運動や資格の勉強もしたいのに…平日何もできない社会人の心の声を描いた漫画が胸に刺さりすぎる「何だこの人生…」SmartTrainee⚾︎ワークアウトブロガー @0to1Workout 商社で働いてたから、お金に不自由はなかったけど この漫画は物凄く共感。 会社なんてある意味ぬるま湯だし、その後の時間に何をするかが大切だけど その気力は奪われがち。 環境を変える方が楽だなと思って、会社辞めたわ。 (働きながら勉強、トレーニングもしてたし、ブログ書いたりもしてたけど) twitter.com/riko3_/status/… 2019-04-07 00:26:58
エンジニアの業績評価をやめるべき理由 - 室長のひとりごち
身も蓋もない言い方をすれば、エンジニアの評価なんて必要ない。というか、できない。 できない理由は幾つかある。エンジニアに求められるスキルは広く深さがある。その人を形作る基礎スキルはもちろん、エンジニアが身につけている技術を適用してアウトプットする技術スキルの両方が評価対象となる。 評価対象は、所属する組織の事業により違いがある。事業領域が広ければ、事業として必要とする技術領域は広がる一方、そうした技術の幅は一人のエンジニアでは賄えないから複数のエンジニアでカバレッジをすることになる。結果、同じ事業を一翼を担うエンジニアの担当する技術は違うが、評価は同じ軸で行われる。 そこで持ち出すのが事業への貢献、役割になる。ビジネスでリーダーシップを発揮したか、などを問うようになる。 担当する業務もSI（新規開発）とSO（維持管理）で同等の評価をしない。SIでは新しいビジネス、サービス開発により事業貢献
「管理ゼロで成果はあがる」を読んで - 組織と自分を変えるヒントとか学びなど - Lean Baseball
読了から二ヶ月経過して今さら感もありますが、すごく良い本でしたので感想を. セルフマネジメントの大切さを学びました 倉貫さんの新著、「管理ゼロで成果はあがる」です. 管理ゼロで成果はあがる ~「見直す・なくす・やめる」で組織を変えよう 作者: 倉貫義人出版社/メーカー: 技術評論社発売日: 2019/01/24メディア: 単行本（ソフトカバー）この商品を含むブログを見る TL;DR（感想をひと言で言うと） 組織だけでなく、「自分を変える」「自立する」という視点で「自分ごと」として読むと最高だ！ と感じました. 自分および組織を「自分ごと」として変えたい方は絶対読んでほしいと思っています.*1 おしながき TL;DR（感想をひと言で言うと） おしながき 【感想】管理ゼロで成果はあがる 倉貫本の追っかけです（最初に断っておく） 全体的な感想 自分を変える 抱え込まずさっさと相談 タスクばらし
僅か100万円で開発した「Amazon Go」型店舗 その意外な仕組み
欲しい商品を手に取り、店を出れば支払いが終了──。米アマゾン・ドット・コムがレジなしコンビニ「Amazon Go」を一般向けに開業して以降、その驚異の買い物体験は大きな話題となり、さまざまな企業が 「ウオークスルー（通り抜けるだけで決済が完了する）」を実用化しようと開発競争を繰り広げている。しかし、手に取った商品を正確に認識して決済まで持っていく精度の問題や、膨大なコストなどの面から実際の店舗に導入されているケースは非常に少ない。 そんななか、「完全キャッシュレス」「レジなし」「ウオークスルー」を実現したAmazon Go型カフェが2019年2月、東京・秋葉原にオープンした。システム開発のクラスメソッド（東京・千代田）が運営する「Developers.IO CAFE」だ。
オルバースのパラドックス - Wikipedia
星が限りなくあるのであれば、夜空はこのようにいたるところ輝いて見えるはずだが、実際にはそう見えないのはなぜだろうか。 オルバースのパラドックス（Olbers's paradox, Olbers' paradox）とは、「宇宙の恒星の分布がほぼ一様で、恒星の大きさも平均的に場所によらないと仮定すると、空は全体が太陽面のように明るく光輝くはず」というパラドックスである。 その名は、18 - 19世紀の天文学者であるヴィルヘルム・オルバースに由来する。ただしオルバースが最初に提起したわけではない。オルバースの逆説、オルバースの逆理、オルバースの背理、ド・シェゾー＝オルバースのパラドックス（de Cheseaux-Olbers paradox）[1]などともいう。 このパラドックスの帰結は、星は距離の2乗に反比例して見かけの面積が小さくなるが、距離が遠い星の数は距離の2乗で増えるので、これらはちょ
フロントエンドの開発環境に Docker は不要(少なくともMacでは) - mizchi's blog
追記: 前提部分 開発環境を docker-compose で抽象することが最近のベストプラクティスだとされているが、フロントエンドをコンテナに突っ込むと無視できないIOボトルネックが発生する。 とくにwebpackのファイル監視からのビルドで発生する高頻度のIO処理を捌くために、フロントエンドだけはホスト環境に移したほうがいい、という主張。 これについて speakerdeck.com 自分の意見 Web開発者の主要な開発環境である Docker for Mac は I/O がとにかく遅い (3x~5x) data volume の driver やら cache を工夫しても遅い npm install/webpack は 基本的に I/O ヘヴィー とくに大規模開発時の watch => build がクリティカル webpack.conifg の entry で自分が関与する部分以
やるべきことを締切直前まで先延ばしにしてしまう心理に迫る「Inside the mind of a master procrastinator」
by Holly DeVane 宿題・仕事・論文執筆など、やるべきことはあるのに後回しにしてしまい、ついには締切直前に不眠不休で取り掛かる羽目になる……という経験をしたことがある人も多いはず。「やるべき」とわかっているにも関わらず、人はどうして先延ばしにしてしまうのか、という心理についてブロガーのティム・アーバンさんがTEDで語ると共に、その真の恐ろしさに迫っています。 Tim Urban: Inside the mind of a master procrastinator | TED Talk Subtitles and Transcript | TED.com https://www.ted.com/talks/tim_urban_inside_the_mind_of_a_master_procrastinator/transcript ムービーは以下から見ることができます。 Ins
そのリリース日そんなに大事ですか？ - だいくしー(@daiksy)のはてなブログ
今期の目標設定を決めましょう、というときに、よく「〇〇の機能を期日どおりにリリースする」と書きたくなりがち。ぼくも以前はよく書いていた。 マネージャの仕事をそれなりの期間やっていくうちに、この考え方はまったく意味がないな、と思うようになった。 リリース日を遵守する、というのは、プロダクトのビジネス価値を生み出す要素の一つにすぎない。期初にたてた予算が、この日にリリースされることを前提に計画されている、とか、競合製品よりはやく価値を出すためにはどうしてもこの時期にリリースしたい、といった感じだろう。 なのでリリース日を目標にするのはなんの問題もない。当然そのように振る舞うべきだ。ただ、これが評価に結びつくととたんに破滅する。 リリース日遵守を基準点。遅延すると減点、前倒しで加点。こんなふうにしてしまうと最悪。 開発を進めるうちに、どうしてもリリース日に間に合いそうにない。スコープを絞って間に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
docker-node/docs/BestPractices.md at main · nodejs/docker-node
迷える子羊に捧げるコンテナ環境徹底比較 〜ECS、Fargate、EKSは何が得意で不得意か〜
