人間をリソースと呼ぶことの何が問題なのか - valid,invalid
かねてより人間、とりわけ労働者や従業員をリソースと呼ぶことについて批判的な意見を聞くことがあった。 2018 Don't call people resources - Ben Linders 2021 社員を「リソース」と呼んではいけない――。 | d's JOURNAL（dsj）- 理想の人事へ、ショートカット 2022 人間をリソースと呼ばない方がいいと思う - ジムには乗りたい 加えて、これらの主張に対するカウンターを見たこともある。「問題の所在が不明瞭」「情緒的な意見のみで代替が示されない」「人材を人財と書くような言葉遊びでは」等々。俗っぽく言えばここにあるのは、「モノ扱いしないでほしい」vs「とは言っても経営管理上はヒト・モノ・カネ・情報はリソースでしょ」という対立である。 この件について「人間をリソースと呼ぶことの問題についてアカデミックな見解・理論はあるのか」「人間をリソー
状態、結合、複雑性、コード量の順に最適化する - valid,invalid
There’s No Such Thing as Clean CodeのHacker Newsコメント経由でコードやシステム設計・最適化についての良いコメントを見つけた。どうやらHacker Newsで何度も引用されているらしいが日本語で言及された記事が見つからなかったので取り上げてみる。 コメントは2016年のSandi MetzのThe Wrong Abstractionに関するもので、発言者のcurun1rいわく「私は設計の優先順位をこの順序で学習することで、優れた開発者になれた」。*1 4つの基準と優先順位のガイドライン 状態 > 結合 > 複雑性 > コード量 私は状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。 コードがよりステートレスになるなら、結合を増やすこともいとわない 結
"まともなステージング環境"を考える - valid,invalid
まともな（信頼できる）ステージング環境を用意できてるウェブ系企業、肌感だけど5%以下という印象— たにみち (@ttanimichi) 2018年8月20日 このツイートを見て弊社は5%に入れるかどうかを考えてみたいと思った。 が、そもそも何をステージング環境と呼ぶか、何をもって"まとも（信頼できる）"と言えるのかわからないのでそこから考えてみた。 ステージング環境とは 本記事中では「アプリケーション、システムの動作や表示を試験するための環境」とする。 試験の対象は機能・性能・外部連携などの多岐にわたる。また、試験を行うのはサーバサイド開発者、クライアントサイド開発者、デザイナー、カスタマーサポート、プロダクトマネージャ etc.…と、これも多岐にわたる。 まともであるために、ステージング環境で実現したいこと 少なくとも自分の感覚では、以下を実現できるのであれば良い開発体験（Develop
ソフトウェアの世界での slug / スラグ / スラッグの意味 - valid,invalid
かつての自分と全く同じ気持ちを持った質問者によるurl - What is the etymology of 'slug'? - Stack Overflow（'slug' の語源は？）が気に入ったので抄訳。 python - What is a "slug" in Django? - Stack Overflowよりも質問の仕方が良い。 ちなみに今の自分が「'slug' ってなに？」と聞かれて説明するなら「ヒューマンリーダブルな ID」あたりが妥当な回答だろうか。 Q: ‘slug’ の語源は？ ‘slug’ は特筆すべき理由のない言葉なのか、それともやはり何らかの意味がある言葉なのでしょうか？あるとき私は会話の中でこの言葉を使用したのですが、「なぜ ‘slug’ って呼ばれているのか」と聞かれたときに私も意味を理解してないと気づきました。 もちろんそれがどのように使われているかは知って
休日の成果を手放しに称賛しない - valid,invalid
土日祝日などの勤務時間外にがんばって出した成果を「やっていき」「圧倒的当事者意識」などと手放しに称賛しない方が良いと思っている。 「いやー土日にがんばるなんてスゴイっすね〜〜〜」と褒められて気分良くなったりするんだけど往々にしてそもそも実現不可能なスケジュールの帳尻合わせに加担してしまっていたりする。そういうのは個人の頑張りで巻き返すのではなくいっそ破綻させた方が全体の教訓になるので好ましい。 こういう振る舞いを迂闊に繰り返すとだんだん周囲の期待値も変わってきて「休日で巻き返せる/巻き返してくれるからいっか」「今週末は働いてくれなかったのか…」となってくる。*1 ボランティア精神に近い個人の貢献は当たり前ではないことを共有し続けないといけない。 誤解しないようにしたいのが問題なのは「やり方」であって「出した成果」それ自体は尊いということ。「休日に対応したからゴミ」みたいなことは、ない。平日
満足度の高い引越しのためにやったこと - valid,invalid
いろいろあり引っ越すことにした。 学生時代も含めるとこれが4回目の賃貸物件探しだ。過去の引越しも、その時々で良い物件を見つけられたと思っているのだが…どの体験もあまり満足度が高くなくて若干トラウマ感があった。 今回物件を探すにあたってこうした過去を乗り越えることにした。 はてブが集まっている人気記事などを読んでみると、どうやら引越しや賃貸物件探しの満足度が低い原因は「ネットで物件探しを済ませようとする」「良い不動産屋を探していない」ことなどにあるらしい。 特に 今回は良い物件を探すのではなく、良い不動産屋を探すという方向に考えを変えることができたのが良かった。 部屋探しは面倒、suumoやhomesで探しててもよく分からない、自分より物件探しのプロの不動産屋の方が物件探しは得意なんだからそこに任せたほうが結果的に良いだろう、なら任せられる人を探そうという感じ。 良い物件ではなく良い不動産屋
git push --force でなく git push --force-with-lease を使う - valid,invalid
前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある git push --force でなく、最後に fetch したタイミング以降に他人が push していたら失敗する git push --force-with-lease を使う方が良い。 --force considered harmful; understanding git's --force-with-lease - Atlassian Developers Quipper では GitHub flow のような開発フローを採用している。 各開発者が feature branch を作成し、master / develop branch へ pull request を作る流れだ。 他人と修正箇所が重なってコンフリクトした際には rebase が必要で、 rebase 後の内容を push する際には
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
