サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
中東情勢
qiita.com/e99h2121
再発防止策を書くのは難しい。 良い再発防止策 良い再発防止策について、順位付けするとしたら、 その種類の問題について二度と意識することがなくなる解決策 その種類の問題を開発時に自動的に検知することができる解決策 その種類の問題が発生しても自動的に復旧することができる解決策 その種類の問題が発生しても影響が局所化される、フールプルーフ、フェールセーフになる解決策 と言うのは意識したいと思いつつ、やはり難しい。 再発防止はむずかしい 障害の再発防止策は、 メカニズム ツール ルール チェックリスト の順番に検討せよ。と言われても、急いで書けなんて言われると「次回からは複数人でチェックします。」とか「チェック項目を追加します。」とかいう徹底できなそうな「反省文」になってしまう。 まさにこの有名な猫...。 **「なぜミスを繰り返すのか」「どうすればミスを防げるのか」を真剣に考えていないことがミス
自身のプライオリティによりますが、いくつか。 Markdownで幅広く再利用性を利かせたい、長期的に丁寧に版管理したい 自分自身の操作性、描きやすさと、見た目 俄然手軽に、短期的に、Onlineでいつでもどこでも いずれかという視点で考えると良いのかなと思い、並べてみました。 1. 長期的に: Markdownで幅広く再利用性を利かせたい、丁寧に版管理したいなら Markdownで描くことのメリットは再利用性。 将来的に追記・編集、自分以外の誰かが手を入れる可能性が高い。 現在のドキュメントだけでなく多種説明資料、媒体に転用する可能性がある。 ...という点で差分管理をしたいなら、以下。 VSCodeでPlantUML、Mermaid 上記参考で以下。 Alt+D でプレビュー起動。 Ctrl + Shift + P でコマンドパレットを起動し、出力。 png, svg, eps, pdf
Why doesn’t Japan excel in software as they did in hardware? (なぜ日本はハードウェアの時代と同じようにソフトウェアに秀でることができない?) という英語Quoraのやり取り、分析が興味深かったので、まとめ。 仮説1: 日本は完璧を求める 10人のエンジニアのソフトウェア開発会社を経営しているフランス人の友人が、ルイ・ヴィトン日本支社のコンピュータシステムのマネージャーと同意した話:ソフトウェアはハードウェアではなく、産業用でもない。50年間同じトヨタカローラのように構築され、洗練され、完成されたものではありません。ゼロバグでそれを「完璧」にすることは不可能であり、したがって、「ゼロデフォルト」という、総合的な品質、継続的な改善を求める日本人の精神に反するものです。 日本は職人の国であり、漢字を書いたり、折り紙を折ったりする技術を
身につまされる英語力問題。手っ取り早く英語を習得するなら海外に行ってしまうが最善なはずですがこのコロナ禍、身近なところで英語に触れつつ技術も勉強したい?といえば、動画です。 10 Developers You Should Follow to Improve Your Skills (スキルを上げるための、フォローすべき開発者10選) という記事があったので10人をまとめた。プラスオマケ。それぞれ実際に動画を見てみての補足付き。 1. Ben Awad (ベン・アワド) ソフトウェア開発者。React、React Native、GraphQL、Typescript、Node.js、PostgreSQL、Python、その他あらゆるコーディングについて紹介。React.jsやGraphQLの開発者にお勧め。ビッグ/テック コーディングインタビューの準備を手ほどきしている。「アルゴリズム形式の
伝えたいことは全てタイトルに書いた。 動機 https://github.com/topics/awesome を眺めていて本当にawesomeなものばかりだった (割にあまりどこにもそのawesomeさが書かれていないように見えた) ので書く。 awesomeリストとは GitHub で使われる慣習的なリポジトリについてまとめてみた#awesome より: 「特定テーマに関するキュレーションを行うリポジトリ。Markdown のリスト表記で一覧化するのが一般的。また、Contribution も受け付けている(人気のあるリポジトリはガイドラインも厳しめ)。」 Where? ここのことです: https://awesome.re/ 画像はリポジトリから引用。 What? What is an awesome list? よりDeepL翻訳 awesome マニフェスト もしあなたのリストを
「正直9年経ったいまでもfor文ググってる」 という議論記事があった。正直なところ私もググる方の人だ。私の感想: ポンとテキストエディタだけ渡された時に書けるか自信ないぞ...IDEがあればまあ大丈夫かなあ。 JavaScriptだけじゃない。言語色々扱うしという言い訳。正規表現とか毎度調べる。 だから世の中にチートシートというものがあるのだ。お気に入りチートシート多数。 実戦でどうしているか?結局周りのソースを見て馴染む書き方にしていますよ多分。 暗記するかしないかは受験勉強みたいなもので、コーディング面接に受かるなら必要。暗記そのものには意味はないとは思う。 競技プログラミングが使えないとかいう論もあったな。 ググり力も大事。 でも「最低限」もできないのはやはり恥ずかしい気持ちはある。 なんかこれ英語できるできないと似てるな。英語なんてGoogle翻訳、DeepL翻訳あればいいけど、実
「Markdownテンプレート」シリーズの目次です。 Markdownで全ての社内文書 GitHub Flavored Markdown推し 段落 Markdownで設計 Markdownでリリースノート Markdownで報告書 Markdownで職務経歴書 Markdownでスライド Markdownで会議 Markdownで校正 終わりに 以上、各記事が参考になれば幸いです。
はじめに 以下おすすめする技術書達です。分類に迷うものありつつ、流行り廃りあるかもなので2022春と書きました。 技術書達 基本 プログラムはなぜ動くのか プログラムはなぜ動くのか 第3版 知っておきたいプログラミングの基礎知識 | 矢沢 久雄 |本 | 通販 | Amazon 2000年代から推されている基本情報技術者レベルの本 イラスト図解式 この一冊で全部わかるWeb技術の基本 イラスト図解式 この一冊で全部わかるWeb技術の基本 | NRIネットコム株式会社, 小林 恭平, 坂本 陽, 佐々木 拓郎 |本 | 通販 | Amazon Webの全体像から、HTTPでやりとりする仕組み、さまざまなデータ形式、Webアプリケーションの開発、セキュリティ、システムの構築・運用まで、これからWebにかかわる人が知っておきたい知識をこの一冊で丸ごと解説! リーダブルコード リーダブルコード ―
システム運用アンチパターン ―エンジニアが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はいいぞ。脱
1200人以上の全社員がリモートワーク。GitLabが公開する「リモートワークマニフェスト」は何を教えているか? スケールする組織を支えるドキュメンテーションの技術を”GitLab Handbook”から学ぶ その コメント GitLab Handbookで面白かったもの@コミュニケーション編 GitLabのリモート統括責任者が語る 日本企業が「まずやるべきこと」 を読んだ。主題はGitLab社の https://about.gitlab.com/handbook/ である。 2022.02追記 GitLabで学んだ最高の働き方 Developers Summit 2022-02-18 2022.01追記 リモートワークのいま学びたい、GitLab Handbook非同期コミュニケーションのススメ - Qiita Handbook要点 「GitLab社ではリモートワークの中でも生産性高く働
Markdownを社内に布教したい、というモチベーションからMarkdownを勧める理由をまとめたもの。 同じようなことを考える方へ、周囲への説得材料になると嬉しい。 1. Markdownを勧める理由 1-1. 圧倒的理由 全人類がマークダウンを学習すべき理由|情報デザイン力を鍛えよう Markdownとは (日本語Markdownユーザー会) をMarkdownで引用する。 Markdown(マークダウン)は、**文章の書き方**です。 デジタル文書を活用する方法として考案されました。特徴は、 - 手軽に文章構造を明示できること - 簡単で、覚えやすいこと - 読み書きに特別なアプリを必要としないこと - それでいて、対応アプリを使えば快適に読み書きできること などです。 Markdownはジョン・グルーバー(John Gruber)によって2004年に開発され、 最初は [Darin
GitLab社のGitLab Handbookと徹底した文書化、組織的なオープンネス(?)を先日調べたのだが、じゃあ同じように見える化、透明性をアピールしているツールが何か?と考えた際ににSlackがあると思っている。SlackといえばDM禁止!オープンな職場が良し!風通し良し!なやつである。 しかしそれを実際会社で根付かせようとした時に、Slackの使い方を説くだけでは足りなくて、むしろ皆の意識改革みたいなものが必要だな~とひしひし感じさせられる。オープンな会社が良いかクローズドが良いか、「チームの風通しは良いほうが良いのか?」 世の中ひねた人も居るもんで風通しだけ良くてもこんなデメリットが有るなんて言われる 意見は増えても、内容が浅い 意見の浅い深いを確認する手間がかかる 浅い意見でも対応しなければならない 多数派の浅い意見に流されがちになる https://factory-learn
npm のちょっとしたオプションについては以下を参照。 Step.1 本体と最低限のルールをインストール 任意のフォルダを作成。 C:\workspaces\textlint_work cd C:\workspaces\textlint_work npm init -y npm install --save-dev textlint textlint-rule-preset-ja-spacing textlint-rule-preset-ja-technical-writing 上記で、textlint 本体 + プリセット2つをインストールする。 preset-ja-spacing preset-ja-technical-writing npx textlint --init で、.textlintrc が生成される。 Step.2 追加のルールをインストール 上を参考に入れてみる。 n
最近自分の周りで「スキルマップ」というものを作ったり 新卒の子にどこまで勉強すれば良いですかね?と聞かれた件 ロシアの天才ハッカーによる【新人エンジニアサバイバルガイド】 というような記事を見つけたりしたので、考えたことを視覚化してまとめてみた。 ##スキルマップとは 人のスペックを表現する箱がこのようにあったとして ###図1. 箱 便宜上Frontend, Backendとかいう方向性があるとします。 ###図2. 分野、方向性 ###図3. 1年目- 例えば「バックエンドを1年位経験しました」。 ###図4. もっとやってる1年目- 例えば「『フルスタック』で1年位経験しました」。 ###図5. のらりくらりと5、6年- 例えば「バックエンドだけ5, 6年やっていました」。 などと表現されるとする。 実際は 濃淡があると思う。 ###図6. バックエンドの便利屋、3年選手- こんなだ
概要 定型的な システム開発 では以下のような設計書が使われる。 システム要件定義 システム方式定義 ソフトウェア要件定義 ソフトウェア方式設計 ソフトウェア詳細設計 しかしそれ以前に 開発者目線、開発者発信で顧客に提案する概要資料を作りたい ケースがある。あるいは就職活動時の自身のポートフォリオを採用担当に説明することも同様かもしれません。 オードリー・タンがコード書く前にまずreadme.txtを書く話、Yahoo!がプロダクト開発の最初にプレスリリースから作る話、自分が前職で商品企画する際にまず広告から考えていた話、どれも明確なゴールイメージをまず確定させて必要要件を定義していくという意味で全部共通の考え方 — 菅俊一 / Syunichi SUGE (@ssuge) February 2, 2021 なんて話も。 技術とマーケティングのちょうど中間、開発者と顧客との意思疎通の橋渡し
流行っているらしいのでやってみた。 10 Trending projects on GitHub for web developers - 12th March 2021 GitHub その後、Sweetalert2 を見つけたので、追記。// 2021/04/05 お試し See the Pen SweetAlert by YAMADA Nobuko (@e99h2121) on CodePen. See the Pen SweetAlert2 by YAMADA Nobuko (@e99h2121) on CodePen. <script src="https://unpkg.com/sweetalert/dist/sweetalert.min.js"></script> <button type=“button” onclick="basicSample()">やさしいアラート</b
動機 Webフロントエンド開発で役立つサービスまとめ#Codepen および CSS Art Resourcesを読んだ。Codepenは、 HTML、CSS、JavaScriptによるコード実行環境を提供するサービスです。このサービスの特徴の1として、CSSの作品がアートワークのように多く投稿されており、世界中のCSS職人による素晴らしいギャラリーを堪能することができます。その技術はもはや 変態 職人の域に達しているものが多く、より高いレベルのCSSを組みたい場合に勉強になるでしょう。 というもの。そんなCodepen の https://codepen.io/tag/css-animation から、 CSSだけでできるあんなことこんなこと に倣い、Html10行、js no need, cssだけでこんなことができるんだ、すっげー、という私の眼力だけで選出した。役に立つかは知らない。
「暴言吐かないように気をつけます」 暴言暴言書いているので念のためBOSS(社では執行役員ともいう)のお名前はマスキングしています。弊社の開発部のトップリーダーに彼自身の「分報」を開設させる、という今年前半の社内コントリビューションを自慢するために書いています。 関連: Developers Summit 2022に登壇したので、その感想🍬 - Qiita 「弊社の執行役員に、#times_役員 なSlack分報を開設させるまでにやったこと全部書く」。BOSSは尊敬している。だからこそもっとBOSSと気楽に話したい、仲良くなりたい、BOSSの考えていることを知りたい、でも話しかけるのは緊張しちゃう、いつでも話していいよ?ムリ~~... そんな悩みをもつ方やチームの参考になれば嬉しいです。 結論: 地道なお互いの信用獲得。それは狩猟ではなく農耕 結論から。地道にお互いと全方位的な信用獲得を
はじめに 自分と似たような好み (宗派) の人の参考になればと思い書いています。自分の好みとは... 脱ExcelしたいMarkdownテンプレート目次 - Qiita Notion概要と、無料Markdownエディタとの比較 - Qiita ですが正直なところNotionは使いこなせているわけではなく、日々の打合せやネタ帳をただの *.txt でWindowsのお仕事自端末に保存して過ごす人生でした。 きっかけ Obsidianは最高のマークダウン『メモ』アプリである 最高とは。しかしそういえば自分の *.txt 、書くだけで見返すことができていない... 。 そこで WindowsデスクトップVersionを入れた Obsidian is a powerful knowledge base on top of a local folder of plain text Markdown
この記事は Develop fun!を体現する Works Human Intelligence Advent Calendar 2020 Develop fun!を体現する Works Human Intelligence #2 Advent Calendar 2020 煽り記事的タイトルですが Works Human Intelligence アドベントカレンダーの投稿練習です。 プログラミング言語に優劣はあるのか Delphiで湯婆婆する を投稿したらそれなりに面白がってもらえたようなのでDelphi(Object Pascal)というプログラミング言語の良いところを書いてみます。結論を先に書いてしまうと、言語に向き不向きはあっても優劣なんてないわけです。たまに表題のように煽られる弊社ではありますが、それを中の人としてどう向き合うべきなのか、という意味であらためてDelphiについて
No Brilliant Jerks - Netflixの「頭はいいけど嫌な奴、お断り」について調べたチーム開発チームビルディングnetflix ブリリアント・ジャークス。 有能だけど有害な人のことを Brilliant Jerks と言うとのこと。 (以下DeepL翻訳) The Brilliant Jerk: What to do with A High Performer with a Bad Attitude 良い姿勢、ハイパフォーマンス - ロックスター 良い姿勢、低いパフォーマンス - チームプレーヤー 悪い姿勢、低パフォーマンス - 三本足の犬 悪い姿勢、ハイパフォーマンス - The Brilliant Jerk. 態度の悪いハイパフォーマーを排除することは、他の社員の潜在能力を引き出す圧力弁を解放するようなものです。 私はそれを何度も何度も見てきました。態度の悪い人が会社
ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ | Mark Richards, Neal Ford, 島田 浩二 |本 | 通販 | Amazon を読み直したのでその読書感想文です。「読み直した」というのは、2021年よりありがたくもこの本の査読に参加させていただいたからであります。 感想 「基礎」という言葉の通り教科書的にアーキテクトのお仕事が学べる本。 「パターン」とそれぞれの特性などが分かる。何度も読み直したい。 「既にアーキテクトである人や駆け出しのアーキテクトに向けて、ソフトウェアの構造からソフトスキルに至るまで、ソフトウェアアーキテクチャとそのさまざまな側面を提供したい」との通り、とりわけ「ソフトスキル」という対人のものも結局はスキルなのだよなと気付く。 査読は大変楽しかった!!! 要点 はじめに:公理を疑う 公理 確立され、一般に受け入れられ
コーチング・メンタリング・ティーチング・コンサルティング・カウンセリングの違いと、自分のメンタリングへの心がけ 2022春教育新人教育新人プログラマ応援メンタリング コーチング・メンタリング・ティーチング・コンサルティング・カウンセリング の違い コーチングとティーチングはどう違う?それぞれのメリットやデメリットと使い分けの方法を解説 | SmartDocument メンタリングとコーチングの4つ共通点と違いとは | しごとのみらい コーチングはコンサルの基本スキルになりつつある? | フリーコンサルタント.jp コーチングとティーチング、コンサルティングの違い(使い分け) | コーチング | NLPプロコーチ認定コース | 米国NLP&コーチング研究所公認 認定スクラムマスター研修受講メモ | DevelopersIO まずは以上を参考にしています。「メンター」という役割について心配の声
読書感想文です。 感想 「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サイトとして カスタマーサポートにかかるコストの課題を解決する 顧客満足度と企業評価を上げる オペレーターのストレスを緩和する ユ
概要 真面目にやると損をする不思議? 不幸なリモートワーク、我慢のリモートワークは有害なのでやめようという話です。リモートワーク下。 がんばって生活時間を削って対応する。ギリギリ問題がないように見せる。 最初は「頑張っている/頑張ってくれているのだな」との相互理解があっても、1ヶ月もすぎればそれは「普通」。 周りは次第に、それは彼/彼女の「当たり前」であると勘違いさせられてしまう。 一方頑張っている側は相変わらず「頑張っている」つもりに勘違いしてしまう。 姿が見えないからです。タチが悪い。 結果いつの間にか 仕事を頼まれた側: 相変わらず頑張っているのにそれが当たり前に思われてしまう。ので、感謝されない。 仕事を頼む側: 相手が頑張っていることに気づけない。ので、感謝できない。 たいへん不幸なミスマッチが発生する。 一線で水が溢れ出た時 仕事を頼まれた側: 無理です (というか元々無理目に
プレゼン、凝りたいと思い始める時が危ないですね。 以下あたりが軸なのかなと思い、並べてみました。 結局UMLとかシーケンス図とかAWSの図とかどれで描くと良いのよ?と思ったときの選択肢 - Qiita の姉妹編です。 書きやすさ 資料としての保存 プレゼン映え 結論としては以下意味で、この順番です。 「書きやすい」フォーマットで完璧に仕上げておく。 そうすることで保存性、見直す価値のでる資料になるし、映える資料にあとからでも加工できる。 1. 書きやすさ 見せるというよりまず、ごくシンプルに書きたい。 Terminal Terminal上でプレゼン。 slides go install github.com/maaslalani/slides@latest slides sample.md 変換 究極の選択肢として、いかなるものへも変換してしまえばいいということでもある。 md2googl
対象読者 新人プログラマ。 新人プログラマに数学くらいはできてくれと願う方。 数学をどこまで勉強すればよいのか?を知りたい方。 はじめに 何をどこまで勉強すればよいのかについて以下をこれまでに書いた。 エンジニアはどこまで勉強すればよいのか - スキルマップと生存戦略を考えた エンジニアは英語をどこまで勉強すればよいのか - 英語に関する2つのご意見 で、私のような古参にとっては「エンジニアなんて一生勉強だ...」が正直なところだと元も子もないことを書いてしまったのだが、新人さんが配属される季節。何を勉強することが少なくとも必要なのかと考えた。で、こんな本の話です。プログラマの数学。 目次に従って、その内容と関連知識のメモです。この本に書かれているくらいの数学が分かると、どう嬉しいのか。 目次 ゼロの物語 —— 「ない」ものが「ある」ことの意味 10進法 / 2進法 / 位取り記数法 /
あー、そういえばちょうど良い具合の勤怠管理システム欲しいな~! そんな休日ありますよね!? Azure でちょっとしたプロトタイプみたいな設計レシピ作ってくれと言われたので作り始めてみたメモ。 オーダー: 就労管理 Azure を使う Azure OpenAI も使う あとは自由 雑だがあとは自由なら自由にやってみようということでとりあえず。 Request 時刻を Excel に記録 Microsoft Forms からの Request を Excel に記録 アイディアを膨らませる ものが動くと楽しいですよね。 勤怠管理システムを構築する際には、以下の機能を考慮することが重要です: ユーザー管理: 従業員の基本情報やアクセス権限を管理できる機能が必要です。 打刻機能: 出勤や退勤の打刻機能を実装し、これを元に労働時間を計測できるようにします。 休暇申請機能: 従業員が休暇を申請し、管
次のページ
このページを最初にブックマークしてみませんか?
『@e99h2121のマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く