タグ

ブックマーク / qiita.com/e99h2121 (5)

  • 結局UMLとかシーケンス図とかAWSの図とかどれで描くと良いのよ?と思ったときの選択肢 - Qiita

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

    結局UMLとかシーケンス図とかAWSの図とかどれで描くと良いのよ?と思ったときの選択肢 - Qiita
    abababababababa
    abababababababa 2022/04/03
    CACOO使ってる。リアルタイムでみんなで書けるのはいい。
  • 「正直9年経ったいまでもfor文ググってる」 - Qiita

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

    「正直9年経ったいまでもfor文ググってる」 - Qiita
  • 「次から気をつけます」に対抗する、反省文よりは効果が上がる再発防止、学びの機会 - Qiita

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

    「次から気をつけます」に対抗する、反省文よりは効果が上がる再発防止、学びの機会 - Qiita
    abababababababa
    abababababababa 2021/08/17
    IPAの教訓集知らなかった!面白すぎる。毎日1つずつ読んでみたい。
  • Slack社はSlackをどう使っているのか - Slack利用ガイドラインの話 - Qiita

    GitLab社のGitLab Handbookと徹底した文書化、組織的なオープンネス(?)を先日調べたのだが、じゃあ同じように見える化、透明性をアピールしているツールが何か?と考えた際ににSlackがあると思っている。SlackといえばDM禁止!オープンな職場が良し!風通し良し!なやつである。 しかしそれを実際会社で根付かせようとした時に、Slackの使い方を説くだけでは足りなくて、むしろ皆の意識改革みたいなものが必要だな~とひしひし感じさせられる。オープンな会社が良いかクローズドが良いか、「チームの風通しは良いほうが良いのか?」 世の中ひねた人も居るもんで風通しだけ良くてもこんなデメリットが有るなんて言われる 意見は増えても、内容が浅い 意見の浅い深いを確認する手間がかかる 浅い意見でも対応しなければならない 多数派の浅い意見に流されがちになる https://factory-learn

    Slack社はSlackをどう使っているのか - Slack利用ガイドラインの話 - Qiita
  • 海外「なぜ日本はハードウェアの時代と同じようにソフトウェアに秀でることができない?」 - Qiita

    Why doesn’t Japan excel in software as they did in hardware? (なぜ日はハードウェアの時代と同じようにソフトウェアに秀でることができない?) という英語Quoraのやり取り、分析が興味深かったので、まとめ。 仮説1: 日は完璧を求める 10人のエンジニアのソフトウェア開発会社を経営しているフランス人の友人が、ルイ・ヴィトン日支社のコンピュータシステムのマネージャーと同意した話:ソフトウェアはハードウェアではなく、産業用でもない。50年間同じトヨタカローラのように構築され、洗練され、完成されたものではありません。ゼロバグでそれを「完璧」にすることは不可能であり、したがって、「ゼロデフォルト」という、総合的な品質、継続的な改善を求める日人の精神に反するものです。 日は職人の国であり、漢字を書いたり、折り紙を折ったりする技術

    海外「なぜ日本はハードウェアの時代と同じようにソフトウェアに秀でることができない?」 - Qiita
  • 1