しくじりエンジニア！私みたいになるな！ - Qiita 人間であれば誰しも「しくじったこと」が一度はあると思います。 あなたがエンジニアとして「しくじったこと」で思い浮かぶものは、どんな内容でしょう? を思い浮かべてのポエムです...。もちろん具体的な誰かの顔をイメージする記事ではないですが、社会人も 20 年そこそこになると「余計なこといっちゃったなー」とか、「うわあああ！ (頭の中で後悔)」とか、後になって胸にチクっとくる場面を、(割と)(これでも)(幾度となく) 経験しています。 Unsplash 本番サーバー60台のホスト名を全部 cat にしてしまった話 #Linux - Qiita とか、WHERE 句を付けずに DELETE 文を流すとかも記憶のどっかにあるけど、言うて対システムの失敗は「(せいぜい数週間) 頑張れば」どうにかリカバリできることの方が多いのではと感じます。 一

グレース・ホッパー - Wikipedia Grace Hopper - Wikipedia “アメージング・グレース” , グレース・ブリュースター・マレー・ホッパー (Grace Brewster Murray "Amazing Grace" Hopper, 1906年12月9日 - 1992年1月1日) は、アメリカ海軍の軍人かつ計算機科学者。75歳で退役、最終階級は准将。プログラミング言語COBOLを開発した。 Image COBOLの母、「グレース・ホッパー」です。こんなCSSアート作品もあるようです。 See the Pen Single Div Grace Hopper by Tricia Katz (@triciaakatz) on CodePen. ともかく、リアルコンピューターおばあちゃんと言える位カッコイイのです。 名言 おばあちゃんの名言。 9 Grace Hopp

「暴言吐かないように気をつけます」 暴言暴言書いているので念のためBOSS（社では執行役員ともいう）のお名前はマスキングしています。弊社の開発部のトップリーダーに彼自身の「分報」を開設させる、という今年前半の社内コントリビューションを自慢するために書いています。 関連: Developers Summit 2022に登壇したので、その感想🍬 - Qiita 「弊社の執行役員に、#times_役員 なSlack分報を開設させるまでにやったこと全部書く」。BOSSは尊敬している。だからこそもっとBOSSと気楽に話したい、仲良くなりたい、BOSSの考えていることを知りたい、でも話しかけるのは緊張しちゃう、いつでも話していいよ？ムリ～～... そんな悩みをもつ方やチームの参考になれば嬉しいです。 結論: 地道なお互いの信用獲得。それは狩猟ではなく農耕 結論から。地道にお互いと全方位的な信用獲得を

製品哲学、なにそれおいしいの 「あなたが、あなたの製品をつくる際、最も大切にしているものは、何ですか」 品質？ 機能？ リリースすること？ 締切を守ること？ オカネ？ チケットの仕様を満たすこと？ 承認欲求を満たすこと？ どれも正解かもしれません。正解だと思います。というか個人開発なら大正解だと思います。さてもう一つの質問です。 「我々製品開発が自社の製品をつくる際、最も大切にしているものは、何ですか」 。。。 答えられる方はいますか。 。。。それはシャチョーが決めることでは。 そうですね。正解だと思います。というか私もそう思います。しかしあなたがシャチョーだったら、あるいは、シャチョーがあなたに 「ウチの製品開発がウチの製品の『最も大切にしないといけないもの』を決めるんや！期限は1ヶ月や！」 などと言い出したらどうしますか。 via GIPHY ――この記事はフィクションです。が、そんな

話題の 良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方 | 仙塲 大也 |本 | 通販 | Amazon の読書感想文です。 SNS時代ならではの本だと感じた まず驚いたのがこの本冒頭、#ミノ駆動本 とハッシュタグのガイドが書かれています。 本書のSNSでのハッシュタグは #ミノ駆動本 です。本書の感想などを投稿するとき、ぜひお使いください。 なるほどこうして体験を共有することを最初から想定しているのだな～、と (本筋と少々ズレたところで) 感服しました。ということでお祭りに参加するつもりで書き留めています。 リファクタリングを勧善懲悪で、ゲーミフィケーションした痛快な攻略本だと思った 「クソコード動画」やゲームがむしろアイディアの核にあり、技術的根拠詳細が語られている本と考えると、余計なるほどな、腹落ちするところ多数でした。誤解を恐れず書くならば、むしろ

