  |
はてなキーワード: カバレッジとは
私はPM。要件決め、設計などは得意だが、細かい技術的な部分はよくわかっていない。
チームリーダーB：経験豊富。全体設計もできて、コーディング速い。顧客折衝もできる。
新人C：経験浅い。コーディング遅め。devopsやプログラム言語についての知識がある。こだわりが強い。SNSでもいろいろ発信。
私は板挟み。
チームリーダーBは頼りになる。新人Cも最新の技術的な動向を追っていて、いろいろ知っていて関心する。いわゆるベストプラクティスというのは新人Cが提案するやり方なのかな、と思う
たとえば、クラス設計はインターフェースを用いてもっと疎結合にコードを組むべきだとか、テストコードのカバレッジをもっと上げないととか、言ってることはもっともだと感じる。
チームリーダーBはそういった細かいところにわりと無頓着なのかもしれない。ずっとやってきたやり方に固執してる部分もあるだろう。
私が若かったころは先輩のやり方は絶対だったため、こういった揉め事は少なかったように思うが、
最近は新人も学生時代にネットで多くを学んでいるため、知識が豊富で理論武装もすごいため、先輩が言い負かされてしまうケースも多い。
私の意見としてはBもCも良い部分があるため、どちらの意見も採用したいところだが、相性がよくない。
BはCのやり方だと、他のメンバー（DやE）の面倒もBが見ることになり、自分の負担が増えると言う。
ただ、保守性の高いプロダクトにしておかないと、長い目で見たときにあとあとキツくなってくる気もする。
あと、CはCで時間を掛けてばっちりテストコードを書いてるはずだが、経験が浅いせいか、テスト環境にデプロイさせると、かなりバグを発生させている。。
どうしたらよいだろう。
ツッコミを入れておくと、既にROGDは「是非の分かれる」というより「まともな」研究レベルには到底達していない存在なので、肯定的に取り上げる時点でどういう偏見が背後にあるかを示す存在になっている。
その翻訳してる元でも"which itself was subject to censorship efforts which, whatever the merits of the study, were scientifically deplorable."だけど、これは実際
https://link.springer.com/article/10.1007/s10508-019-1453-2
などで網羅的に指摘されている通り、調査手法の最初から問題外なレベルであって、あまりにもdeplorableな「研究」。
また、ROGDを引いてシュライアーが主張している感染による急拡大は、調査自体がないが、間接的証拠からは実際にはそもそも起きていない可能性が高いことと、
男女比の変化などはカバレッジの改善でほぼ説明できることを解説しているのがこちら。
https://sciencebasedmedicine.org/the-science-of-transgender-treatment/
ただ、その翻訳元（Dr C.J.Ferguson）が懸念している点である、
GD-ASDの併発が稀でない可能性が示唆するGDに対する予期せぬ過剰介入については、
まだ治療ガイドラインに反映されているとは言いがたく、さらなる研究が必要だが、
それについてあまりにも反応が極端ゆえに研究が進まないのでは、というのはあるし、
実質的な検閲によってそれがさらに阻害されるという可能性もその通りではあるけど、
"the negative reaction it has garnered in the trans community is entirely understandable. "
と書いてるように、このフォビア全開な内容を価値があるとするのは、それはそれで傲慢でしょってのもある。
学術的価値を優先するならフォビアを抜くのは造作もないはずなんだから。
とはいえ、抗議だけで差し止められるようになればそれは研究への間接的な検閲というのもその通りだから、懸念するのもわかるんだよね。
https://doi.org/10.1007/s10508-014-0285-3
※性差の研究でよく扱われるCRMP4がASDに関係している可能性を示した論文もあるので、
視床下部をターゲットにした非定型な遺伝子発現が場合によっては両方に影響するという仮説は立てられる。
ASDは元となる遺伝子異常があまりにも多岐にわたるもので、様々な原因が同じような症状を呈するために一つのスペクトラムとして扱ってるようなものなので、いつか個々の原因に分解できるようになればどれが原因ならば併発するかは分かるようになるだろう。その時はまた新たな社会的問題になるだろうけど。
この期間に、様々なプロジェクトに関わり、多くのことを学びました。
今回は、私が経験した技術的な話を中心に、はてなでの仕事について振り返りたいと思います。
はてなでは、主にRuby on Railsを使ってWebアプリケーションを開発していました。
はてなブログやはてなブックマークなどの有名なサービスはもちろん、社内向けのツールや新規事業のプロトタイプもRailsで作っていました。
Railsは、高速に開発できるというメリットがありますが、それと同時にコードの品質やパフォーマンスにも気を配る必要があります。
私は、テストやリファクタリング、コードレビューなどの技術的なプラクティスを積極的に取り入れることで、Railsの開発をより効率的で安全に行う方法を学びました。
例えば、私が担当したプロジェクトでは、RSpecやRuboCopといったツールを使ってテストカバレッジやコード規約をチェックし、GitHub ActionsやCircleCIといったサービスを使って自動化しました。
また、Pull RequestやPair Programmingといった方法を使ってコードのレビューを行い、バグや改善点を見つけたり、知識やノウハウを共有したりしました。
また、はてなでは、AWSやGCPなどのクラウドサービスを活用してインフラを構築していました。
私は、DockerやKubernetes、Terraformなどのツールを使って、コンテナ化やオーケストレーション、インフラストラクチャ・アズ・コードなどの技術を実践しました。
これらの技術は、開発環境と本番環境の差異を減らし、デプロイやスケーリングを容易にするという利点がありますが、それと同時に複雑さやトラブルシューティングの難しさも増します。
私は、モニタリングやロギング、アラートなどの技術的な仕組みを整備することで、インフラの運用をより安定的で信頼性の高いものにする方法を学びました。
例えば、私が関わったプロジェクトでは、DatadogやCloudWatchといったサービスを使ってシステムの状態やパフォーマンスを監視し、SlackやPagerDutyといったサービスを使って異常や警告を通知しました。
また、ElasticsearchやFluentdといったツールを使ってログの収集や分析を行い、原因究明や改善策の検討に役立てました。
## チームでの協働
はてなでエンジニアとして働くことで、私は多くの技術的なスキルや知識を身につけることができました。
しかし、それ以上に大切だったのは、チームで協力して問題を解決することでした。
はてなでは、エンジニアだけでなくデザイナーやプロダクトマネージャーなどの他職種とも連携してプロジェクトを進めることが多かったです。
私は、コミュニケーションやフィードバック、ドキュメンテーションなどの技術的ではないスキルも重要だと感じました。
私は、自分の意見や提案を積極的に発信することで、プロダクトやサービスの品質や価値を高める方法を学びました。
例えば、私が参加したプロジェクトでは、SlackやZoomといったツールを使って日常的に情報交換や相談を行い、BacklogやJiraといったツールを使ってタスク管理や進捗報告を行いました。
また、FigmaやMiroといったツールを使ってデザインやアイデアの共有やフィードバックを行いました。
私は、はてなでエンジニアとして働くことがとても楽しく充実していました。
しかし、私は自分のキャリアについて考える中で、新しい挑戦をしたいという気持ちが強くなりました。
私は、自分の興味や関心のある分野にもっと深く没頭したいと思いました。
## おわりに
彼らに感謝する気持ちを込めて、このエントリーを書き終えたいと思います。
全ての男の遺伝情報は，全ての男の全ての遺伝情報とは異なります．
技術的な話で恐縮ですが，父親を判別するのが目的ならば，全ゲノムを解析する必要はなく，ユニークな部分だけ解析すればよいです．
バーコーディング技術と超並列シーケンサーを用いれば，100万円で1000万人分くらい解析できてしまいます．この計算ではカバレッジ=3強ですので，大分手抜きなのですが，もしも容疑者が複数名になってしまった場合でも再解析すればよいので，実用上問題ないはずです．
サンプル採取はコストがかかりそうですが，新型コロナウイルスのワクチン注射やPCR検査の実績を見れば物理的に無理ってことは全くないですね．
それでデータ量は数百GBってところでしょうか．なんせ肝心要の部分だけなら一人につき56ビットですので，1億人でも56ギガビット，つまり8GBでお釣りが来ます．
つうわけで技術的には可能です．ただ，本番データを落っことしたりすると厄介ですので，そんなデータベースは当分作らないで欲しいと思っちゃいますが･･･
転職歴としては1社目は新卒で入った地元の零細受託Web制作会社→4年前くらいに転職し現在自社サービス企業に勤務中。
ちなみにまだ内定は0件。
コロナを機にフルリモート案件が増えたのと、リーダー経験とか積むにつれて市場価値と今の職場が合わなくなってきたのがあるのと、
今の年収だと婚活で戦うのはかなりきついということを実感したので動き出すことに。現年収は400万ちょっとくらい。
専門卒で経験はPHP/JS中心だから経験してきた技術スタックや学歴的にはあんまり上位狙えるようなアレじゃないんけど今回は心が折れるまでは初年度年収600万を目指すことに。
現職でのリーダー経験と、Saasを立ち上げから設計・開発全部8割型自分で進めて競合と戦えるサービスに成長させた経験とか、ゼロイチで既存案件をDDDに移行したりテスト駆動体制を導入したりとか、まあまあ個人開発もやってますよとかその辺をアピールポイントとして戦うことに。
肌感覚としては「500万までは余裕だけど600万はきつい」だわ。
まず某転職サイトに応募すると早速600万のスカウトが来たユニコーン系ベンチャー。フルリモート。
「貴方のSaas開発経験に魅力を感じ～」とか書いてたから誰でも送ってる風じゃないと思い応募。
結果はなんと書類選考落ち。いや学歴とか職務経歴とかほぼ転職サイトにそのまま書いとったやん。
恐らくだけど選考時にGithubアカウントとかTwitterアカウントを求められたときに仕事用のものはセキュリティ上渡せないとか渋ったのと、
渋々渡した個人用Githubアカウントはオープンソース活動とかはしたことなかったからこれがしょぼいって思われたのかな？って思った
ちなみにこの会社からは書類選考落ち後に各転職サイトから5回くらいスカウトが来てる。
大手っていうわけではないけど割と有名なSaas企業。こっちもスカウト。転職サイトの上の方でよく見る気がする。
結構近しい分野のSaasを立ち上げから関わったことがあるのでこちらを武器に面接へ。1次面接落ち。
面接は割とうまく行ったと思うけどなぁ、って思ったけどやっぱりフルリモートでこの給与帯の休日は倍率半端なさそうだからちょっと良いくらいだと全然落ちるんだなと実感。
立ち上げから3年も経っていないベンチャー、ただし既に利益率は割と凄い感じで業界的にも硬そうだから応募。
カジュアル面談のときにCTOに是非応募してほしいって直接言われた。
1次の技術面接のレベルがたけぇ。○○の設計思想の内容だとかDIコンテナとかReactの状態管理用ライブラリの運用とかの質問をクイズ形式っぽく質問される。
割とうまく答えられたと思ったけど1次面接落ち。
有名地元に拠点がある東証一部上場の自社サービス企業。600万の求人と450万の求人で分かれてて600万の方で応募したら書類選考で「600万は厳しいけど450万なら良いですよ～」って言われてる状態。
やっぱ相場観的にはそうだよなぁって思った。
今週1次選考だけど受かっても年収交渉時に450万しかもらえないなら辞退しちゃうかも。
有名医療系ベンチャーと車業界系のSaas。カジュアル面談の要請出すも音沙汰なし。
別の転職サイトで確認すると応募条件大卒以上って書いてたから多分それが原因。ちゃんと書いとけや。実質書類落ち。
少人数の建築系ベンチャー。HPの情報量も少なく恐らく資金調達のフェーズでは？って感じの企業。
なんとなく社長から与沢翼の匂いがする。まだマネタイズまで行けてないのに何百億とか何兆とかやたらでかい数字を言いたがる感じ。
技術スタックに対して年収が高すぎるのが逆に怪しい感じがする。
一応最終選考まで残ってるが、通ったとして行くべきかは悩みどころ……
スカウト来て応募。かなり好感触だが求人票と実態の下限年収に相違あって思ってた年収より100万くらい下がりそう。
去年末くらいから始めた転職活動。今週も面接面接面談面談面接。
自分の市場価値みたいなところは良くも悪くも痛感する。500万までのスカウトはよく来るけど600万になるとやっぱなかなかこない。これが相場観なんだろうなって感じ。
「テックリード」とか「シニア」とかのスカウトは全く来ないからまだそういうレベルではないんだなぁって。
「誰もが知る有名企業で年収600万」は多分俺のスペックだと無理ゲーで、あとはいかに穴場のベンチャー狙えるかっていうところにかかってる感じ。
それはそれで安定捨てて市場価値より高い会社に勤める感じになるわけだし将来トータルで考えるとそれはそれで大丈夫なの？って感じもある。
でも専門卒じゃ20代現年収600万くらい武器ないと婚活じゃ戦えないしなぁとも……はよ彼女作ってこの悩みから開放されたい……
エントリーする度にそこで働く未来の自分を思い浮かべるのに祈られた瞬間に全部がなかったことになるの辛い
あとカジュアル面談受けまくってるけど、これが割と面白かったりする。
「こんな有名企業だけどQAは俺がリーダーやってる案件のがカバレッジ率とかしっかりしてるんだー、バグったら人が死ぬタイプのシステムじゃないし逆に今の運用が過剰品質すぎなのかなぁ」「LeSSって開発手法あるんだー」「前職も現職もSelenium導入って微妙な感じになってるけどこのMablってテストツールだと割と良い感じかも」「今の職場みたいに運用フェーズのエンジニア部署でKPI設定を半期ごとに設定するのは粒度がでかすぎるよなぁ、この会社みたいに1ヶ月周期とかで設定した方がよさそう」「ワーカーサーバーの悩むポイントはどこも同じだなぁ、でもやっぱGoだとPHPよりも並列処理強いんだなぁ」
他の会社の運用とか技術スタックの話を深堀りして質問しまくれる機会とかなかなかないから、落ちたは落ちたなりに吸収できるものはある気がする。
あと社交辞令かもしれんけど「いやその経験と技術力で今の年収はどう考えてもおかしいっすよ」とか結構言ってくれるの嬉しい。
今地方の自社サービス開発企業に勤めててその中ではテックリード的な立場。
Saasのシステムを設計フェーズから1から構築したこともあるし、
他にもレガシー目なサービスにDDDやクリーンアーキテクチャ的思想を導入したりTDDの構築と運用へあたっての体制構築や教育を主導したりとか
メンバーのスキルに偏りがある状態でも品質維持するための体制をなんとか作ったりとか
小さい企業ながら割と経験詰めたし今なら転職とか余裕だよなーって思ったがなかなかうまくいかない。
今のところ3社受けて全部1次面接落ち。受けたのは転職サイトのトップページに一番大きく載ってるような人気企業だから倍率は結構高い気はする。
今のところフルリモートで初年度年収550万～600万くらいを目指してる。多分500万くらいまで水準下げれば求人めっちゃ増えるし余裕な気はする。
あっちからスカウトが来て、競合ではないけど似たようなサービスを俺も構築した経験があったから
御社の製品の○○機能(リリースされたらプレスリリース打つくらいの機能)と似たようなものを営業にほしいと言われてから2日後にはテストカバレッジ率100%の状態でリリースまで持っていきましたとか、
当時はリソース足りず自分一人でほぼ全部対応してたけど爆速でリリースサイクル回して1年で機能数的にも競合製品に負けないくらいまで成長させましたとかこれ以上ないくらいアピールしたよ。
なーにが行けなかったんだろう。やっぱコミュ障なのが影響してんのかなぁ。「えーっとまあ」とか「なんか」「えーーそうですね…」みたいなのが多いのは自覚してる。
フルリモートで給与も高水準だと倍率高いから、もしかしたら20人中の1人や2人採用で第3位だったとかかもしれない。
何をどう変えたらいかなぁ。
転職指南書に書いているようなHPの企業理念読んで面接官が喜びそうなことを事前に作文して頭に叩き込んでおくみたいなことはやりたくないんだよね。
俺会社じゃ面接官する側だけどポートフォリオとか職務経歴しょぼいのに口だけ凄いこといってると
「ああ、この人面接官喜ばすための言葉を事前に作文してきたんだろうなーーー」「この人は”面接が”上手い人なんだな」とかやっぱ内心思っちゃうし
まあ応募して落とされて凹んでまた応募してを繰り返すしかないのかな。
今ちょうど対処法に頭を悩ませてる、ここまでの人は正直人生初。
バグが多い、レビューの指摘数が多い、投げた仕事がわからない・できないで投げ帰ってくる、基本的なアーキテクチャが理解できてない、成果物が出てくるのが遅い
ざっくりとこんな感じ。
今のところこんな感じで対処してる。
正直「こんなに時間をかけて詳細に指示書いてこんな数の指摘を説明しなきゃいけないのだったらその人に振らずに俺が1から対応した方が数倍以上早いしこれは一体何を生み出している時間なんだろう」みたいなことを自問自答しながら作業してる状態。
これが新入社員とかだったら多分立ち回り方も結構変わると思う、できなくてもそれは経験不足から来るものだし、多分『教育』って形で結構時間かけて丁寧にペアプロして習熟度を上げてもらう感じかな。
2年目くらいでまだ戦力になれてない社員だったら多分3年目とか4年目くらいの誰かしら(できれば数人)と相談して教育係として俺との間に誰かを挟んでコミュニケーション上の距離を置いて負担をチーム内で分散する形にすると思う。
ただ経験年数長いで今更新人教育みたいなことをするとプライドを傷つけかねないし、ぶっちゃけこの経験年数でこれなら教育にパワーかけても効果薄そうっていうのもある。
あと単純に社内リソースが足りなくて俺がなんとかしなきゃいけない状態。
これどうすっかなぁ。プログラミングとはまた違う頭使うぞ。
1. Markdown, Textileは知っていた。
2. 「何か新しいことを覚えようかなぁ」というコレクター魂のようなもので、reStructuredTextの手を付ける。
3. Sphinxなるものを知る。Pythonとから、Djangoとか、あの見慣れたチュートリアルを作るドキュメントツールがSphinx。
4. 面白いのだけど登場人物が多くて話が追えないなろう系のメモとして使ってみる。
6. LaTeX記法での数式表現、Matplotlibの機能に感動する。
8. 索引ページに気づく。
9. 日本語表示がイケてない。微分なら「は」の項目に、積分なら「さ」の項目に表示してほしいじゃん？「微」「積」の項目なんよ。。英語と同じように「頭の一文字」を取ったらそうなるよね。
10. 探してみたら、「Yogosyu」というプラグイン（※Sphinxでは拡張モジュール）があった。使ってみる。
11. 最新のSphinxに対応していない。ここからPythonのコード解析へと逸れる。
12. 取り敢えずエラーはでなくなったけど、元々索引ページとは関係ない機能だった。同一「用語集」での表示順が日本語に対応するだけ。
13. （しばらく放置）
14. 「単語の先頭に振り仮名を付け足せば、いい感じにソートしてくれる？」と気付く。
15. 表示の直前で「振り仮名」を取除くために、どこで表示しているか探す。
16. （紆余曲折）
18. ここで初めて「プラグイン形式にすれば良くね？」と気付く。
20. 出来上がって喜ぶ。
21. ここで初めて「これってクラスにしたら、全体の見通しが良くなったりする？」と気付く。
22.（この辺りで、unittestモジュールに手を付ける）
23. テストケースのお陰でリファクタリングが怖くない。喜ぶ。
24. setup.py, setup.cfgの書き方を学ぶ。
25. pypi公開を果たす。誰にも知られずひっそりと…
26. テストケースにjinja2を通した結果も加える。一人で成果に喜ぶ。
27. githubに手を付ける。学ぶ。基本的なことは覚える。
30. teratailに登録。コソコソ。「何がなんだか分からない」では質問しないし、そのうちどうにかなることが多い。先駆者に感謝。
32. coverageを知る。学ぶ。基本的なことは覚える。
33. circleciを知る。学ぶ。基本的なことは覚える。
34. カバレッジが90%を超えて喜ぶ。←今はこの辺。
※ボッチの日常
いつもクルマネタの増田は反応がほとんどないんだけど、今回はこちらの記事に珍しく（少しだけ）反応があって（少しだけ）うれしい。
■手洗い洗車の基本を解説するよ
https://anond.hatelabo.jp/20210609143814
前回は基本編だったけど、今回はちょっとステップアップ。手洗い洗車してみたらまあまあ楽しかった、もうちょっと自分でできることを増やしたいなーって人向けだよ。と、言いつつも、大半は俺が書きたかっただけの蛇足だよ。
さて、作業の質をステップアップしようとすると、だいたい使う道具や洗剤を買い足すことなります。つまりステップアップと追加投資はほぼ同義だよ。
基本編ではホイールを洗うのにスポンジを使ったけど（使う道具が多いとアレかなと思って省略した）、ホイールはブラシで洗ったほうが効率がいいよ。風呂桶を洗うような柄付きのホイール用ブラシがホムセン行けば200円くらいからある。なので基本編から何かを買い足すならばまずはホイールブラシをおすすめする。お手元のホイールがスポークタイプ（中心から放射状に柱が立ってるデザイン）なら、スポークの間をくぐり抜けて奥まで洗えるやつがいい。ホイールの形状をよく確認してブラシを選ぼう。
クッソ便利そうだけどクッソ高いホイールブラシがひとつあって（商品名は伏せる）、朝起きたら枕元に置かれてないかなーと毎晩祈りながら就寝してる。
うっすら鉄サビのオレンジ色に染まってるホイールとか、全体が黒ずんでるホイールあるよね。こういうのはブレーキが削れて粉になった「ブレーキダスト」の成れの果てだよ。どんなホイールでも多かれ少なかれブレーキダストを浴びていて（ヨーロッパ車で大柄なやつの前輪とかは特にスゴイ）、これを手洗いで落とすのは正直めちゃくちゃたいへん。落とすには「鉄粉除去剤」を使おう。「チオグリコール酸アンモニウム」っていう成分が含まれてればＯＫ。こいつをホイール全体にまんべんなくスプレーして放っておくと、薬液が鉄粉と反応して紫色の汁が流れだします。5分くらいで落ち着くので、シャンプーで洗えば完了。
モールの境目とか、エンブレムやオーナメントとか、くぼみや隙間や細かいところ、隅っことか角っこにはスポンジ（と目）が届きにくい。
そういう場所の汚れは、小さなサイズのスポンジとか筆とかハケを使うと落としやすいよ。使い終わった歯ブラシなんかも場所によっては役に立つよ。洗車用品はとてもたくさんの専用品が売られてるけど、ホームセンターに行ったらカー用品以外の売り場もよく歩き回って「これアレに使えそうじゃん？」とひらめいた道具を使うのも楽しいよ。案外専用品よりずっと安上がりだったりする。
用途に応じてどんどん道具を増やしても逆に不便なので、カバレッジの広い万能内野手みたいなツールがあるとよいよね。私も模索中です。
車体にワックスやコーティングを施すとツヤが出てピカピカになるし、小さな傷なんかは隠れちゃいます。でも、ワックス／コーティングの効能はピカピカの美観だけじゃないんだな。むしろ、「保護」のほうが恩恵が大きい気がする。ワックス／コーティングをしておくと日々の汚れが溜まりにくいんよ。
日々の汚れが溜まりにくいと、毎回の洗車がラクになるし、頻度も減らせる。風化の進行を遅らせてくれるので、駐車環境が悪い人ほどきちんとコーティングしておく意味は大きいよ。下取り価格にもきっとちゃんと返ってくるはず（期待）。
どんなワックスやコーティングがええんや？ と言われてもそこはお答えが難しい。製品は無数にあって効果や耐久性も千差万別だし、そもそも私はこの部分はいつも専門業者にオマカセしちゃってるので（年イチでメンテナンス）知見が全然ないです。やってみたい人は自分で調べてね。ごめん。
ひとつだけ言えるとしたら、とにかく汚れをバッチリ落としてからやれということ。汚れを残したままコーティングで塗り込めても目立たなくはならないし、そのコーティングもすぐに落ちてしまうよ。
ロングノズルのシャワーを持ってるとボディの「下回り」が洗えるよ。下回りってのは床下ね。車を四つん這いの亀に見立てると、お腹のところ。シャワーを上に向けて、ボディの下に突っ込んで床下を洗おう。もっとも、最近の車は床下がまるっとカバーで覆われていることもあるので、床下が一枚板のノッペラボーだったら下回り洗浄はあんまり必要ないよ。自分の車の床下がどんな様子かは、スマホを挿し入れて動画撮影すればわかる。
下回りは見えない場所だから気分的に優先度が低いけど、その車に長く乗るつもりなら定期的に水で流すくらいしておこう。これも美観を保つというよりはメンテナンスの一貫だね。錆で朽ちてきても気づきにくいのに、いざ老朽化して壊れると修理費はけっこうかかるから……。
下回りも、基本的には水をかぶってはいけない部品はない。ボディ洗いの時と同じで水圧で吹き飛ばす要領でゆっくりとノズルを移動させて、こびりついた泥汚れを落としていこう。
あくまで一般論だけど、車軸と背骨がなす「エ」の字の周辺は構造物が多くて入り組んでいることが多いよ。なのでこのエリアは特にていねいに流そう。逆に、脇腹のエリアは基本的にただの床板なのでざっとでいいよ。
雪国に住んでいる人はみんな下回りをていねいに洗ってるよね。これは道に撒かれている融雪剤がサビの原因になるからだよ。雪無し県住みでもスキースノボによく行くって人は、帰ったらすぐに流したほうがいいよ。ちなみに高速ＳＡのガソリンスタンドには高圧洗浄機が使えるところがあるから、帰り道で洗っちゃうのも手だね。上信越道は横川SA、関越は赤城高原SAや高坂SA、中央道は談合坂SAのガソリンスタンドで高圧洗車機が使えるよ。
ていうか、ロングノズルのシャワーは下回りに限らず重宝するよ。屋根の上が流しやすいし、体が少し車体から離れるので高水圧でも返り血を浴びにくい。
ボディにも鉄粉は乗っているよ。でも目で見てわかるようなものではなく、注意して触れば感触でわかる程度のものなので、これからコーティングしようとか研磨しようという人でない限り放っておいてもよいのではと思う。
落とし方はホイールと同じで鉄粉除去剤をスプレーするか、異物除去用の粘土（ネンダーという）で表面をなでてキャッチする。ネンダーはボディ表面を水で濡らして使ってね。
スポンジが行き届きにくい窓ガラスのサッシぎわとか隅っこは長年汚れを見落とされ続けて汚れが積もっていってしまうので、なるべく日々の洗車で借金をためないようにしたいところ。
でもカーシャンプーで洗っても油膜やウロコ（雨や洗車の水滴がまだらな模様になってこびりついた汚れ）ってマアー落ちないよね！ ワイパーの水切れが悪いなとか、なんか見通し悪い感じがしてきたら、油膜・ウロコ取りをしよう。それ用の洗剤がいろんな種類たくさん売ってます。
あと窓ガラスのコーティングも雨の日の運転しやすさにめちゃくちゃ効果があるので、やったことない人はフロントだけでもやってみよう（ガソリンスタンドとかでもやってくれるところがあるよ）。窓ガラスコーティングもボディコーティングと同じで、「まずは完全にキレイなこと」が施工の大前提。汚いまま塗ってもしょうがないです。コート剤にも色んなタイプのものが出ているので、お好みで選んでみてね。
外装の美観には無頓着でも室内は気になってしまう、という人はけっこう多いんじゃないかな。てか、一般的にはそういう人のほうが多いか。
室内は基本的におうちのお掃除と同じだ。拾えるゴミは拾う。掃いたり掃除機をかけてチリを払い、汚れてそうなところは中性洗剤とかで拭き掃除。
掃除機も高いところから始めて低いところに降りていくといいよ。チリは下に下に落ちていくからね。シートはリクライニングを最大に倒すと背もたれと座面の隙間に掃除機がかけやすいよ。けっこうゴミとか小銭とか前オーナーの屁とかが溜まってるよ。車室内にはドリンクホルダーやドアポケット、センターコンソールの小物入れなど便利なくぼみがいっぱいあるけど、そういうところの底にはゴミも溜まりやすいよ。そして女性はそういうところが汚いことを見つける名人だよ。
拭き掃除はふだん手指で触るところを重点的に、かんたんマイペットとかの中性洗剤で清めればよいよ。ハンドルやノブ、スイッチとかその周辺。広いところはスプレーしたり、狭いところはタオルにスプレーして拭いたり。そしてすかさず水拭き・乾拭きで仕上げるとべたつかないよ。
ドライバーがタバコを吸う人ならば作業範囲は車内全体に及ぶのでしんどいよ。ヤニは溜めれば溜めるほど掃除がたいへんなので、タバコを吸う人は月に一度はあったかい濡れ雑巾で全体を水拭きするようにしたほうがいい（ヤニは水溶性だよ）。
古い車はヘッドライトがどんより濁って黄ばんでることが多いよね。これをリフレッシュするのは個人的にめちゃくちゃオススメ！ スッキリ透明ツヤツヤなヘッドライトにするだけでパッと見の印象がマジでまるっきり違う。ハードルはかなり高いけど、ホント若返るよ。
しかしこれをＤＩＹでやるのは「そういうことが大好きな人」にしかおすすめできない。基本的には磨き屋さんとか板金屋さんに持ち込んで研磨＋コーティング施工してもらうのが一番なんだけど、まあ、お高い。両目で１万以上とられると思う（純正新品と交換するのと比べればずっと安いけど）。金銭感覚は人それぞれだし現状がどのくらいみすぼらしいかにもよるけど、とにかく高いお金を払う価値はあると思うよ。
あ、虫除けスプレーでヘッドライトの黄ばみが落ちる、と一時期バズッてたけど、私はあまりオススメしないな。たしかに落ちるんだけど、これは黄ばみ層を剥離するだけなのでまたすぐ黄ばんでくる。年に何度もやる覚悟をするか、ＤＩＹするならちゃんとコートまでできるキットを買ってやったほうがいいかも。
私の車は細かな凹凸が多いデザインで洗車機だと洗い残しがたくさん生じるので、基本的には洗車機は使ってません。まあ、自分で手洗いするのが好きってのも大きいけど。なので近ごろの洗車機の実力とかメリデメとかはちゃんと把握していないんだよね。語る資格なし！
洗車機の世界も日進月歩で技術革新が進んでいてなかなかハイテクなことになってるみたいなので、ふだん洗車機使ってる人、現代の洗車機事情なんかを教えてほしい。
あれを買えこれを買えといろいろ言ったけど、具体的な商品名は挙げないようにした。商品名を出すととたんに文章がウソくさくなるよね。なのでどれを使うかはみなさん自己判断してほしいんだけども、カー用品店にもAmazonにも似たような製品が無限にあって、何を買えばいいかけっこう迷うと思う。
普通にググるとタイアップ動画やアフィりブログばかりヒットしてしまうよね。もしネットの口コミで判断する時は「みんカラ」でレビューを探すとよいよ。みんカラはエンドユーザーのコミュニティなので書かれてることは基本的に使ってる当人たちのホンネです。ただし全体的にＩＱとリテラシがやや低め（含む科学リテラシ）なので、そこは補正しながら読んであげてほしい。
ちなみに自分は高機能・高付加価値な製品にはあまり興味がなく、単機能でベーシックなものをやりくりしてほどほどの結果が出ればいいやってタイプ。で、「ここから先がたいへん」というところでは素直にお金を積んでプロに頼む。間違いなく仕上がりはそのほうがいいからね……。
■セミバケットのすゝめ
https://anond.hatelabo.jp/20210529213157
■自動車って、逆さまで走れますか？
https://anond.hatelabo.jp/20210529002625
何事もなければ社長が死んだショックだけで終わったかもしれない。
7Payと言えばわかるだろうか。詳しくは書けないのだけど、あれと似たようなことが起きてしまった。
かなりのストレスだったと思う。ネットで調べたところ、急性心筋梗塞はストレスでも発症することがあるらしく、そこが少し引っかかってしまった。
様々な理由から現状社長の訃報を知らせるページを検索エンジンにインデックスされないようにしています。
もし心当たりのある会社があった場合でもリンクは貼らないでいただけますようよろしくお願いします。
使うのであれば、ライブラリ、フレームワーク、ミドルウェアの更新（バグ、脆弱性情報）を一生追い続ける覚悟で使ってほしい。
テスト自動化とかそういう発展的なものではなく、もっと根本的なテストについて勉強してほしい。
コードレベルのカバレッジとかそういうのではなく、「境界値分析」、「デシジョンテーブル」、「オールペア法」、「直交表」こういう物について勉強してほしい。
他にもいろんな手法はあるのだけど、上記に上げたもので1個でも知らない単語があった人は今すぐ検索してほしい。
いくら進捗が悪いからと言ってお客さんに順調などと嘘をつかないで欲しい。
遅れている理由を正直に言って（例えばテストの工数が膨れているとか）相談すればお客さんもわかってくれるかもしれない。
また、テストの質もそこまでの物が求められていないとかがわかるかもしれない。
お客さんに相談しないで工数圧縮の為にろくなテストも書かないで動いてるからいい！っていうのは危ない。
自信がない、もしくは、やったことがない・使ったことがない、などは正直に話してほしい。
もしかしたらそのせいで給料があがらなかったり、出世できなくなったりするかもしれない。
だけれど、その嘘のせいで他の誰かに負担がかかったり、他の誰かが不幸になるようなことがあってはいけないと思う。
これに関してはいろんな批判があることは覚悟している。嘘をついてでもいろんな経験をした方がいいって言う人もいると思う。
それでも、どうしても書きたかった。
別にLPIC(LinC)は持ってなくてもいい。本屋で適当に対策本をパラパラめくって、聞いたことのない単語がないレベルであればいい。
インターネットには嘘が散りばめられている。昔は本当だったけど今は嘘になっているものだってある。
一番いいのはエラーメッセージを出している物のソースコードを読むこと。二番目はドキュメントを読むこと。それでもわからない時だけ検索してほしい。
そして、その情報が誰が書いているかをよく見てほしい。書いている人が本当に信用できる、かつ、更新日付が近かったときだけそこの内容を信じてほしい。
公開リポジトリにpush/commitされているメールアドレスを収集している人がいるということ、
公開リポジトリにpush/commitされている秘密情報を収集している人がいるということ、
RDBによってはSQLのIN句に指定できる数に上限があること、
他にもいろいろあるが、1個でも知らないものがあった人は検索してみて欲しい。業界にもよるかもしれないが、本来であれば最低限知っておかなければいけない知識。
これを知らないと適切な設計、ましてや適切なコーディングすらできなくなる。
ぼくはエンジニアに向いてない
ウォーターフォールとか知らなさそう
上流工程だけをやるようなSIerは廃れていくだけなので増田の落胆もわかる
でもSIerの就職経験がエンジニアとしてダメかというとそんな事はない
SIerと言われる受託開発を経験してWeb系と言われるサービス系企業に転職しておどろいた事がある
それはみんな設計はできないしプロジェクトを上手くまわせない事だ
モダンな技術や流行りの技術を取り入れたりテストコードを書いてカバレッジを計測したり
「まだ安定していないその技術使うの?」 って思ったり、「それ個人開発のライブラリですよね? メンテ大丈夫ですか?」って思ったり
とりあえず「流行ってるから使ってみたい」で使おうとする人が多い
サービス立ち上げ初期のスタートアップなら理解できないでもないけど、そうでもない規模でもよくいる
コードを書く時も自分の見える範囲でのみ使えるコードを書くので、他の仕様と整合性がとれなくて再利用性がなかったり
技術者上りのマネージャは大体が技術についていけなくてマネージャになったような人が多いので、自分の中で理解できる知識に落してくるので説明するのも大変だし言ってくる事も古くて意味がわからない
そういう人に限って技術者だったって言うのを誇りにしてるから自分の中の技術を間違ってると認められなくて頑固だ
技術者上がりじゃないマネージャは大体がディレクターやってましたという人でUI/UXとか言ってくるけどバックエンドは一切わからなくて設計なんてできない
そしてどちらもマネージャとしての知識がないのでマネージメントは上手くない
たまにスーパーエンジニアがいて、その人が開発をしつつマネージャー以上にマネージメントをしてプロジェクトをまわしている
SIerで設計を学びつつ開発は個人でやっていき、数年たったらサービス系の会社でスーパーエンジニアとして無双すると良いとおもいます
というか、
ＡＳＩＣやＬＳＩを作ったことある人なら、当たり前すぎることなんだけど、
語弊があるどころかニュアンスが逆なんだよね。
開発者にとって楽になるどころか難しい方向に行くんだよね。
「フロントエンドのみArm命令に置き換えた形」という文言は、
「中身は前のまんまw」「命令セット入れ替えただけなんすわw」「命令デコーダをarm化したSparc64です。」という意味ではなくむしろ逆で、マイクロアーキテクチャが共通になるように、DDRとHBMの差分を見えなくしたりレイテンシを調整したりetc...して、ほとんど全部Verilogを書き直したってことなんだよね。
で、なぜそこまでしてマイクロアーキテクチャを共通化するかっていうと
LSIチップの検証って組み合わせパターンが天文学的数字すぎて分岐網羅とか全然できないんだよね。
ソフトウェア的な分岐網羅に換算したら0.1%となんじゃないかな。
そこでマイクロアーキテクチャを共通化してると、過去チップのLSIテストケースを流用できるわけなんだな。
