Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

タグ

dev0000_1のブックマーク (8,166)

  • つよつよエンジニアのなかには初心者にやたら厳しい人がいる話…「信頼関係の構築がないのに試しはただ追い詰める」「社内の常識は社外の非常識なのでまず教える」など

    サタン@フリーランスエンジニア @satan_engineer つよつよエンジニア、初心者にやたらと厳しくないですか? 新人の育成を疎かにすると、業界の衰退に繋がると思うのは私だけではないはず。 ところで「つよつよエンジニアの定義って何?」って聞かれて答えられる人いるます? 納得いく答えが見つからなかったので、自分なりに考えてみました。 note.com/satan_engineer… 2024-11-10 19:39:30 リンク note(ノート) 【最強】つよつよエンジニアの正体|サタン@フリーランスエンジニア SNSで「つよつよエンジニア」ってワードをよく目にするんですけど、じゃあ、つよつよエンジニアの定義って何だろう?と気になったので、私なりに 考えてみました。 つよつよエンジニアの定義は、ズバリこうではないか、と思います。 知識に対して誰よりも貪欲 努力が努力ではない 他人がつ

    つよつよエンジニアのなかには初心者にやたら厳しい人がいる話…「信頼関係の構築がないのに試しはただ追い詰める」「社内の常識は社外の非常識なのでまず教える」など
  • マンガの表紙に金が出ない件の話|デンノー忍者|pixivFANBOX

    はじめに、現代では作家の多くが編集部や編集者との関係は概ね良好とみられ、私もその例に漏れず良好です。 賃金交渉は「闘争」と言ったりもしますが、まあ闘ってるわけでもありません。 あくまでも交渉です。 言葉の応酬の中で半端な発言をすることを避けたかったので、時間をかけて整理させてもらいました。 ここでこ...

    マンガの表紙に金が出ない件の話|デンノー忍者|pixivFANBOX
  • テキストコミュニケーションのコツ - そーだいなるらくがき帳

    これは元々社内ブログの記事なんだけど、テキストコミュニケーションについていろんなところで話すことが多いのでここに残す。 結論 背景をしっかり整えてから題を説明するようにしよう 省略しない お互いのスコープやフォーカスを最初に整理する 仮説と事実をちゃんと分けて明記して条件を整える お互いの知っていること、知りたいこと、わかってないことをちゃんと分けて整理する ボール交換が3往復以上したら同期的なコミュニケーションとして15分くらいとってすぐ会話する 要約 ローコンテキストなコミュニケーションをしよう! 意外とみんな 相手の背景 を知らない レスポンスで貰いたいものを明確にしよう! 参考資料 リモートワークにおけるファシリテーションの方法論[増補版]_COPILOT 部下や上司へのフィードバックに有効な「SBIモデル」とは? - 株式会社インヴィニオ 説明 SBIモデル SBIモデルとは

    テキストコミュニケーションのコツ - そーだいなるらくがき帳
  • 情報システム・モデル取引・契約書 | 社会・産業のデジタル変革 | IPA 独立行政法人 情報処理推進機構

    情報システム・モデル取引・契約書 情報システム開発におけるユーザ企業とITベンダ間の取引構造を透明化するため、DXの進展によるそれぞれの役割の変化等を踏まえた、それぞれが各開発段階で担うべき責務等の解説と、契約書のひな型を提供しています。 改正民法への対応内容はその後に公開した「情報システム・モデル取引・契約書(第二版)」に含まれますが、改正民法対応版作成に関する経緯等を含めた説明や第二版作成時に削除された参考資料を参照できます。

    情報システム・モデル取引・契約書 | 社会・産業のデジタル変革 | IPA 独立行政法人 情報処理推進機構
  • 強いチームと開発生産性

    2024-11-15 開発生産性Kaigi https://developer-productivity-engineering.connpass.com/event/332852/

    強いチームと開発生産性
  • なぜ「上司の説得」はムダなのか?|山口周

    よく「環境関連のビジネスを提案してるけど上司が認めてくれない」「クリティカル・ビジネスのアジェンダを提案しているけど会社が認めてくれない」という悩みを聞きます。 この悩みの先には、必ず「どうやったら上司を説得できますか?」という質問が来るのですが、常に答えているのは 説得というのは、人間がやる行為の中で最もROIの低い行為です ということです。ましてや「上司を説得する」などというのは、人生の無駄使いだろうと思います。 なぜ「上司を説得する」がムダなのか?マーケティングにおけるライフ・サイクル・カーブの理論を用いて考えてみましょう。 ライフ・サイクル・カーブの理論では、新しい製品・サービス・概念などは、次のような順序で社会に浸透していく、とされます。 イノベーションの浸透理論によれば、画期的な製品・サービスを最初に受け入れるのは「イノベーター」と呼ばれる人々で、これが社会全体の2.5%という

    なぜ「上司の説得」はムダなのか?|山口周
  • プロファイル結果の可視化三本勝負 in PHP

    speaker uzulla in "Laravel 勉強会 in 札幌 vol.3" https://larasap.connpass.com/event/193566/ ref: https://github.com/uzulla/xhprof-flamegraphs

    プロファイル結果の可視化三本勝負 in PHP
  • メンバー思い"風"マネージャー - Konifar's ZATSU

    自分は2020年に初めてマネージャーという役割になってしばらくの間、メンバーに寄り添う意識が強くてあまり職責を果たせていなかったと思う。「今思うと」という話で当時はそう思っていなかったのが黒歴史と言える。過去の自分のことを思い出しながら、この「メンバー思い"風"マネージャー」だった自分に向けたフィードバックを雑に書いてみる。 お前は"メンバーを守ること"が目的になっていて、経営や他部署との対立構造を自ら作ってしまっている。 たとえば、ビジネス上満たしたいリリースターゲットを共有された時、メンバーの負荷を勝手に想像して初手で噛みついてしまっているな。マネージャーとしてきちんと"断る"ことも仕事といった感じで、どこか使命感に近い感覚を持っていないか。お前がやっていることは、結果として経営との接続どころかむしろ最初のブロッカーのような立ち振る舞いにしかなっていない。 人事制度の変更アナウンスに対

    メンバー思い"風"マネージャー - Konifar's ZATSU
  • ドメイン名の終活について - JPAAWG 7th -

    2024/11/11〜12 に行われた JPAAWG 7th General Meeting で発表した資料です https://meetings.jpaawg.org/

    ドメイン名の終活について - JPAAWG 7th -
  • アジャイルを実践する組織であってもウォーターフォールを学ぶことには価値がある - mtx2s’s blog

    「すべてのライフサイクルモデルの祖は、ウォーターフォールモデルである」とは、スティーブ・マコネルの言葉だ1。また、ソフトウェア開発ライフサイクル(SDLC)に関するGitHubの文書では、広く採用された最初のSDLCがウォーターフォールモデルであるとされている2。 そこに、ウォーターフォールを学ぶことに対する価値がある。それは、スクラムを導入し、アジャイルソフトウェア開発を実践する組織にも言えることだろう。いや、そうであるからこそだ。どんなソフトウェア開発プロセスモデルであろうと、ウォーターフォールから派生したり、何らかの影響を受けていると考えられる。したがって、ウォーターフォールへの理解から、自分達がやっていることの質を見いだせるのではないだろうか。 ウォーターフォールなんて誰でも知っていると思うかもしれないが、そうとも限らない。確かにウォーターフォール未経験のソフトウェア開発者は少な

    アジャイルを実践する組織であってもウォーターフォールを学ぶことには価値がある - mtx2s’s blog
  • フロントエンドフレームワークからサーバーにアクセスするパターン | フューチャー技術ブログ

    僕が触り始めた頃のウェブフロントエンド開発はデバッガーもなく、ダイナミックHTMLと呼ばれて文字をチカチカさせたりするようなものでした。IE6という超安定ブラウザが出てきたり(Netscape 4.xも7.xも不安定だった)その後jQueryが登場したときは、天使が降臨したように思えたものです。 そこから長い年月が経ち、ウェブフロントエンドの比重が大きくなるにつれ、フロントエンドのコードはどんどん複雑化しました。OpenAPIなどのコードジェネレータなども普及した結果、通信というものが隠され、イベントの中でawaitや.then()で呼ばれる何か、みたいな理解をしているメンバーも今後増えていくのではないかという懸念があります。 現在ではウェブフロントエンド開発はReactVueといったフレームワーク上で行われ、イベントというのはそのフレームワークの提供するライフサイクルイベントに対応付け

    フロントエンドフレームワークからサーバーにアクセスするパターン | フューチャー技術ブログ
  • マネージャーが「面倒なことをやってくれる人」と思われないためにやること - パウリのしこう

    マネージャーは「面倒なことをやってくれる人」なのか 最近マネージャーな方を「面倒なことをやってくれる人」として認識されていることがあります マネージャー自身が「そう思っていますーハハハ」と言っていることもありますし、「マネージャーって開発に関係のない面倒なことをやる役割でしょ?」って言われることもあります なんなら「面倒なことはマネージャーが全部やるからさ」とメンバーに言っている場に居合わせたこともあります マネージャーは「面倒なことをやってくれる人」なのでしょうか 「面倒なことをやってくれる人」と思われる背景と影響 「面倒なことをやってくれる人」として扱われているマネージャーの共通点を自分なりにまとめたところ、自身の業務を明示していないのではないかな?と思いました 自身がやっている業務を自身で説明できない or しないため、その専門性やキャリアを示すことができない状態です 結果としてメン

    マネージャーが「面倒なことをやってくれる人」と思われないためにやること - パウリのしこう
  • タスクを完了したら抜けるSlackチャネル - Konifar's ZATSU

    複数人に必ずやってほしいタスクがある時、『そのタスクが終わったら各自抜けるSlackチャネル』を作る運用にすると楽。最近試験的に"月の勤怠を提出したら抜けるチャネル"を Zapier で自動作成するようにしたので雑に書いておく。 Zapier はこんな感じで組んで、毎月1日10時になったら前月分の勤怠提出を促すための #tmp-kintai-YYYYMM チャネルを作成してメンバーを招待する。 で、11時、15時、19時に自動でリマインドし続けるだけ。若干無駄に Action を消費する Zap になっているので改善すべきだとは思う。 毎月ちゃんと提出してくれる人にはうざったいだけなので、そういう人は自動招待の対象から外していっている。だんだんと対象人数が減ってきているので、最終的にはこの仕組み自体が不要になればいいと思う。あと、欲を言えばこういうしつこく強制力のつよいリマインド機能自体は

    タスクを完了したら抜けるSlackチャネル - Konifar's ZATSU
  • 「なぜ30%値下げできないの?どれくらいなら下げられるの?」「できるか、できないかで答えてください」と高圧的に言われたらどうするか?『戦略的交渉入門』

    「その価格では厳しい、30%下げてほしい」 と、初手から無理な数字をふっかけてくる。それは難しいと答えると、 「なぜですか?どの程度なら下げられますか?」 と畳みかけてくる。答えに窮すると、 「できるのか、できないのか、答えてください。できないなら議論は終わりです」 と言い放つ。 価格交渉や要件定義の場で、高圧的な態度で話す人がいる。相手を説き伏せ、自分の思い通りの結論に持っていきたがる。一方的にまくし立てて、質問に質問を重ね、相手に話す機会を与えない。 典型的なパワープレイ、二分法、アンカリングの交渉術である。これらはビジネス上の技法であることを、そもそも知らなかった若いころは、さんざんやられたものだ。顧客だけでなく営業や上司からもやられたことがある。 そして、交渉の「術」だから対策がある。『戦略的交渉入門』には、こうした交渉「術」への対策がふんだんに盛り込まれている。 「なぜ30%下げ

    「なぜ30%値下げできないの?どれくらいなら下げられるの?」「できるか、できないかで答えてください」と高圧的に言われたらどうするか?『戦略的交渉入門』
  • 【JavaScript】関数名をclose()にするのは気をつけろ

    単なる自分のやらかしの共有です。この記事は事実をもとにしたフィクションです。 消し忘れたclose()関数 あるときモーダルコンポーネントを閉じる、close()関数というのを作りました。後日、リファクタリングをするときこの呼び出されているclose()関数がとあるコンポーネントから取り除かれることになりました。しかし誤って1つ削除し忘れてしまい、close()関数が取り残されてしまいます。 このとき、import文なども取り除かれたのですが、何故か未定義エラーなどは出ずに見過ごされてしまいました。(察しの良い人はピンとくるかも) 何故か消えるウィンドウ そんな中、消し忘れたコンポーネントを含む画面で特定の手順を踏むと開いたブラウザウィンドウが閉じてしまう現象が確認されるようになりました。 どうやら発生源は先程のリファクタリング作業らしい… window.closeというJavaScrip

    【JavaScript】関数名をclose()にするのは気をつけろ
  • 経営者から見た"開発生産性向上"の違和感に向き合う

    こんにちは。PharmaXの上野(@ueniki)です。 2024年10月31日、PharmaXはFindy Team+ Award 2024のSmall Divの部(エンジニア組織が50人未満)を受賞しました! この賞は開発生産性向上に関して優れた取り組みを行った企業に贈られるものです。 この賞も今年で3年目を迎え、開発生産性という言葉が何となく日IT企業に受け入れられてきているように感じます。 特にスタートアップで、ソフトウェア開発に携わっている方は、一度は"開発生産性"という言葉を聞いたことがあるのではないでしょうか。 ですが、開発生産性という言葉自体は聞いたことがあるものの、よく分かっていないという言葉を聞くことも少なくはありません。 "開発生産性向上"というと、響きは素晴らしいものの、当に意義のある活動なのでしょうか? 「そもそも開発生産性とは何なのか?」 「開発生産性を向

    経営者から見た"開発生産性向上"の違和感に向き合う
  • 著者の一言:マネジメントは嫌いですけど

    「マネジメントなんてやりたくない。部下やお金や人事評価の面倒なんて見たくない」 そんな声をよく聞きます。まったくもって同意します。 しかし,「⁠やりたくない」というのなら,マネジメントはいらないのでしょうか? Googleは,2002年にすべてのマネジメント職を廃止するという実験をしています。2008年には,マネジメント職は重要な存在ではないという意見を証明しようとして失敗しています※。 ※re:Work マネージャーより 私は,「⁠技術職を経験しているマネジメント」の人間がもっとたくさん,自然に増えるといいと願っています。なぜなら,技術者の常識が,マネジメントに必要だからです。 問題点や失敗する可能性を隠さずオープンにするほうが健全で安全である 自分の望むことと自然界で発生することが一致しない 自分の成果を他人に批評してもらってこそ自身の知識が深まる 自分には知らないことがあることを知っ

    著者の一言:マネジメントは嫌いですけど
  • TypeScript - use correct version of setTimeout (node vs window)

    I am working on upgrading some old TypeScript code to use the latest compiler version, and I'm having trouble with a call to setTimeout. The code expects to call the browser's setTimeout function which returns a number: setTimeout(handler: (...args: any[]) => void, timeout: number): number; However, the compiler is resolving this to the node implementation instead, which returns a NodeJS.Timer: se

    TypeScript - use correct version of setTimeout (node vs window)
  • ハウスミュージック史上最も重要な曲10選

    1.Strings of Life Derrick May言わずと知れた超絶名曲。 ハウスかテクノかと問われたらジャンル分けが難しい部分もあるが、今回はハウスカテゴリに入れさせて頂きたい。 2.Can You Feel It  Mr Fingersハウスミュージックの歴史を語る上で外すことのできない1曲。ここから全てが始まったと言っても過言ではなかろう。 3.Gypsy Woman Crystal Waters様々なバージョンが出ている名曲。聴けば「これが元ネタか!」となる人も多いだろう。 4.Sweetest Day Of May ジョー・T・ヴァネリDJ EMMAさんが毎月5月に必ずかけていた曲として思い出深い人も多いだろう。 フロアの聴衆は必ず「スイスイスイスイ」と合唱していた記憶がある。 5.We Got The Love Touch Of Soul2006年にリリースされたInn

    ハウスミュージック史上最も重要な曲10選
  • 小学校の頃の仕組みに学ぶ - Konifar's ZATSU

    今思い返すと小学校の頃の色々な決まりごとはよくできていて、"大人"の組織にも適用できること多いよなと思うことがある。 ジェネレーションギャップもありそうだが雑に書いてみる。 帰りの会 いわゆる"夕会"だよね。大事な連絡事項を漏らさず伝えて、皆で話し合うべきことがあれば話せている。そういう場が定期的に必ずやってくるのは大事。 係活動 "勉強"という主目的以外に必要な取り組みをうまく分割して役割として任せて自律させている。大人になった今、組織目標に囚われて必要な取り組みを"差し込みタスク"のように扱っていないだろうか。必要なことであれば、"いきもの係"的に切り出して取り組めるように設計するといいかもしれない。 日直 リードをローテーションして皆が均等にできるようにしている。ある程度マニュアル化されており、たいてい2人ずつアサインされるところもいい仕組みだと思う。小学校の日直でできていたなら、定

    小学校の頃の仕組みに学ぶ - Konifar's ZATSU