システム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション | Jeffery D. Smith, 田中 裕一 |本 | 通販 | Amazon エンジニアがDevOpsで解決する組織・自動化・コミュニケーション。早速お薦めしたく書いています。読書感想文です。 感想5点 良いぞ。周りに薦めたい 百聞一見。目次だけでも: https://www.oreilly.co.jp/books/9784873119847/#toc 特に自分にとって良かったのは以下 9章　せっかくのインシデントを無駄にする 10章　情報のため込み：ブレントだけが知っている だが、一番スゴイのは11章かもしれない 「文化を変えようと思うのであれば、文化がどのように共有されているかを理解すること」 コロナ以前は 議事録 会議 机横での雑談 飲み会 タバコなどなどあったが コロナ以降、リ

はじめに DeepL翻訳をはじめとしたテキストコピペ系Webサービスは機密情報の扱いに注意しよう - Qiita 長文要約生成APIを利用する前に気をつけたいこと - Qiita 記事やソースコードを公開するときに気をつけていること - テックブログガイドライン - Qiita 他、ツールの利用は社内規定を確認しましょう。以下そのうえで日常おすすめするツールです。流行り廃りあるかもなので2022春と書きました ツール達 エディタ テキストエディタはどれが良いだろうか - Qiita を参考。 サクラエディタ TeraPad 公式ダウンロードサイト Oedit Typora — a markdown editor, markdown reader. Obsidianで日々のローカル秘蔵メモを取り込んでみたらNotionより自分好みに使えそうだった - Qiita Markdownはいいぞ。脱

「対応」という言葉を使うのはできる限りやめよう。ではなくて 具体的に何をするのか書こう 「サポートする」ならサポートレベルを示そう 答えるだけなら「応対」だよ 対応とは たい‐おう【対応】 ［名］(スル) １ 同種の二つのものが向かい合い、対(つい)になっていること。「四辺形の互いに対応する角」 ２ ある物事が、他の範疇(はんちゅう)に属する物事と、対立・相当する関係にあること。「ギリシャ文字のα(アルファ)は、ローマ字のaに対応する」 ３ 互いにつりあいがとれていること。「文章の書き出しと結びを対応させる」 ４ 周囲の状況などに合わせて事をすること。「現実に対応した処置」「対応策」 ５ 二つの集合A、Bがあって、Aのどの要素にも、Bの要素が少なくとも一つ定まる規則があること。ふつう、AからBへの対応という。 なにかをする、くらいの意味にしかなっていない...。 障害対応とは 障害を検知

読書感想文です。 感想 「FAQの書き方を学ぶ UX×テクニカルライティング勉強会 #5」を視聴したので、その記録 - Qiita にて読みたくなった本。 コールセンターの1回の問い合わせ対応コストは1回1200円らしい...月に10000問い合わせ来ていたら1200*10000円 ということ https://www.tactinc.jp/article/callceter-cpc FAQ整備に1月100万でも予算をかけてコール数を30パー減らせれば十分お釣りが来る ... ということでFAQの整備で効果を上げることの戦略が具体的に考えられる点でも読んで十分お釣りが来る本である。 要点 第1章：FAQはなぜ重要なのか 1.1　FAQの存在意義 お客さま向けFAQサイトとして カスタマーサポートにかかるコストの課題を解決する 顧客満足度と企業評価を上げる オペレーターのストレスを緩和する ユ

心理的安全性という言葉に手垢がつきすぎている気がして既に混乱してきてしまったので頭を整理するために書いているものです。冒頭に結論を書いておきます。 心理的安全性の高い状態の達成とは、「失敗」を「むしろ自分にとっておいしい。おもしろい」に変換できている状態を指す。 集団としては、失敗を称賛する文化ができたチーム、と言い換えても良い。 記事の表題に至る過程を以下説明します。 おさらい 心理的安全性 とは サイコロジカルセーフティ（psychological safety）... Psychological safety - Wikipedia Wikipediaによれば以下である。 チームが対人関係のリスクを取っても安全だという共通の信念 心理的安全性の高いチームでは、チームメンバーは受け入れられ尊重されていると感じている。また、グループダイナミクスやチーム学習の研究において、最も研究されてい

