■ 人事の超プロが明かす評価基準 を読んだ & エンジニアの評価基準について 去年 @pyama86 さんが読みやすくて面白かったと話していたので買ってシュッと読んだ。 確かに面白くて、コンピテンシーという考え方はなるほどなって感じだった。いろんな立場の人が組織にはいるけど、より管掌や責任の範囲が広い人は狭い人ができることは当たり前とした上で、立場にあった評価の基準が重なっていくという話で、自分も含めて「わかるー」という感じだった。 後、この本では評価を決めるのは影響力というくだりがあって、これは特に専門職に分類される人には読んでもらいたいところなんだけど、エンジニアの場合だとシニアエンジニアは「技術力が高い」から評価されるのはなく「技術力が高いので結果として生み出されるアウトプットの影響力が高い」から評価されると置き換えるとわかりやすいと思う。 「アウトプット」と言われると OSS であ
こんにちは。グラムでエンジニアをしている星影（ほしかげ）と申します。 今回のフィードでは、グラムの開発チームの実態について軽くお話させていただきます。少しでも「グラムの開発チームはこういう感じですよ」という雰囲気が伝われば幸いです。 ※技術的なお話については、また別途していきたいと思っているので、今回はそうした話題は含みません。 社内ツールの見直しが早いグラムには情報感度が高い人が多く、常により良い環境を模索し続けています。導入する開発基盤やライブラリにおいても、最新情報は抑えつつ、流行り廃りを見極め、ある程度の運用 / 保守に耐えられるものを選んでいるつもりです。 開発チームに限らず、グラムでは「こういうの使いたい！」という要望が挙がることが多い印象です。みんな基本的に面倒くさがりなんですよね。 なので、 ・極力無駄なことをしたくない ・とにかく無駄を減らしたい ・では、どうすべき？ と
突然ですが、 README.md に動的なコンテンツを埋め込みたいと思ったことはないですか？僕はあります。 具体的には、リポジトリのコントリビューターをREADME.mdに埋め込みたいという願望がありました。 つまりこういうことです。 しかし毎回CIなどでREADME.mdを編集するのはセットアップが面倒です。 <contributors-list> みたいなCustom Elementsが使えたらきれいな世界だなあと思ったのですが、肝心のscriptタグが動かないのでそれは無理です。 ということで、頼れるのは 画像 ということになりました。 Image via Function README.mdに埋め込めて、なおかつ動的なコンテンツを扱えるのは画像のURL展開だけなので、つまりコントリビューターリストを画像化するHTTPエンドポイントを用意し、そのURLをREADME.mdに埋め込めば
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く