ペパボのエンジニアの各種制度 2020 夏 - Pepabo Tech Portal
執行役員 VP of Engineering 兼技術部長の @hsbt です。PS4 の Ghost of Tsushima が面白くて、毎日仕事が終わると対馬にいく毎日です。 2020年7月より、GMOペパボ(以下、ペパボ)では、パートナー(GMOインターネットグループでの従業員の呼称)全員の評価の制度と報酬をアップデートしました。エンジニアについても同様に従来の制度をベースにしながらアップデートを行っています。ペパボのエンジニア職位制度は2015年に導入した制度をベースとしながら2020 年までの 5 年間に主に以下に示すアップデートを行いました。 シニア(以上の)エンジニアの評価基準の細分化(例: 4.1等級-4.4等級など) シニア以上の報酬の大幅な増額 エンジニアリングマネージャ(テクニカルリード、チーフテクニカルリード)の導入 先日、エンジニアの評価について、ベースとなる制度へ
Goで作るテキストエディタ - Sansan Tech Blog
はじめに みなさんこんにちは。Sansan事業部プロダクト開発部のiOSエンジニア荒川です。 以前はRDBMSの記事*1を寄稿し、好評いただいたこともあり、定期的に車輪の再発明系の記事を書いていこうと思います。 さて本日はタイトルの通り、VimやEmacsに代表されるターミナルで動作するインラインテキストエディタをGoで開発してみました。 ソースコードは以下のリポジトリに置いているため、ぜひ参考にしてください。 github.com 完成品 文字だけだとイメージも湧きにくいので、まずは完成品をお見せします。 最低限エディタの動きは出来ている、というレベルの完成度ですね🙏 特徴 1000行インラインエディタ 文字入力/挿入/削除 画面スクロール キーボードショートカット ファイル読み込み/保存 Goのコードハイライト機能 実装の方針 今回はただ開発するだけではなく、いくつかのこだわりポイン
設計書には何を書くべきなのか - terurouメモ
設計とは、 要求（やりたいこと）をヒアリングする 要求を要件（何を満たさないといけないのか）に落とし込む 要件を実現するために考えられる手段を洗い出す 手段の検証を行う 検証結果を元に、どの手段を使うかを選定する 選定した手段を合意する（一部要件を満たさない事項がある場合は、代替策や妥協ラインについても合意する） 合意内容を元に、実装や設定に落とし込む をやることである。画面設計や機能設計のように、3-5の検証/選定が薄くなったり曖昧になったりするものはあるが、一般化するとこの流れになる。 設計書には、上記の設計でやってきたことを順番に書いていけばよい。これを文章構成のテンプレに落としていくと、 要求 要件 方式 対応案（いわゆる比較表で書いていくのが楽） 検証結果 選定・合意結果（合意した代替策や妥協ラインについても記載する） 詳細設計（どういう実装にするとか、パラメーターにするとか、細
Docker ガチ入門 〜つくって学ぶ docker pull & run 編〜 - もろず blog
こんにちは！ いま所属している LAPRAS という会社のメンバーで「LAPRAS 夏の自由研究リレー」と題してそれぞれが興味のある領域についての記事を書こう！という企画をやっており、その一環で記事を書くことにしました！ この記事が1発目の記事なので気合いをいれていきたいと思います。今日から他のメンバーも各々の自由研究の記事を発信して行くのでぜひチェックしてください！ note.lapras.com さて、そんな僕の夏の自由研究のテーマは 「つくって学ぶ Docker pull & run 編」 です。Docker についてより深く知るために、docker pull と run を自分でつくってみようと思います。 お仕事でも趣味の開発でも、もはや Docker なしではアプリケーションは作れないというくらいに Docker を使っています。 LAPRAS では全てのコードは Docker
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