というタイトルの面白そうなポエムを見つけた。「デイリースタンドアップミーティング（デイリースクラムとして知られている）は、次のようなやり方で行われると無駄になる。」というもの。 全員がTrelloやAsana、JIRAのボードを見つめ、PjMやTechLeadが各チームメンバーに作業中のチケットに関する質問を投げかけ、以下のような会話が起こります。 (PjM) ジョン、チケットXYZの進捗状況はどうですか？ (John) いい感じですよ。あれもやったし、これもやったし、ほとんど終わったよ。あとは最後の仕上げで、コードを磨いて、いくつかテストを追加するだけだ。今日中に完成させなければなりません。 (PjM) 素晴らしい、次に進みましょう。マリアさん、あなたのチケットの状況はどうなっていますか？ (Maria) ボブが私のプルリクエストをレビューしているので、コメントがない限り、私はこれで終わ

再発防止策を書くのは難しい。 良い再発防止策 良い再発防止策について、順位付けするとしたら、 その種類の問題について二度と意識することがなくなる解決策 その種類の問題を開発時に自動的に検知することができる解決策 その種類の問題が発生しても自動的に復旧することができる解決策 その種類の問題が発生しても影響が局所化される、フールプルーフ、フェールセーフになる解決策 と言うのは意識したいと思いつつ、やはり難しい。 再発防止はむずかしい 障害の再発防止策は、 メカニズム ツール ルール チェックリスト の順番に検討せよ。と言われても、急いで書けなんて言われると「次回からは複数人でチェックします。」とか「チェック項目を追加します。」とかいう徹底できなそうな「反省文」になってしまう。 まさにこの有名な猫...。 **「なぜミスを繰り返すのか」「どうすればミスを防げるのか」を真剣に考えていないことがミス

の続編のようなポエム。 「できるかできないかわからない状態」の物事に対して「いつまでにならできますか？」という質問を受けることがある（非開発者含む）が最上級に難しい質問であることをとりあえず知ってほしい、というのは愚痴。 多分相手は単純に、「抱えているのは量の問題だ」という感覚があって、明日までにできないっすと答えた私に対して「なら来週月曜までにならできますか？」（えっそれ営業日で1日も伸びてねえ）とか（むしろ、期限を延長してくれたかのように）返してくれているのだと思っている。 違うんだよそれ以前なんだよな～、と思いつつ、そう簡単にその気持ちが伝わるわけはないのでそういうときにどうするべきなのかを考える。 見積もりはむずかしい 「なぜ見積もりは難しいのか？それはあまりにも不確実性が多いからだ。」。不確実性を減らすには だが、下から上への情報の透明性 なんてものもあるし、ともかく「距離」のあ

はじめに 対象読者は以下です。 開発チームが日常何をやってるかわからんという方。 開発チームが日常何をやってるかわからんという方が周りにいる開発チームの方。 以下に答えるのが目標です。 誤解1: 「こんなの一瞬で直せるでしょー」 誤解2: 「優先順位付け独特すぎて困るー」 誤解3: 「開発チームって複数のタスク同時進行して切り替えて作業しててスゴイです！」 「なぜ開発チームは私の起票した要望をなかなか実装してくれないのか」と疑問を他部署から受けている。案件精査バトル（何）なる野蛮な闘いが開発チーム内では日々起こりそれが顧客要望を裁いているという噂。いやそれそんな単純じゃあないんすわ…とおもったので、物語式にこの理解され難い葛藤と異常な日常業務をまとめた。一般的なものもあるかもしれないし、私の周りに独特すぎることもあるかもしれない。でももし再利用いただけたら嬉しい。 開発チームが毎月繰り広げ

表題に他意はなく、単に興味を持った「Buy me a coffee」を日本語にしたらそういう感じなのかな、というところです。記事の結論を先に書くと「金銭」とまでは言わずとも、「お礼」や「応援」の気持ちは、普段から開発者同士もっと表明して送っていきたい。そういう気持ちを改めてもったという話。 Buy me a coffee、Qiita記事でも紹介されていた。以下。 モノの試しに自分でもBuy me a coffeeアカウントを作ってみた。しかし何かを作ることとお金、もう少し話を広く表現すると「報酬」「対価」の話は各媒体、それぞれ戦略や考え方がある。 「お金を稼ぐ」ことにまつわる各コミュニティ等のお話 例: Qiita 実際、そういえばとおもったのでQiita本営へ問合せた。Qiitaに投げ銭サービスリンクは貼れるのか。端的に以下回答を頂いた。 アフィリエイトや欲しいものリスト、投げ銭を受け付

