最近、エンジニアリング組織の健全さの指標に、 d/d/d というのを用いてる。 deploys / a day / a developer の略で 1日あたりのデプロイ回数を開発者数で割ったもの。 だいたい、0.1 以上なら健… https://t.co/2DQo7GBR7j
最近、エンジニアリング組織の健全さの指標に、 d/d/d というのを用いてる。 deploys / a day / a developer の略で 1日あたりのデプロイ回数を開発者数で割ったもの。 だいたい、0.1 以上なら健… https://t.co/2DQo7GBR7j
アウトプット大全を読み、一ヶ月試してみた感想を書いておく。 所感 本著はアウトプットするためのTipsがひとつ2、3ページくらいの量でいくつもまとめられており、自分に合ったもの、すぐ始められそうなものから試すことができる。 本著の「アウトプット」とは、「他人と話す」「アイデアを出す」という日常の小さなアウトプットも含まれており、ブログを書いたりなにか発信する媒体を持っていない人が読んでも参考になるはずだ。 私は読後一ヶ月程度いくつかのTipsを試してみたが後述する通りとても効果を感じたので今後も本著のTipsに従うのを継続していきたい(そして他のTipsも取り入れていきたい)と思う。 どんな本なのか この本には著者がまとめた80のアウトプットのTipsと、7つのトレーニングがまとめられている。 著者である精神科医の樺沢紫苑氏は実際に以下の圧倒的なアウトプットを継続しているとのこと。 メルマ
開発者向けのドメイン、「.dev」の登録受付が開始された。timakin.devはちゃんと俺が取った。みなさんも取りましょう。 で、昨日vim.devのドメインが個人によって取得され、そのリダイレクト先がEmacsのサイトになっていたことで、物議を醸した。HackerNewsにも載ってた。 この行為に対し、観測範囲では ・「やりすぎだ、同じデベロッパーとして辟易する」という人 ・単に"エディター間の宗教戦争"に関するユーモアあるネタだと受け取る人 の二極化が見られた。ちなみに僕はそこまでエディタ戦争に関心はないし、結構あとあと迷惑になる行為かなーと思うので、どちらかといえば前者寄り。 僕の話は置いておいて、前者はOSS開発者やカンファレンス主催者などが多い印象を持った。だから前者の意見が偉いとかそういうわけではないのだけれど、おそらく以下の2つのポイントで認識が大きくズレているから、二極化
やりたいこと(ユースケース)から利用パターンへ到達できるように、ユースケース主導で紹介。利用するサービスのすべての機能をを覚えなくてもやりたいこと/部分からスタートできます。実際、類似するアーキテクチャの実例が多くあることがわかります。 パターン別のテンプレートから始めてみよう! チュートリアルで体感しよう! - いくつかのパターンはテンプレート/雛形から始めることができます。それぞれのパターンの「Template」「Sample」「Solution」のリンク先を参照ください。 - 実際に作って動かせるチュートリアルに「Tutorial」「Workshop」リンクからアクセスできます。ちょっとしたトライに費用が気にならないのもサーバーレスの良いところ。 - 各パターンの特性に合わせたエラーハンドリングの記事を拡充中。それぞれのパターンの「エラーハンドリング」リンクからご確認ください。 -
表題のような問題があり,その調査したという記録です.なお,結論を一言で言うと--initを使え,ということになります. そもそもDockerコンテナを起動すると,CMDあるいはENTRYPOINTに指定されたコマンドがコンテナ内でPID 1として起動します.これが何を意味するかと言うと,「CMDあるいはENTRYPOINTに指定されたコマンド」はそのコマンド自体の責務をまっとうするのと同時に,initプロセスとしての振る舞いも行わなければならないということになります (id:hayajo_77さんにこの辺を詳しく教えてもらいました,ありがとうございます). つまりPID 1で動いているプロセスは「SIGCHLDをトラップすることで孤児プロセスを適切に回収し,waitpidをかける」という処理も適切に行う必要があります. さて,puppeteerを使ってChromeブラウザを起動するとどうな
これまで大小様々なシステム障害に遭遇してきましたが、障害対応から学ぶことは沢山あります。 いろんな習熟度のフェーズで障害発生を学びに変えるための行動事例や、webアプリケーション開発において障害対応を減らすためにできることなどをお話しできればと思います。 TokyoGirls.rb Meetup vol.1 https://techplay.jp/event/716251
いきなり結論を書くと、idやclassはスタイルのためのものなので、テストでそれを使うのはやめましょう。そして、カスタムデータ属性を使いましょう。(idやclassはスタイルのためだけではないという意見はごもっともです!しかし、主にとしてスタイルに使われるということでご了承頂いて以下の駄文に付き合って頂けると幸いです🙇) 先に断っておくと主にreactについての話で、JSXを前提とします。(手法はReactに限りませんが理由は後述) 2020/03/23 追記 この記事は1年以上前に書かれた記事なのでテストフレームワークとしてenzymeを使っていますが、現時点ではTesting Libraryの使用をオススメします。data-testid に対応するクエリを備えています。 React Testing Library · Testing Library はじめに ご存知の通り、ロジックと
大分周回遅れなのだけれども、最近読んでいる「Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations」がめっぽう面白い。なお以下にKindle本へのリンクを示すが、私はここに書いた手法で定額制の範囲内で読んでる。 Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations 作者: N
redash使って、ロジックツリーのように可視化する。いいやり方ですね。 ダッシュボードは本ブログで何度も登場しているRedashを使用しています(まじ便利)。 構成は先ほどのロジックツリーを意識していて、メインのダッシュボードには木の上の方にある数値が並んでいます。 Redashのダッシュボードにはリンク付きのテキストを埋め込むことができるので、リンクを辿っていくと枝葉の数値まで辿れるようになっています。数値を見る仕組みとしては、数値確認朝会と、Slack通知を行っているみたいです。 数値確認朝会とはデータ分析部で実施している、プロダクトの各指標を毎朝確認するための朝会です。 各メンバーが週替りで担当の指標を決めていて、その数値がどんな状態なのかをレポートしていきます。 朝会用の資料にはQiita Teamを使用していて、ダッシュボードへのリンクや主要なグラフが埋め込まれている投稿が毎朝
こんにちは。Wantedly Visit 開発チームで"Squad Leader"をしている森脇です。 この記事では、エンジニアブログでいつも紹介している技術の話ではなく、開発チームが普段どのようにシゴトをしているのかを紹介したいと思います。エンジニアだったらクールな技術を使っているかはもちろん重要ですが、どのような組織体制で、どのような目標を持って、どのように意思決定をするかは、それ以上に大切なことでしょう。 まずは重要なキーワードであるSquadとOKRについて簡単に説明してから、実際のチームを例にしてより詳しく具体的な話をしていきます。 チーム編成: SquadとTribeさっき自分のことを"Squad Leader"と紹介しましたが、いきなり登場したこの"Squad"という言葉について説明します。 Squadとは、いわゆるチームのことなのですが、同じ目標をもち、互いのシゴトが強く依
「VOYAGE GROUP エンジニアの公開ガチ評価会」に参加して、最近考えていた「良いエンジニア」像がかなり良い感じだと思うようになりました。 「ガチ評価会」自体の内容は他の方のブログに譲るとして、「ガチ評価会」で聞けなかった部分、つまり「普段だったら『ビジネス的側面からの技術投資判断』とかも聞くんだけど」と言っていたところが、まさに聞きたいところだったのでニヤッとしました。聞けなくて残念♪ 妥協ない挑戦元々ピクシブの技術力評価においては、「最近やった妥協ない挑戦は何ですか?」というのをキーワードにやってました。 解決すべき課題に対して、どういう背景があって、どういう事前調査をして、どういう実装をして、どう考察するか、というところまでをきちんと考えて仕事することに成長があるんだよ、というメッセージ性です。 そんなこと言っても普段は妥協ばっかりですって?いえいえ、相反する選択肢の中で、何を
CTOの役割は会社によってもマチマチですが、自分が2年やってきて見えてきたことを言語化してみます。 責任分解のツリー仕事を任せるほうは結果責任(accountability)を負い、任せられたほうは執行責任(responsibility)を負うそうです。 会社の持ち主である株主は会社のすべてに対する結果責任を持ち、その執行責任をCEOに負わせます。CEOはそのうち技術的な部分の執行責任をCTOに負わせて、自分は結果責任を負います。 CTOは技術全体のうちの一部をまた別の誰かに任せます。 というふうに、会社って責任分解のツリーで成り立っています。 責任は権限やゴールとセット何かを任せるときには、権限も一緒に渡します。やっていいこととダメなこと、使っていいお金やリソース、何は相談が必要か、等々。これらは敢えて明示されないかもしれませんが、必ず存在するのです。 それから、任せる側と任される側には
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く