selenium構築メモ
ブランチ戦略とリリースについて
- フィーチャーブランチ
- リリースは金曜は避ける。
実際に使った転職サイト３選
概要
転職２回目のソフトウェアエンジニアが使った転職サイトについて話していくよ！
転職ドラフト 2件
good
- 先に年収提示がある
more
- スカウトをもらって面談をしても基本スキル感の需給やコミュニケーションスタイル等がマッチングしないのでユーザーとしてはもう一工夫ほしい（何かはわからん、、）
- スカウトをもらえる件数が他と比べて少ないのはフロー的に仕方ないのかもしれない。
印象
他の転職サイトでもマッチングしないこと自体は多々あるけどスカウト数が少ないのでマッチしない感覚だけが残った気がする。 スキル不足、記述不足でスカウトをもらえてないだけかもしれない。 職務内容の記述自体は他の転職サイトに載せているものと同じ。
paiza転職 16件
good
- スキルチェックが楽しい
- スキルチェックをしっかりやっておくと捌ききれないほどスカウトがもらえる。
more
- スカウトを特定のステータスで一括辞退させてほしい。何十件もカチカチ自体は押せないです。。
- 気になるや、話を聞いてみたい、ボタンを押す時、後のフローの検討がつくと良い。
- 応募履歴が進度やステータスでソート/フィルタさせて欲しい。
- スケジュール機能で、重複はシステム側でコントロールしてほしい。直近1営業日でも面談が入れられるようにしてほしい。
- 問い合わせ対応をチャットでして欲しい。（営業時間内でのメール回答は1時間程度だったので対応自体は早めにしてもらえる。）
印象
とにかくたくさんスカウトがもらえて比較検討できるのでいい。 カジュアル面談の認識が世間とズレていそうで、カジュアル面談後のFBに「今回はカジュアル面談なので評価なし」のような記述が多発する。 システムと上手くマッチしてない感じがするのは他の至る所でも感じるのでとにかく使いずらい。重いし。
Findy 25件
good
- チャットやユーザーサクセス面談でのフォローが手厚い。
- スカウト件数も多い。
more
- カスタマーサクセスの方に伝えた内容が思わぬ形で面談企業側に伝わることがある。
- 相談させてもらうたびに企業側への公開範囲を確認した方がよさそう。
- チャットが常に最新順で並ぶので（それはそう）選考ステータスが確認しづらい。小さく出してくれると嬉しい。
印象
概ね満足。 ただ自分がセンシティブな内容を話してると思っていてもCSの人との認識齟齬があると企業側に伝わってしまうのはびっくりするので確認してほしい。
習得していきたい技術
- Web
webフレームワーク
データベース
認証、セキュリティ
- JWT(JSON Web Token)認証
- Cookie認証
- Basic認証
- ワンタイム認証
- SSL(Secure Sockets Layer)認証
- OAuth
- 公開鍵と秘密鍵
- 暗号化と復号化
- CORS(Cross-Origin Resource Sharing)
- CSRF(Cross-Site Request Forgeries)
- XSS(Cross-Site Scripting)
- SQLインジェクション
テスト
- 単体テスト(ユニットテスト)
- 結合テスト
- 機能テスト
- システムテスト
- ホワイトボックステスト
- ブラックボックステスト
デプロイ
- git：バージョン管理で最も使われるソフトウェア。ソースコードの変更を追跡し、複数の開発者が同時に作業できるようにするためのバージョン管理として使われる。
- GitHub：バージョン管理やプロジェクトのソースコードを確認するためのWebサイト。GitHubアカウントを持っていれば、どこからでもプロジェクトに参加できる。
- GitHub Actions：ソフトウェア開発のワークフローを自動化するために役立つ。GitHub上でプロジェクトのビルド、テスト、パッケージ化やデプロイを行える。また、ワークフローのあらゆるステップを自動化するために使える。
- Webアプリケーションをデプロイするには、HTTPリクエストに応答し、オンラインデータベースと連動するための専用のサーバが必要だ。そこで有名なPaaS(Platform as a Service)を紹介する。
PaaS(Platform as Service)
- Heroku：PaaSの代表格。無料プランが2022/11/28に廃止される。引き続きHerokuでデプロイ・運営するには最低でも月額$7が必要。(サブスク形式)
- Railway：無料枠で活用できるPaaS。GitHubアカウントさえあれば誰でも始められる。
- Fly.io：Railway同様に無料枠で活用できるPaaS。多種多様な言語・フレームワークに対応している。
- Firebase：Googleが開発したデータベースサービスと認証サービスがついたホスティングサービス。
- Vercel：Next.js(ReactベースのWebフレームワーク)で開発されたプロジェクトをデプロイできるPaaS。HTML/CSS、JavaScriptで制作されたWebサイトのホスティングもできる。
データ構造とアルゴリズム
- ツリー構造
採用担当「うちの会社いい人が多いんですよね〜」の罠
採用担当「うちの会社いい人が多いんですよね〜」の罠
概要
目次
- なぜ採用担当はいい人が多いというようになったか
- 身近な人がいい人だから？
- 最近コミュニケーションでハレーションがないから？
- みんながいい人が多いって言ってるから？
- いい人が多いアピールの意図
- いい人はいい人コミュニティに入るから
- いい人に入って欲しいから
- 単にプラス要素としての紹介
- いい人とはどんな人か
- マイナス要素がない人？
- マイナス要素はあっても特化して優れている部分があるとか？
- 全体的に社会人基礎力が高い？
- いい人というのは個人が意図的にいい人を心がけている可能性が高いと思ってる。
- いい人は採用においてプラス要素になるか
- いい人が多い会社に入ればいい人からいいインプレッションをもらえる？
- よくない人に煩わされることが少ない？
- いい人ばかりのコミュニティの今後の見通しは？
- 「部屋の中の象」状態にならないか
- いい人が多い、という状態は一過性ではないのか
- いい人は恒常的にいい人か
- いい人というのも個人の状態の一つで、経済的余裕、精神的余裕で変わる
- ライフステージの変化で変わる可能性もある。
- いい人は恒常的にいい人か
- いい人がいると会社にとってどんなメリットがあるか
- ハレーションによる余計な課題が増えない？
- 離職率の低下？
結論
いい人というのは個人の努力によって支えられていることが多い。楽観的に考えず、いい人を言語化し、ドキュメント化し、迷った時にどうしたらいいかを明示しておくことが大切。また、いい人でいることが組織のメリットであり、個人のメリットになることをことあるごとに認識できるよう、組織の制度などで仕組み化しておくといい。
プライマリーキーは何にすべきか
想定読者
結論
分散環境でなければ基本的にサロゲートキーを使う。 ユニークなレコードを担保するために複合主キー候補のカラムにユニーク制約を貼る。
候補
auto-increment id（サロゲートキー） ナチュラルキー 複合主キー UUID
複合キーを使用しない方がいい理由
UUIDについて
UUIDにするとセキュリティが担保されて良いと聞いたことがあるけどAuto-Increment IDとUUIDであればどちらを適用するべきか。
chatgptの回答
データベースのプライマリーキーにauto-incrementのIDを使用するか、UUIDを使用するかは、アプリケーションの要件とスケーラビリティに大きく依存します。以下に、それぞれの選択肢が適している状況について説明します。 Auto-Increment ID: データが単一のデータベースインスタンスで保管されている場合に便利です。これは、プライマリキーが一意であり続け、順序を保持することを保証します。 簡単で、直感的な運用が可能です。データが順序付けされているため、データの挿入順序を簡単に判断できます。 IDが小さいため、ディスクスペースを節約でき、インデックスの効率が向上します。 ただし、分散環境でauto-increment IDを使用すると、IDの一意性を保つための追加の手段が必要となるため、複雑性が増します。 UUID: 分散データベースやマイクロサービスのアーキテクチャでよく使用されます。各エンティティはその生成元に関係なく、グローバルに一意のIDを持つことができます。 UUIDはランダムに生成されるため、情報の推測を難しくします。これはセキュリティ上の利点となり得ます。 ただし、UUIDは通常、数値のauto-increment IDに比べて大きいため、ストレージとパフォーマンスに影響を与える可能性があります。 結論としては、使用するキーの種類は、アプリケーションの要件、データベースの設計、そしてどの程度までスケールする可能性があるかに大きく依存します。そのため、「一概にこれが正解」と言うことはできません。具体的な要件と状況に基づいて適切な選択を行うことが重要です。
と言うわけで分散環境になった時に導入検討すれば良さそう。
