はてなブックマーク

こんにちは。マネックス・ラボでferciを開発している佐藤です。今回は、GoogleSignInで本番環境を意識した設定行った上で本番環境での利用を申請しようとしたところ、わからないことが多くて時間を使ってしまったので、本番環境を想定した設定の流れと、ハマりどころを書き残したいと思います。 Googleのロゴは勝手に使えないのでマカロンの画像を貼っておきます。 前提 公式のドキュメント GCPの準備 OAuth2.0クライアントIDの登録 OAuth同意画面の設定 「アプリを編集」の設定 アプリ名 ユーザーサポートメール アプリのロゴ画像 アプリのドメイン 承認済みドメイン デベロッパーの連絡先情報 スコープの設定 テストユーザー 本番環境への申請 確認を準備する 省略可能な情報 YouTube動画について 審査で指摘されたこととGoogle担当者とのやり取りについて ハマりどころ ユーザ

こんにちは。システム開発一部の吉田です。 先月自作PCを組み立てました。ファンがピカピカに光ります。 グラフィックボートを買わなかったのでPCケース内のスペースが余りまして。そこにブロリーのフィギュアを置いてディスプレイ代わりにしていたらメモリがぶっ壊れました。流石は伝説の超サイヤ人。 さて、今回はCodePipelineとCodeBuildとCodeCommitのCode兄弟についてのお話です。主にCodeBuildについて。 これらの組み合わせて使うとCI/CDパイプラインを比較的簡単に作成できるのでとても便利です。皆さんもう使っているでしょうか？ 特にAWSリソース操作の権限管理をIAMロールで完結できるのが個人的には気に入っています。 そんな便利な3兄弟ですが、利用すると気づく独特な癖があります。 タイトルにもある通り、CodeBuildでGitメタデータを利用する際に少しだけハマ

はじめまして、システム開発一部の山下です。 マネックス証券に入社して1年半。自身の転職活動について、少し振り返りたいとおもいます。 アラフィフ転職 1994年に外資系IT企業に新卒として入社しました。Web系のシステム開発を主に担当しつつ、26年間ほど勤務しました。 新卒の頃はまだバブルの影響が残っており、かつ理系なので学校推薦という仕組みで採用されました。つまり新卒時は就職活動をほとんど経験していません。 2020年春に早期退職制度に応募し退職。それから3ヶ月ほど転職活動した後、マネックス証券に開発者として入社しました。 50代、いわゆるアラフィフになって、初めての転職を経験したことになります。そこで苦労した3つのポイントを振り返り、あくまで自己流ですが、その対策について簡単にご説明します。 ニッチなロール 同じ業界に長く居ると、他業種から見て、ロール(役割)分けが細分化されていることを

こんにちは。システム開発グループの小田切と申します。 プログラム実装に関わっていて、JSON*1フォーマットを扱うことが多くなっています。 そういえば、エイッとなんとなく作るJSONフォーマット*2ですが、今一度、JSONの国際標準を確認してみようと思います。 そ。の。ま。え。に。 JSON以前に存在する皆さんに更になじみの深いCSV*3も、いまだに多用しています。まずは、CSVの国際標準を、過去の体験談なども交えて、書きたいと思います。 CSVの国際標準　RFC 4180 RFC 4180の内容とは トップページ 1. Introduction（はじめに） 2. Definition of the CSV Format（CSVフォーマットの定義） 1. 1レコードの区切りに関する規定 2. 1ファイル中の最後のデータの行末に関する規定 3. 1ファイル中の1行目のレコードに関する規定 4

こんにちは。クチコミ機能で賑わっているferciを開発しているマネックスラボの佐藤です。 今回は、ferciシステムにDatadogを入れた経緯を追いつつ、小規模なシステムこそマネージドの監視サービスを使った方が良いのではないか、ということを書きたいと思います。 Datadogについて深掘りする記事ではないことをご承知おきください。 システム構築前 Datadogへの思い込み ferciのシステム規模と、初期の構成について 前置き(構築メンバーとOSSに対して感謝の意を) ferciシステム構築後 Zabbix辛い。ElasticsearchとFluentd辛い。 Zabbixからアラートが上がって調べてみると、トリガーの計算式に書かれている数字が実装と異なっている。 AutoScalingグループの新規ホストがZabbixに正しく登録されない。 監視対象サーバのセキュリティグループと、監

こんにちは。 最近こちらの会社に参りました、システム開発部の小田切と申します。 私の担当する開発が結合テストフェーズに入りました。 結合テストフェーズでは、横軸にテスト時間、縦軸に累積バグ発見数をとったグラフを作成することがあり、信頼度成長曲線と呼んでいます。S字のカーブを描くことが多いです。 形状について考察した理論があり、以下に挙げる２つが基本のモデルと解釈しています。会社によっては40年も前から、以下のどちらかやその拡張式を用いて、バグの発生状況を推定・評価しているところがあります。しかしながら、学校の授業では行わない内容の為、一部の方にしか知られていない事実もあります。 また、先に結論の式だけを提示されて、難しいと敬遠されることも多いので、昔勉強したその成り立ちを今一度書いてみようと思いました。 1) ロジスティック曲線モデル式 ※もともとは、1800年代に人口増加のモデルとして考