モダンなWeb用ウィンドウマネージャ：軽量、優れたパフォーマンス、依存関係なし、完全にカスタマイズ可能、オープンソース (公式説明をDeepL翻訳) だというWinBoxというjs、まだ若いもののようだが触ってみた。 GitHub: https://github.com/nextapps-de/winbox 例えばURLセットして開くならこれだけ。 var winbox = new WinBox("Custom Color and Open URL"); winbox.setBackground("#ff005d"); winbox.setUrl("https://e99h2121.github.io/") var winbox = new WinBox("Custom Color and Open URL"); winbox.setBackground("#ff005d"); winbo

What are the biggest delusions that computer science students have? というQuoraの質問にあった画像。 ...を出オチのようなところに、Life of a Programmer in Simple Jokes That Will Make You Laugh (プログラマジョーク集) およびそのリンクから集めてしまったジョーク、meme等です。 趣旨 基礎的なプログラミングと英語の知識がある人がクスッとできるかもしれない meme です。プログラミング知識は増えません。自分の英語やエンジニアリングの知識をテストする程度ですが、息抜きに。 meme (ミーム) とは、ネタの意味が分かるとクスッとしてしまう画像のこと。 海外で通用するエンジニアがクスッとしてしまう17の meme 、エンジニア向けMeme　も過去記事参考です

自身のプライオリティによりますが、いくつか。 Markdownで幅広く再利用性を利かせたい、長期的に丁寧に版管理したい 自分自身の操作性、描きやすさと、見た目 俄然手軽に、短期的に、Onlineでいつでもどこでも いずれかという視点で考えると良いのかなと思い、並べてみました。 1. 長期的に: Markdownで幅広く再利用性を利かせたい、丁寧に版管理したいなら Markdownで描くことのメリットは再利用性。 将来的に追記・編集、自分以外の誰かが手を入れる可能性が高い。 現在のドキュメントだけでなく多種説明資料、媒体に転用する可能性がある。 ...という点で差分管理をしたいなら、以下。 VSCodeでPlantUML、Mermaid 上記参考で以下。 Alt+D でプレビュー起動。 Ctrl + Shift + P でコマンドパレットを起動し、出力。 png, svg, eps, pdf

図解入門 よくわかる最新システム開発者のための仕様書の基本と仕組み[第3版] | 智明, 増田 |本 | 通販 | Amazon より、要点、キーワードをメモしたもの。 システム開発全体の流れ とは プロジェクトの流れ 時間軸 要求定義 要件定義 設計工程 外部設計 内部設計 検証 実装工程 試験工程 納入 マイルストーン 成果物の流れ 要件定義での成果物 設計工程・検証での成果物 実装工程での成果物 試験工程での成果物 それぞれの工程を結びつける成果物 情報の流れ 要求定義・提案書 要件定義 基本設計 外部設計 内部設計 実装工程 試験工程 サンプル Markdownで表現すると以下のようになる。 ## はじめに 要求定義の前置きを書く。 ## システム構築の目的 - システム構築をする際の目的 ## システム構築の制限事項 - システム構築をする際の制限事項を記述する。 - 移行プロジ

「正直９年経ったいまでもfor文ググってる」 という議論記事があった。正直なところ私もググる方の人だ。私の感想: ポンとテキストエディタだけ渡された時に書けるか自信ないぞ...IDEがあればまあ大丈夫かなあ。 JavaScriptだけじゃない。言語色々扱うしという言い訳。正規表現とか毎度調べる。 だから世の中にチートシートというものがあるのだ。お気に入りチートシート多数。 実戦でどうしているか？結局周りのソースを見て馴染む書き方にしていますよ多分。 暗記するかしないかは受験勉強みたいなもので、コーディング面接に受かるなら必要。暗記そのものには意味はないとは思う。 競技プログラミングが使えないとかいう論もあったな。 ググり力も大事。 でも「最低限」もできないのはやはり恥ずかしい気持ちはある。 なんかこれ英語できるできないと似てるな。英語なんてGoogle翻訳、DeepL翻訳あればいいけど、実