Sign in
![Google Colaboratory](https://cdn-ak-scissors.b.st-hatena.com/image/square/b3cf727fb43a38982c4fc02e1c51ebc0090e85a5/height=288;version=1;width=512/https%3A%2F%2Fcolab.research.google.com%2Fimg%2Fcolab_favicon_256px.png)
この度転職活動を行って無事内定をいただいたので、記念に面接の中でいただいた質問をまとめてみました。 某大手金融のフィンテックエンジニアに転職します!! 転職活動当初は、レガシー、ジョブホッパー、経験少でダメ出しの嵐🍃 でも諦めずNuxt+Firebaseでのサービス開発、マイクロサービス化ポートフォリオ、CTFの取組、GitHub毎日コントリビュート、個人活動も頑張って内定頂けて本当よかった😁 — bindingpry (@bindingpry) November 19, 2021 基本的に技術面接では、履歴書や実務経験の技術、ポートフォリオで扱っている技術、自分で口にした技術を深ぼられることが多かったです。 そこはしっかり技術を扱えるだけでなく説明できるようにすることも必要だと思いました。(自分は最初ボロボロでしたが笑) また正社員の面接では技術と同等に、仕事への姿勢、性格、事業への
はじめに こんにちは、インフラエンジニアの 高山 です。 この記事は Enigmo Advent Calendar 2021 の 9 日目の記事です。 現在、BUYMAをオンプレからAWSへ移行するプロジェクトを進めています。 テスト環境の移行は完了し、本番環境の移行をしようというところです。 本番環境の移行をする前に 性能的に問題ないことを確認するため、本番環境と同程度のスペックで検証環境を構築し負荷テストを実施しました。 まだ終わっていませんが、今の時点で得た知見を記事にしようと思います。 負荷テストツール選定 詳細は割愛しますが、 以下のような要件からAWSの分散負荷テストのソリューション(正式名称はDistributed Load Testing on AWS 以下、AWS負荷テストソリューションと呼ぶ)を使うこととしました。 大規模な負荷テストができること 複雑なテストシナリオが
スタディスト開発ブログ Advent Calendar 2021 8日目の記事です。Hansoku Cloud 開発グループのマネージャーをしている zuckey が担当します。2020年の末にHansoku Cloudという新規事業のアプリケーションをリリースしたのち、そのプロダクトおよびサービスのグロースに力を入れてきました。 本エントリでは、Hansoku Cloud で今年の6月に検討を開始し、9月にリリースにこぎつけたモバイルアプリの開発全般について書きます。 TL;DR“ガワネイティブ” からネイティブAPIへのブリッジ部分を提供してくれるライブラリ Capacitor を利用してiOS / Android向けのモバイルアプリをリリースしたWeb開発者がモバイルアプリを開発するにはどのようなツールを使うにしても、チームで学習を深めていく必要がある。Full Stack なチーム
前置き(私見含む) Recoil が面白い。 React でそれなりの規模のアプリケーションを作ったことのある方なら、状態管理の辛さをよく知っていると思う コンポーネントを跨いだ変数をひとつ作ろうと思っただけなのに「まずは Flux アーキテクチャのコンセプトとアンチパターンから学ぶ必要があります。大量の props バケツリレーから逃れるためには〜」とか言われても 現実的で複雑なアプリケーションの状態、つまり「非同期処理」や「状態同士の依存関係」……などを作っていくのは大変 そんな中 Facebook が新たな状態管理ライブラリをリリースした、それが Recoil これは Redux とも ReactN とも全く異なるアプローチのライブラリで、しかも圧倒的に分かりやすい teramotodaiki.icon 現在は experimental(実験段階) なので Redux のコードをごっ
この記事は LITALICO Engineers Advent Calendar 2021 その2 の7日目の記事です。 Pull Requestを作るときに割と入念にセルフレビューしてからレビュー依頼するようにしており、また他メンバーのもののレビューをしているときに「これは事前にセルフレビューして修正しておいてほしいなぁ」と思うことがあり、セルフレビューの重要性を感じるこの頃です。 レビュー時に都度指摘してもよいのですが、意外と観点が多いこともあり、思考の整理がてらアウトプットしてみるか、という試みです。 なぜ自分でレビュー? まず、そもそも自分で書いたコードを何故自分でレビューするのか?という点について書いておきます。 よくプログラミング一般の議論で「N日前のコードは他人のコード」と言われます。ということは、Pull Requestを作成した時点の自分から見て、該当コードを書き始めた時
prismatix事業部の塩谷 (@kwappa) です。 「**会」について prismatix事業部では、毎週金曜日の朝10時から「**会」というタイトルで誰かが喋る、という会を催しています。 もともとはマネジメント陣からプロダクトの導入状況や部署の状態、今後の方針などを説明する機会だったのですが、だんだん拡大していろんな話をしてもらうようになってきました。 ぼくも(ちょっと恥ずかしいのですが)「塩谷会」というタイトルで何度か話しています。その中のいくつかがDevelopersIOの登壇ネタになっていたりもするので、いいアウトプットの機会にもなっています。 「レビューのつらさを倒したい」 先日、塩谷会で「レビューのつらさを倒したい」という話をしました。見直してみると社内に閉じなければならない内容でもないので、スライドを公開してみます。 スライド 以下余談 この記事を書いたいきさつ 日々
はじめに こんにちは!Hamee株式会社の tatsuo48 です。 GitHub ActionsにはデフォルトでGITHUB_TOKENというシークレットが存在しており、環境変数にセットして利用することで、Actionsがトリガーされたリポジトリに対する操作が可能です。 GITHUB_TOKENシークレットについて これはこれで便利なんですが、特定の条件のときに少し問題があります。 CIの中で別リポジトリを使いたいときどうする問題 上記の通り、GITHUB_TOKENでは権限の範囲がActionsがトリガーされたリポジトリに制限されます。よって以下のようなユースケースには適しません。 CIの中で別のプライベートリポジトリを参照したい Terraformのプライベートモジュールとか こういった場合、マシンユーザという人に紐付かないユーザを作り、そのユーザの個人アクセストークンが使われたりす
Intro 筆者は、 Web のセマンティクスに対する実装の方針として、大きく Push 型の実装 と Pull 型の実装 があると考えている。 もっと言えば、それは実装方法という具体的な話よりも、開発者のセマンティクスに対する態度を表現することができる。 この話は「Push よりも Pull が良い」などと簡単に切り分けられる話ではない。 「自分は今 Push で実装しているのか、 Pull で実装しているのか」この観点を意識するかしないかによって、セマンティクスに対する視野が広くなり、その応用として、たとえば今自分が行っている実装が、将来の Web においてどのような互換性の問題を生じるかなどを想像できるようになるだろう。最近問題になる Ossification を、こうした視点の欠如の結果とみることもできる。 (本エントリでの Ossification は、一般に言われている Pro
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く