Notices by いつも魚とトマトを買いに来る客 (momosetkn@qiitadon.com), page 92

「正しい方向」は１つしかないが、「間違った方向」は正しい方向以外の全部だから、「理解できないパターン」は無数にある。

https://qiita.com/shiracamus

この方が、ときどき初心者の方が書いたPythonやC言語のコードをいい感じにリファクタリングして記事に書いてるようなので、読むと参考になるかも

オブジェクト指向的なコードの書き方の本や記事って少ないかも？

アジャイル開発に関する質疑応答 - Qiita https://qiita.com/hibikikudo/items/7a31c7e8bc5b71d585c5

>差し込み仕事を依頼した回数に応じて偉い人のプリクラをホワイトボードに貼っていくといった可視化を行うと、不思議なことに差し込み依頼が減ってくる。

吹いてしまったｗｗｗ

スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするか - Qiita https://qiita.com/aimof/items/d68bdb347283ee2dbccf

テストを書こう。
テスト先に書いてからコード書くと、単体ですぐに試せるので品質・速度が上がるという話。当たり前だけど、意外と当たり前じゃない。

>【SIer新人向け】研修では教えてくれないノウハウ集

さっき後輩から「技術面はぜんぜんできてないが、業務面はほとんどできてる」ってメールで返信が来た。

え？まじかよ…って感じが…。ぼくはその後輩から業務面について教えてもらわないといけないかもしれない。

徳丸本輪読会第２回目の日程調整・参加申し込みを行います。
場所は東京都内を予定しております。
詳しくはリンク先！

連絡はマストドンか、オンラインチャットルーム（ https://discord.gg/s5VQjMN ）で行いましょう。

徳丸本（安全なWebアプリケーションの作り方）輪読会第２回目の日程調整・参加申し込み | 調整さん https://chouseisan.com/s?h=0466c70bbf84453aac97f4d251012151

#徳丸本輪読会

みんなからカツアゲされそうになってる・・・

@7of9 なんらかの原因で過大な電力で通電した瞬間に青サビがついたのかもしれないですね…。
(sharow氏が貼ったリンクの知識より）

椅子が原因で腰痛になるんじゃなくて、姿勢が悪いのが原因で腰痛になるってことか

ネットで議論好きな人？で相手を理解しようとする気持ちよりも相手の矛盾を必死に探そうとする人ってどこにでもたいてい居るけど、Qiitadonは今の所そういう人は少ない印象。

IPA資格の基本情報の言語問題ってC言語、COBOL、Java、アセンブラと最近は表計算が追加になったらしい

プロトコルとは - Qiita https://qiita.com/KEINOS/items/cb7f629268b90ef6493d

社内のメーリングリストに共有しとこうかな。
「プロトコルを説明します」と言って仕様を説明している翻訳ものの本はたまに見る。

ああ、昔「プロトコルって言葉の意味わかってねえよ」って上司に言われたことあるなあ…。
そのときにこの記事見せられれば良かった。

今の案件の運用方針作ってる。

【スクラム入門】認定スクラムマスターの俺が正しいスクラムの理論をまとめる - Qiita https://qiita.com/gold-kou/items/90ba982a14ca79d843c9

ひだお氏が発掘してきたこの記事が役に立っている。

未投稿 (10/10)にある新人向けの記事、技術的なこと以外の記述の練りが足りない。
新人のとき技術力が無くて困った経験をあまりしてこなかったのか、質問・相談スキルが低いのかもしれない。

新人の方が「不慣れだから小さな機能の改修からやりい」的なことを言っていたので、
「どんな機能も分解すれば小さな機能が集まってできてるものだよ」って言っておきました。

大きな機能も小さな機能も分解してしまえば変わらないです。
しかし、分解する能力が身についてないところがネックなんでしょうね…。

#programing

「コードをきれいに書くことは、引き継ぎ作業のコストを下げる一つの手段である」

「～の素」の類は冷凍しておいて、使うときに包丁で袋ごと切るとか…

自分の「いいねした投稿」を見てたら、こんなのがあった。

「ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」 - Qiita https://qiita.com/n_slender/items/06c8ba5b987ed9300281

>エンドユーザの要求をはるかに超えた品質水準は、生産性を上げる一つの手段である
>一見すると、品質を追求しないで手抜きをした方が作業時間も短く、動くもの程度であればたくさんつくれるような気もしますが、そのスタンスでやってその後のバグで手痛い目に合うことも何度かあり。。。

「ピープルウェア」読んでみよう…。ああ、Webセキュリティの本もコップ本も読まないと…。

保守性が著しく悪いコードを改修していると、プログラミング初心者になったような気持ちになれる。
例えば、コードを真面目に読むの辞めて、ブラックボックス的にコピペとかで済ませるとすると、それが動くかどうかは運しだい。

昔、だいたいいつも見積もりよりも2倍以上の工数かかってるおじさんが居て、
そいつは毎回、「想定しているやり方でうまくいくか分からないので、どれぐらいかかるか見込み立てられません」って感じのことを言ってた。
コピペして動くかどうかは運任せなコーディングだから、見積もりも立てれないんだなあって今更ながら思った。