「カバレッジ」を含む日記 RSS

はてなキーワード: カバレッジとは

2024-01-07

開発チームでチームリーダー新人がぶつかって開発が進まない

私はPM要件決め、設計などは得意だが、細かい技術的な部分はよくわかっていない。

チームリーダーB:経験豊富。全体設計もできて、コーディング速い。顧客折衝もできる。

新人C:経験浅い。コーディング遅め。devopsやプログラム言語についての知識がある。こだわりが強い。SNSでもいろいろ発信。

チームリーダーBと新人C、お互いがお互いを下に見ている。

私は板挟み。

チームリーダーBは頼りになる。新人Cも最新の技術的な動向を追っていて、いろいろ知っていて関心する。いわゆるベストプラクティスというのは新人Cが提案するやり方なのかな、と思う

たとえば、クラス設計インターフェースを用いてもっと疎結合コードを組むべきだとか、テストコードカバレッジもっと上げないととか、言ってることはもっともだと感じる。

チームリーダーBはそういった細かいところにわりと無頓着なのかもしれない。ずっとやってきたやり方に固執してる部分もあるだろう。

私が若かったころは先輩のやり方は絶対だったため、こういった揉め事は少なかったように思うが、

最近新人学生時代ネットで多くを学んでいるため、知識豊富理論武装もすごいため、先輩が言い負かされてしまうケースも多い。

私の意見としてはBもCも良い部分があるため、どちらの意見採用したいところだが、相性がよくない。

BはCのやり方だと、他のメンバー(DやE)の面倒もBが見ることになり、自分負担が増えると言う。

ただ、保守性の高いプロダクトにしておかないと、長い目で見たときにあとあとキツくなってくる気もする。

あと、CはCで時間を掛けてばっちりテストコードを書いてるはずだが、経験が浅いせいかテスト環境デプロイさせると、かなりバグを発生させている。。

どうしたらよいだろう。

2023-12-06

anond:20231206174416

ツッコミを入れておくと、既に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. "

と書いてるように、このフォビア全開な内容を価値があるとするのは、それはそれで傲慢でしょってのもある。

学術価値を優先するならフォビアを抜くのは造作もないはずなんだから

とはいえ、抗議だけで差し止められるようになればそれは研究への間接的な検閲というのもその通りだから懸念するのもわかるんだよね。

※なお、GD-ASDの併発の

GDASDADHDの相関を調査したので有名なのはこれ。

https://doi.org/10.1007/s10508-014-0285-3

性差研究でよく扱われるCRMP4がASD関係している可能性を示した論文もあるので、

視床下部ターゲットにした非定型遺伝子発現が場合によっては両方に影響するという仮説は立てられる。

ASDは元となる遺伝子異常があまりにも多岐にわたるもので、様々な原因が同じような症状を呈するために一つのスペクトラムとして扱ってるようなものなので、いつか個々の原因に分解できるようになればどれが原因ならば併発するかは分かるようになるだろう。その時はまた新たな社会的問題になるだろうけど。

2023-09-02

プログラミング20年だけど、この年になって守破離の離に到達した気がする。初心者はクソコードを書く。上級者は変更が容易でテストカバレッジ100%みたいなコードを書く。離に達した者は、変更の必要が無いコードを書く。変更の必要が無いかテスト必要無い。SOLID原則で言うところの、open closed原則に近い。モジュールをうまく分けると、個々のモジュールは変更の必要がなくなる

2023-07-05

anond:20230704231859

うだうだいう暇あったら、レビューの前にデバッグツールでチェックさせろよ。

カバレッジフラグが立っていないロジックがあったら小一時間問い詰めろ。

2023-05-27

はてな退職エントリを書いています

私は約3年間、はてなエンジニアとして働いていました。

この期間に、様々なプロジェクトに関わり、多くのことを学びました。

今回は、私が経験した技術的な話を中心に、はてなでの仕事について振り返りたいと思います

 

## RailsでのWebアプリケーション開発

はてなでは、主にRuby on Railsを使ってWebアプリケーションを開発していました。

はてなログはてなブックマークなどの有名なサービスはもちろん、社内向けのツール新規事業プロトタイプRailsで作っていました。

Railsは、高速に開発できるというメリットがありますが、それと同時にコード品質パフォーマンスにも気を配る必要があります

私は、テストリファクタリングコードレビューなどの技術的なプラクティス積極的に取り入れることで、Railsの開発をより効率的安全に行う方法を学びました。

例えば、私が担当したプロジェクトでは、RSpecやRuboCopといったツールを使ってテストカバレッジコード規約をチェックし、GitHub ActionsやCircleCIといったサービスを使って自動化しました。

また、Pull RequestやPair Programmingといった方法を使ってコードレビューを行い、バグ改善点を見つけたり、知識ノウハウを共有したりしました。

 

## クラウドサービスでのインフラ構築

また、はてなでは、AWSGCPなどのクラウドサービス活用してインフラを構築していました。

私は、DockerKubernetes、Terraformなどのツールを使って、コンテナ化やオーケストレーションインフラストラクチャ・アズ・コードなどの技術実践しました。

これらの技術は、開発環境と本番環境差異を減らし、デプロイやスケーリングを容易にするという利点がありますが、それと同時に複雑さやトラブルシューティングの難しさも増します。

私は、モニタリングロギングアラートなどの技術的な仕組みを整備することで、インフラ運用をより安定的信頼性の高いものにする方法を学びました。

例えば、私が関わったプロジェクトでは、DatadogやCloudWatchといったサービスを使ってシステム状態パフォーマンス監視し、SlackやPagerDutyといったサービスを使って異常や警告を通知しました。

また、ElasticsearchやFluentdといったツールを使ってログ収集分析を行い、原因究明や改善策の検討に役立てました。

 

## チームでの協働

はてなエンジニアとして働くことで、私は多くの技術的なスキル知識を身につけることができました。

しかし、それ以上に大切だったのは、チームで協力して問題解決することでした。

はてなでは、エンジニアだけでなくデザイナープロダクトマネージャーなどの他職種とも連携してプロジェクトを進めることが多かったです。

私は、コミュニケーションフィードバックドキュメンテーションなどの技術的ではないスキル重要だと感じました。

私は、自分意見提案積極的に発信することで、プロダクトやサービス品質価値を高める方法を学びました。

例えば、私が参加したプロジェクトでは、SlackZoomといったツールを使って日常的に情報交換や相談を行い、BacklogやJiraといったツールを使ってタスク管理や進捗報告を行いました。

また、FigmaMiroといったツールを使ってデザインアイデアの共有やフィードバックを行いました。

 

## 退職への決断

私は、はてなエンジニアとして働くことがとても楽しく充実していました。

しかし、私は自分キャリアについて考える中で、新しい挑戦をしたいという気持ちが強くなりました。

私は、自分の興味や関心のある分野にもっと深く没頭したいと思いました。

そこで、私はこの度、はてな退職することにしました。

私は今後、別の会社エンジニアとして働く予定です。

 

## おわりに

はてなで働いた3年間は私にとってかけがえのない財産です。

私は、はてな出会ったすべての人に感謝しています

に私が所属したチームのメンバーには大変お世話になりました。

彼らから学んだことや刺激されたことは数え切れません。

彼らと一緒に仕事ができたことを誇りに思います

彼らに感謝する気持ちを込めて、このエントリーを書き終えたいと思います

 

以上、AIによるフェイ記事です。

どの程度、真実味がありましたか

2022-12-27

唐揚げおせち

Z世代にとっておせちと言ったら唐揚げらしい。

唐揚げって何?そう疑問に思ったがきっとKFCチキンのことを唐揚げと言っているのだろう。輝かしきZ世代実用性の高い知識に富む一方でカバレッジには欠けるらしい。唐揚げチキン区別がつかないとは恐れ入った。

日本は何においても貧しくなったな。KFCチキンはありがたく食しておせち文化蔑ろにするんだから

とはいえ今の時代を生きるのはZ世代。古臭い文化とか習慣といったものアップデートしていく。パパ活梅毒流布の梅カツ女子合理主義を地で行く輝かしく頼もしい日本次世代

唐揚げおせち。いや、KFCチキンおせち。Z世代のみならず貧しい日本の皆様もいかがでしょうか。

2022-11-30

anond:20221130134213

横だけど計算複雑性理論よりバックエンドテストカバレッジだろってのは同意だわ 個人的にはカバーしてないこと自体が鯖落とした奴にお前が悪いって怒鳴っとけばいいだろ的思想に見えてキモい

2022-07-02

anond:20220702215453

全ての男の遺伝情報は,全ての男の全ての遺伝情報とは異なります

技術的な話で恐縮ですが,父親判別するのが目的ならば,全ゲノムを解析する必要はなく,ユニークな部分だけ解析すればよいです.

計算上は大体14カ所のSNPsを記録すればよいと思います

バーコーディング技術と超並列シーケンサーを用いれば,100万円で1000万人分くらい解析できてしまます.この計算ではカバレッジ=3強ですので,大分手抜きなのですが,もしも容疑者複数名になってしまった場合でも再解析すればよいので,実用問題ないはずです.

サンプル採取コストがかかりそうですが,新型コロナウイルスワクチン注射PCR検査の実績を見れば物理的に無理ってことは全くないですね.

それでデータ量は数百GBってところでしょうか.なんせ肝心要の部分だけなら一人につき56ビットですので,1億人でも56ギガビット,つまり8GBでお釣りが来ます

つうわけで技術的には可能です.ただ,本番データを落っことしたりすると厄介ですので,そんなデータベースは当分作らないで欲しいと思っちゃいますが・・・

2022-02-07

28歳専門卒Webエンジニア高望転職活動現実

転職歴としては1社目は新卒で入った地元の零細受託Web制作会社→4年前くらいに転職現在自社サービス企業に勤務中。

ちなみにまだ内定は0件。

コロナを機にフルリモート案件が増えたのと、リーダー経験とか積むにつれて市場価値と今の職場が合わなくなってきたのがあるのと、

今の年収だと婚活で戦うのはかなりきついということを実感したので動き出すことに。現年収は400万ちょっとくらい。

専門卒で経験PHP/JS中心だから経験してきた技術スタック学歴的にはあんまり上位狙えるようなアレじゃないんけど今回は心が折れるまでは初年度年収600万を目指すことに。

現職でのリーダー経験と、Saasを立ち上げから設計・開発全部8割型自分で進めて競合と戦えるサービスに成長させた経験とか、ゼロイチで既存案件DDDに移行したりテスト駆動体制を導入したりとか、まあまあ個人開発もやってますよとかその辺をアピールポイントとして戦うことに。

感覚としては「500万までは余裕だけど600万はきつい」だわ。

1社目

まず某転職サイトに応募すると早速600万のスカウトが来たユニコーンベンチャー。フルリモート

貴方Saas開発経験に魅力を感じ~」とか書いてたから誰でも送ってる風じゃないと思い応募。

結果はなんと書類選考落ち。いや学歴とか職務経歴とかほぼ転職サイトにそのまま書いとったやん。

らくだけど選考時にGithubアカウントとかTwitterアカウントを求められたとき仕事のものセキュリティ上渡せないとか渋ったのと、

渋々渡した個人Githubアカウントオープンソース活動とかはしたことなかったからこれがしょぼいって思われたのかな?って思った

ちなみにこの会社から書類選考落ち後に各転職サイトから5回くらいスカウトが来てる。

2社目

大手っていうわけではないけど割と有名なSaas企業。こっちもスカウト転職サイトの上の方でよく見る気がする。

結構近しい分野のSaasを立ち上げから関わったことがあるのでこちらを武器面接へ。1次面接落ち。

面接は割とうまく行ったと思うけどなぁ、って思ったけどやっぱりフルリモートでこの給与帯の休日は倍率半端なさそうだからちょっといくらいだと全然落ちるんだなと実感。

3社目

立ち上げから3年も経っていないベンチャー、ただし既に利益率は割と凄い感じで業界的にも硬そうだから応募。

カジュアル面談ときCTOに是非応募してほしいって直接言われた。

1次の技術面接レベルがたけぇ。○○の設計思想の内容だとかDIコンテナとかReactの状態管理ライブラリ運用とかの質問クイズ形式っぽく質問される。

割とうまく答えられたと思ったけど1次面接落ち。

4社目

有名地元拠点がある東証一部上場の自社サービス企業。600万の求人と450万の求人で分かれてて600万の方で応募したら書類選考で「600万は厳しいけど450万なら良いですよ~」って言われてる状態

やっぱ相場観的にはそうだよなぁって思った。

今週1次選考だけど受かっても年収交渉時に450万しかもらえないなら辞退しちゃうかも。

5社目、6社目

名医療系ベンチャーと車業界系のSaasカジュアル面談要請出すも音沙汰なし。

別の転職サイトで確認すると応募条件大卒以上って書いてたから多分それが原因。ちゃんと書いとけや。実質書類落ち。

7社目

少人数の建築ベンチャーHP情報量も少なく恐らく資金調達フェーズでは?って感じの企業

なんとなく社長から与沢翼匂いがする。まだマネタイズまで行けてないのに何百億とか何兆とかやたらでかい数字を言いたがる感じ。

技術スタックに対して年収が高すぎるのが逆に怪しい感じがする。

一応最終選考まで残ってるが、通ったとして行くべきかは悩みどころ……

8社目

スカウト来て応募。かなり好感触だが求人票と実態の下限年収に相違あって思ってた年収より100万くらい下がりそう。

技術スタックとかは良かったんだけど辞退するか悩み中。




年末くらいから始めた転職活動。今週も面接面接面談面談面接

自分市場価値みたいなところは良くも悪くも痛感する。500万までのスカウトはよく来るけど600万になるとやっぱなかなかこない。これが相場観なんだろうなって感じ。

テックリード」とか「シニア」とかのスカウトは全く来ないからまだそういうレベルではないんだなぁって。

「誰もが知る有名企業年収600万」は多分俺のスペックだと無理ゲーで、あとはいかに穴場のベンチャー狙えるかっていうところにかかってる感じ。

それはそれで安定捨てて市場価値より高い会社に勤める感じになるわけだし将来トータルで考えるとそれはそれで大丈夫なの?って感じもある。

でも専門卒じゃ20代年収600万くらい武器ないと婚活じゃ戦えないしなぁとも……はよ彼女作ってこの悩みから開放されたい……

エントリーする度にそこで働く未来自分を思い浮かべるのに祈られた瞬間に全部がなかったことになるの辛い


あとカジュアル面談受けまくってるけど、これが割と面白かったりする。

「こんな有名企業だけどQAは俺がリーダーやってる案件のがカバレッジ率とかしっかりしてるんだー、バグったら人が死ぬタイプシステムじゃないし逆に今の運用が過剰品質すぎなのかなぁ」「LeSSって開発手法あるんだー」「前職も現職もSelenium導入って微妙な感じになってるけどこのMablってテストツールだと割と良い感じかも」「今の職場みたいに運用フェーズエンジニア部署KPI設定を半期ごとに設定するのは粒度がでかすぎるよなぁ、この会社みたいに1ヶ月周期とかで設定した方がよさそう」「ワーカーサーバーの悩むポイントはどこも同じだなぁ、でもやっぱGoだとPHPよりも並列処理強いんだなぁ」

他の会社運用とか技術スタックの話を深堀りして質問しまくれる機会とかなかなかないから、落ちたは落ちたなりに吸収できるものはある気がする。

あと社交辞令かもしれんけど「いやその経験技術力で今の年収はどう考えてもおかしいっすよ」とか結構言ってくれるの嬉しい。



まだまだ戦いは長そうだ……俺が心折れて高望みを諦めるのが早いか内定取れるのが早いか勝負、こんな感じです。

2022-01-14

Webエンジニアだけど転職活動うまく行かーん

28Webエンジニア。今の年収は400万くらい。

地方の自社サービス開発企業に勤めててその中ではテックリード的な立場

Saasシステム設計フェーズから1から構築したこともあるし、

他にもレガシー目なサービスDDDクリーンアーキテクチャ思想を導入したりTDDの構築と運用へあたっての体制構築や教育を主導したりとか

メンバースキルに偏りがある状態でも品質維持するための体制をなんとか作ったりとか

小さい企業ながら割と経験詰めたし今なら転職とか余裕だよなーって思ったがなかなかうまくいかない。

今のところ3社受けて全部1次面接落ち。受けたのは転職サイトのトップページに一番大きく載ってるような人気企業から倍率は結構高い気はする。

今のところフルリモートで初年度年収550万~600万くらいを目指してる。多分500万くらいまで水準下げれば求人めっちゃ増えるし余裕な気はする。



あっちからスカウトが来て、競合ではないけど似たようなサービスを俺も構築した経験があったか

御社製品の○○機能(リリースされたらプレスリリース打つくらいの機能)と似たようなもの営業にほしいと言われてから2日後にはテストカバレッジ100%状態リリースまで持っていきましたとか、

当時はリソース足りず自分一人でほぼ全部対応してたけど爆速リリースサイクル回して1年で機能数的にも競合製品に負けないくらいまで成長させましたとかこれ以上ないくらアピールしたよ。

それで受けたのに1次落ちなのはちょっと凹んだ。

なーにが行けなかったんだろう。やっぱコミュ障なのが影響してんのかなぁ。「えーっとまあ」とか「なんか」「えーーそうですね…」みたいなのが多いのは自覚してる。

フルリモート給与高水準だと倍率高いから、もしかしたら20人中の1人や2人採用で第3位だったとかかもしれない。

何をどう変えたらいかなぁ。

転職指南書に書いているようなHP企業理念読んで面接官が喜びそうなことを事前に作文して頭に叩き込んでおくみたいなことはやりたくないんだよね。

会社じゃ面接官する側だけどポートフォリオとか職務経歴しょぼいのに口だけ凄いこといってると

「ああ、この人面接官喜ばすための言葉を事前に作文してきたんだろうなーーー」「この人は”面接が”上手い人なんだな」とかやっぱ内心思っちゃう

まあ応募して落とされて凹んでまた応募してを繰り返すしかないのかな。

超人気の高望企業に3社落とされるだけでちょっと凹むのに就活生は凄いね。。

2022-01-03

技術力が低いエンジニア」への対処法って実際どうすればいいの?

今ちょうど対処法に頭を悩ませてる、ここまでの人は正直人生初。

バグが多い、レビューの指摘数が多い、投げた仕事がわからない・できないで投げ帰ってくる、基本的アーキテクチャ理解できてない、成果物が出てくるのが遅い

ざっくりとこんな感じ。


今のところこんな感じで対処してる。

正直「こんなに時間をかけて詳細に指示書いてこんな数の指摘を説明しなきゃいけないのだったらその人に振らずに俺が1から対応した方が数倍以上早いしこれは一体何を生み出している時間なんだろう」みたいなことを自問自答しながら作業してる状態

この人経験年数自体結構いからこれがまたややこしい。

これが新入社員とかだったら多分立ち回り方も結構変わると思う、できなくてもそれは経験不足から来るものだし、多分『教育』って形で結構時間かけて丁寧にペアプロして習熟度を上げてもらう感じかな。

2年目くらいでまだ戦力になれてない社員だったら多分3年目とか4年目くらいの誰かしら(できれば数人)と相談して教育係として俺との間に誰かを挟んでコミュニケーション上の距離を置いて負担をチーム内で分散する形にすると思う。

ただ経験年数長いで今更新教育みたいなことをするとプライドを傷つけかねないし、ぶっちゃけこの経験年数でこれなら教育にパワーかけても効果薄そうっていうのもある。

あと単純に社内リソースが足りなくて俺がなんとかしなきゃいけない状態

これどうすっかなぁ。プログラミングとはまた違う頭使うぞ。

2021-12-02

anond:20211202232542

時々神経質なおっさん

100%目指せとか言ってるけど

気にしなくて良いぞ

まー、テストコード書きにくい実装

何か把握するのと、処理に対して

想定のテストコードを書けるようになる

スキル有用(そもそもテストコードから

書くべきだが)というか、それが最低限

な気がするが

あと自動テストって話なら、カバレッジあん関係ないと思うぞ?

自動テストってどこまでやればいいの?

カバレッジ100%目指せばいいの?

2021-10-29

程良い難易度で新しいことを覚えて行くのは楽しい

1. Markdown, Textileは知っていた。

2. 「何か新しいことを覚えようかなぁ」というコレクター魂のようなもので、reStructuredTextの手を付ける。

3. Sphinxなるものを知る。PythonからDjangoとか、あの見慣れたチュートリアルを作るドキュメントツールSphinx

4. 面白いのだけど登場人物が多くて話が追えないなろう系のメモとして使ってみる。

5. 慣れた頃に、高校物理数学の復習へ逸れる。

6. LaTeX記法での数式表現、Matplotlibの機能に感動する。

7. 気づくと書き貯めたメモ(rstファイル)が大量に…

8. 索引ページに気づく。

9. 日本語表示がイケてない。微分なら「は」の項目に、積分なら「さ」の項目に表示してほしいじゃん?「微」「積」の項目なんよ。。英語と同じように「頭の一文字」を取ったらそうなるよね。

10. 探してみたら、「Yogosyu」というプラグイン(※Sphinxでは拡張モジュール)があった。使ってみる。

11. 最新のSphinx対応していない。ここからPythonコード解析へと逸れる。

12. 取り敢えずエラーはでなくなったけど、元々索引ページとは関係ない機能だった。同一「用語集」での表示順が日本語対応するだけ。

13. (しばらく放置

14. 「単語の先頭に振り仮名を付け足せば、いい感じにソートしてくれる?」と気付く。

15. 表示の直前で「振り仮名」を取除くために、どこで表示しているか探す。

16. (紆余曲折

17. 索引ページで思ったように表示されて喜ぶ。

18. ここで初めて「プラグイン形式にすれば良くね?」と気付く。

19. 他の拡張モジュールソースを見てやり方を学ぶ。

20. 出来上がって喜ぶ。

21. ここで初めて「これってクラスにしたら、全体の見通しが良くなったりする?」と気付く。

22.(この辺りで、unittestモジュールに手を付ける)

23. テストケースのお陰でリファクタリングが怖くない。喜ぶ。

24. setup.py, setup.cfgの書き方を学ぶ。

25. pypi公開を果たす。誰にも知られずひっそりと…

26. テストケースにjinja2を通した結果も加える。一人で成果に喜ぶ。

27. githubに手を付ける。学ぶ。基本的なことは覚える。

28. スタックオーバーフロー登録モブ参上

29. stack overflow登録モブ参上

30. teratailに登録。コソコソ。「何がなんだか分からない」では質問しないし、そのうちどうにかなることが多い。先駆者感謝

31. toxを知る。学ぶ。基本的なことは覚える。

32. coverageを知る。学ぶ。基本的なことは覚える。

33. circleciを知る。学ぶ。基本的なことは覚える。

34. カバレッジが90%を超えて喜ぶ。←今はこの辺。

※ボッチの日常

2021-06-10

手洗い洗車の基本を解説するよ《蛇足編》

いつもクルマネタ増田は反応がほとんどないんだけど、今回はこちらの記事に珍しく(少しだけ)反応があって(少しだけ)うれしい。

■手洗い洗車の基本を解説するよ
https://anond.hatelabo.jp/20210609143814

 

前回は基本編だったけど、今回はちょっとステップアップ。手洗い洗車してみたらまあまあ楽しかった、もうちょっと自分でできることを増やしたいなーって人向けだよ。と、言いつつも、大半は俺が書きたかっただけの蛇足だよ。

さて、作業の質をステップアップしようとすると、だいたい使う道具や洗剤を買い足すことなます。つまりステップアップと追加投資はほぼ同義だよ。

ホイール洗浄のステップアップ

ブラシを使う

基本編ではホイールを洗うのにスポンジを使ったけど(使う道具が多いとアレかなと思って省略した)、ホイールはブラシで洗ったほうが効率がいいよ。風呂桶を洗うような柄付きのホイール用ブラシがホムセン行けば200円くらいからある。なので基本編から何かを買い足すならばまずはホイールブラシをおすすめする。お手元のホイールスポークタイプ(中心から放射状に柱が立ってるデザイン)なら、スポークの間をくぐり抜けて奥まで洗えるやつがいい。ホイールの形状をよく確認してブラシを選ぼう。

クッソ便利そうだけどクッソ高いホイールブラシがひとつあって(商品名は伏せる)、朝起きたら枕元に置かれてないかなーと毎晩祈りながら就寝してる。

鉄粉除去

うっすら鉄サビのオレンジ色に染まってるホイールとか、全体が黒ずんでるホイールあるよね。こういうのはブレーキが削れて粉になった「ブレーキダスト」の成れの果てだよ。どんなホイールでも多かれ少なかれブレーキダストを浴びていて(ヨーロッパ車で大柄なやつの前輪とかは特にスゴイ)、これを手洗いで落とすのは正直めちゃくちゃたいへん。落とすには「鉄粉除去剤」を使おう。「チオグリコール酸アンモニウム」っていう成分が含まれてればOK。こいつをホイール全体にまんべんなくスプレーして放っておくと、薬液が鉄粉と反応して紫色の汁が流れだします。5分くらいで落ち着くので、シャンプーで洗えば完了

ボディ洗浄のステップアップ

細部には筆やハケ歯ブラシ

モールの境目とか、エンブレムオーナメントとか、くぼみや隙間や細かいところ、隅っことか角っこにはスポンジ(と目)が届きにくい。

そういう場所の汚れは、小さなサイズのスポンジとか筆とかハケを使うと落としやすいよ。使い終わった歯ブラシなんかも場所によっては役に立つよ。洗車用品はとてもたくさんの専用品が売られてるけど、ホームセンターに行ったらカー用品以外の売り場もよく歩き回って「これアレに使えそうじゃん?」とひらめいた道具を使うのも楽しいよ。案外専用品よりずっと安上がりだったりする。

用途に応じてどんどん道具を増やしても逆に不便なので、カバレッジの広い万能内野手みたいなツールがあるとよいよね。私も模索中です。

ワックスコーティング

車体にワックスコーティングを施すとツヤが出てピカピカになるし、小さな傷なんかは隠れちゃいます。でも、ワックスコーティング効能はピカピカの美観だけじゃないんだな。むしろ、「保護」のほうが恩恵が大きい気がする。ワックスコーティングをしておくと日々の汚れが溜まりにくいんよ。

日々の汚れが溜まりにくいと、毎回の洗車がラクになるし、頻度も減らせる。風化の進行を遅らせてくれるので、駐車環境が悪い人ほどきちんとコーティングしておく意味は大きいよ。下取り価格にもきっとちゃんと返ってくるはず(期待)。

どんなワックスコーティングええんや? と言われてもそこはお答えが難しい。製品は無数にあって効果耐久性千差万別だし、そもそも私はこの部分はいつも専門業者にオマカセしちゃってるので(年イチでメンテナンス)知見が全然ないです。やってみたい人は自分で調べてね。ごめん。

ひとつだけ言えるとしたら、とにかく汚れをバッチリ落としてからやれということ。汚れを残したままコーティングで塗り込めても目立たなくはならないし、そのコーティングもすぐに落ちてしまうよ。

下回り

ロングノズルのシャワーを持ってるとボディの「下回り」が洗えるよ。下回りってのは床下ね。車を四つん這いの亀に見立てると、お腹のところ。シャワーを上に向けて、ボディの下に突っ込んで床下を洗おう。もっとも、最近の車は床下がまるっとカバーで覆われていることもあるので、床下が一枚板のノッペラボーだったら下回り洗浄はあんまり必要ないよ。自分の車の床下がどんな様子かは、スマホを挿し入れて動画撮影すればわかる。

下回りは見えない場所から気分的に優先度が低いけど、その車に長く乗るつもりなら定期的に水で流すくらいしておこう。これも美観を保つというよりはメンテナンスの一貫だね。錆で朽ちてきても気づきにくいのに、いざ老朽化して壊れると修理費はけっこうかかるから……。

下回りも、基本的には水をかぶってはいけない部品はない。ボディ洗いの時と同じで水圧で吹き飛ばす要領でゆっくりとノズルを移動させて、こびりついた泥汚れを落としていこう。

あくま一般論だけど、車軸と背骨なす「エ」の字の周辺は構造物が多くて入り組んでいることが多いよ。なのでこのエリア特にいねいに流そう。逆に、脇腹のエリア基本的にただの床板なのでざっとでいいよ。

雪国に住んでいる人はみんな下回りをていねいに洗ってるよね。これは道に撒かれている融雪剤がサビの原因になるからだよ。雪無し県住みでもスキースノボによく行くって人は、帰ったらすぐに流したほうがいいよ。ちなみに高速SAのガソリンスタンドには高圧洗浄機が使えるところがあるから、帰り道で洗っちゃうのも手だね。上信越道横川SA、関越は赤城高原SA高坂SA中央道談合坂SAガソリンスタンドで高圧洗車機が使えるよ。

ていうか、ロングノズルのシャワーは下回りに限らず重宝するよ。屋根の上が流しやすいし、体が少し車体から離れるので高水圧でも返り血を浴びにくい。

鉄粉除去

ボディにも鉄粉は乗っているよ。でも目で見てわかるようなものではなく、注意して触れば感触でわかる程度のものなので、これからコーティングしようとか研磨しようという人でない限り放っておいてもよいのではと思う。

落とし方はホイールと同じで鉄粉除去剤をスプレーするか、異物除去用の粘土(ネンダーという)で表面をなでてキャッチする。ネンダーはボディ表面を水で濡らして使ってね。

ガラス

スポンジが行き届きにくい窓ガラスのサッシぎわとか隅っこは長年汚れを見落とされ続けて汚れが積もっていってしまうので、なるべく日々の洗車で借金をためないようにしたいところ。

でもカーシャンプーで洗っても油膜やウロコ(雨や洗車の水滴がまだらな模様になってこびりついた汚れ)ってマアー落ちないよね! ワイパーの水切れが悪いなとか、なんか見通し悪い感じがしてきたら、油膜・ウロコ取りをしよう。それ用の洗剤がいろんな種類たくさん売ってます

あと窓ガラスコーティングも雨の日の運転やすさにめちゃくちゃ効果があるので、やったことない人はフロントだけでもやってみよう(ガソリンスタンドとかでもやってくれるところがあるよ)。窓ガラスコーティングもボディコーティングと同じで、「まずは完全にキレイなこと」が施工大前提。汚いまま塗ってもしょうがないです。コート剤にも色んなタイプのものが出ているので、お好みで選んでみてね。

室内

外装の美観には無頓着でも室内は気になってしまう、という人はけっこう多いんじゃないかな。てか、一般的にはそういう人のほうが多いか

室内は基本的におうちのお掃除と同じだ。拾えるゴミは拾う。掃いたり掃除機をかけてチリを払い、汚れてそうなところは中性洗剤とかで拭き掃除

掃除機も高いところから始めて低いところに降りていくといいよ。チリは下に下に落ちていくからね。シートはリクライニングを最大に倒すと背もたれと座面の隙間に掃除機がかけやすいよ。けっこうゴミとか小銭とか前オーナーの屁とかが溜まってるよ。車室内にはドリンクホルダーやドアポケット、センターコンソールの小物入れなど便利なくぼみがいっぱいあるけど、そういうところの底にはゴミも溜まりやすいよ。そして女性はそういうところが汚いことを見つける名人だよ。

拭き掃除はふだん手指で触るところを重点的に、かんたんマイペットとかの中性洗剤で清めればよいよ。ハンドルノブスイッチとかその周辺。広いところはスプレーしたり、狭いところはタオルスプレーして拭いたり。そしてすかさず水拭き・乾拭きで仕上げるとべたつかないよ。

ドライバータバコを吸う人ならば作業範囲は車内全体に及ぶのでしんどいよ。ヤニは溜めれば溜めるほど掃除がたいへんなので、タバコを吸う人は月に一度はあったかい濡れ雑巾で全体を水拭きするようにしたほうがいい(ヤニは水溶性だよ)。

ヘッドライト

古い車はヘッドライトどんより濁って黄ばんでることが多いよね。これをリフレッシュするのは個人的にめちゃくちゃオススメ! スッキリ透明ツヤツヤなヘッドライトにするだけでパッと見の印象がマジでまるっきり違う。ハードルはかなり高いけど、ホント若返るよ。

しかしこれをDIYでやるのは「そういうことが大好きな人」にしかおすすめできない。基本的には磨き屋さんとか板金屋さんに持ち込んで研磨+コーティング施工してもらうのが一番なんだけど、まあ、お高い。両目で1万以上とられると思う(純正新品と交換するのと比べればずっと安いけど)。金銭感覚は人それぞれだし現状がどのくらいみすぼらしいかにもよるけど、とにかく高いお金を払う価値はあると思うよ。

あ、虫除けスプレーヘッドライトの黄ばみが落ちる、と一時期バズッてたけど、私はあまりオススメしないな。たしかに落ちるんだけど、これは黄ばみ層を剥離するだけなのでまたすぐ黄ばんでくる。年に何度もやる覚悟をするか、DIYするならちゃんコートまでできるキットを買ってやったほうがいいかも。

洗車機について

私の車は細かな凹凸が多いデザインで洗車機だと洗い残しがたくさん生じるので、基本的には洗車機は使ってません。まあ、自分で手洗いするのが好きってのも大きいけど。なので近ごろの洗車機の実力とかメリデメとかはちゃんと把握していないんだよね。語る資格なし!

洗車機の世界日進月歩技術革新が進んでいてなかなかハイテクなことになってるみたいなので、ふだん洗車機使ってる人、現代の洗車機事情なんかを教えてほしい。

口コミについて

あれを買えこれを買えといろいろ言ったけど、具体的な商品名は挙げないようにした。商品名を出すととたんに文章ウソくさくなるよね。なのでどれを使うかはみなさん自己判断してほしいんだけども、カー用品店にもAmazonにも似たような製品無限にあって、何を買えばいいかけっこう迷うと思う。

普通にググるタイアップ動画やアフィりブログばかりヒットしてしまうよね。もしネット口コミ判断する時は「みんカラ」でレビューを探すとよいよ。みんカラエンドユーザーコミュニティなので書かれてることは基本的に使ってる当人たちのホンネです。ただし全体的にIQリテラシがやや低め(含む科学リテラシ)なので、そこは補正しながら読んであげてほしい。

ちなみに自分は高機能・高付加価値製品にはあまり興味がなく、単機能ベーシックものをやりくりしてほどほどの結果が出ればいいやってタイプ。で、「ここから先がたいへん」というところでは素直にお金を積んでプロに頼む。間違いなく仕上がりはそのほうがいいからね……。

こちらもどうぞ

セミバケットのすゝめ
https://anond.hatelabo.jp/20210529213157

自動車って、逆さまで走れますか?
https://anond.hatelabo.jp/20210529002625

2021-06-08

TDD本とTDD is Dead関連の記事を読んで

テストコードを先に書くくらい仕様設計が固まってれば後先暗くならない

 ・今の仕様書も設計書もないまま10人で開発してクソほどテストでポシャってる現場つらい、というかそろそろコード捨ててくれ

テストが増えると保守は重い作業になる

 ・これはテストやってて感じてるけど、DBに投入するデータをケースごとに用意しだすと管理がキツくて死ぬ印象がある

テストが十分にあれば仕様変更時のデグレ察知になる

 ・これ本当にテストでやるべきか…?と思ったけどテストが通らない方が気づきやすいっちゃ気づきやすいか

テスト作成者技量依存する

 ・正常入力しかやる暇がないときもあれば、異常入力網羅したいときもある印象

  ・カバレッジツール使えば問題ないって話ではある

 ・仕様煮詰まってないと死ぬってのはありそう

テストモックを多用すると死ぬ

 ・モック使った試しあんまないからようわからん

 ・というかスタブじゃないのねそこ

  ・と思ったらモックオブジェクトがスタブの一種って罠じゃん

2020-12-31

社長が死んだ

2020年最後の日だし吐き出したかった。

社長の死因は急性心筋梗塞だった。

何事もなければ社長が死んだショックだけで終わったかもしれない。

ただ、自分の中ではもやもやが残ってしまった。

7Payと言えばわかるだろうか。詳しくは書けないのだけど、あれと似たようなことが起きてしまった。

社長上司含め、お客さんに平謝りだったらしい。

かなりのストレスだったと思う。ネットで調べたところ、急性心筋梗塞ストレスでも発症することがあるらしく、そこが少し引っかかってしまった。


様々な理由から現状社長訃報を知らせるページを検索エンジンインデックスされないようにしています

もし心当たりのある会社があった場合でもリンクは貼らないでいただけますようよろしくお願いします。

今回謝る事態になってしまった件について技術的?に思ったこ

使うのであれば、ライブラリフレームワークミドルウェア更新バグ脆弱性情報)を一生追い続ける覚悟で使ってほしい。


テスト自動化とかそういう発展的なものではなく、もっと根本的なテストについて勉強してほしい。

コードレベルカバレッジとかそういうのではなく、「境界分析」、「デシジョンテーブル」、「オールペア法」、「直交表」こういう物について勉強してほしい。

他にもいろんな手法はあるのだけど、上記に上げたもので1個でも知らない単語があった人は今すぐ検索してほしい。


  • お客さんに嘘をつかないでほしい

いくら進捗が悪いからと言ってお客さんに順調などと嘘をつかないで欲しい。

遅れている理由を正直に言って(例えばテスト工数が膨れているとか)相談すればお客さんもわかってくれるかもしれない。

また、テストの質もそこまでの物が求められていないとかがわかるかもしれない。

お客さんに相談しないで工数圧縮の為にろくなテストも書かないで動いてるからいい!っていうのは危ない。


自信がない、もしくは、やったことがない・使ったことがない、などは正直に話してほしい。

しかしたらそのせいで給料があがらなかったり、出世できなくなったりするかもしれない。

だけれど、その嘘のせいで他の誰かに負担がかかったり、他の誰かが不幸になるようなことがあってはいけないと思う。

これに関してはいろんな批判があることは覚悟している。嘘をついてでもいろんな経験をした方がいいって言う人もいると思う。

それでも、どうしても書きたかった。


別にLPIC(LinC)は持ってなくてもいい。本屋適当対策本をパラパラめくって、聞いたことのない単語がないレベルであればいい。


インターネットには嘘が散りばめられている。昔は本当だったけど今は嘘になっているものだってある。

一番いいのはエラーメッセージを出している物のソースコードを読むこと。二番目はドキュメントを読むこと。それでもわからない時だけ検索してほしい。

そして、その情報が誰が書いているかをよく見てほしい。書いている人が本当に信用できる、かつ、更新日付が近かったときだけそこの内容を信じてほしい。


ApacheのC10K問題

公開リポジトリpush/commitされているメールアドレス収集している人がいるということ、

公開リポジトリpush/commitされている秘密情報収集している人がいるということ、

MySQL寿司ビール問題

MacOS日本語ファイル問題

文字サロゲートペアについて、

RDBによってはSQLのIN句に指定できる数に上限があること、


他にもいろいろあるが、1個でも知らないものがあった人は検索してみて欲しい。業界にもよるかもしれないが、本来であれば最低限知っておかなければいけない知識

これを知らないと適切な設計、ましてや適切なコーディングすらできなくなる。

終わりに

ぼくはエンジニアに向いてない

2020-10-16

anond:20201015205510

一回きりの設計で本当にシステムは作れるのか?

システムの開発はコーディングして初めて気づくことがたくさんある。

それをしないシステム開発って本当に大丈夫なの?

ウォーターフォールとか知らなさそう

上流工程だけをやるようなSIerは廃れていくだけなので増田の落胆もわかる

でもSIer就職経験エンジニアとしてダメかというとそんな事はない

なぜならきっちりとしたプロジェクト開発を経験できるから

SIerと言われる受託開発を経験してWeb系と言われるサービス企業転職しておどろいた事がある

それはみんな設計はできないしプロジェクトを上手くまわせない事だ

一人一人を見るとたしか技術はある

モダン技術流行りの技術を取り入れたりテストコードを書いてカバレッジを計測したり

「まだ安定していないその技術使うの?」 って思ったり、「それ個人開発のライブラリですよね? メンテ大丈夫ですか?」って思ったり

とりあえず「流行ってるから使ってみたい」で使おうとする人が多い

サービス立ち上げ初期のスタートアップなら理解できないでもないけど、そうでもない規模でもよくいる

コードを書く時も自分の見える範囲でのみ使えるコードを書くので、他の仕様整合性がとれなくて再利用性がなかったり

俯瞰して全体の仕様見てる人いるのかなって思う時もある

技術上りマネージャは大体が技術についていけなくてマネージャになったような人が多いので、自分の中で理解できる知識に落してくるので説明するのも大変だし言ってくる事も古くて意味がわからない

そういう人に限って技術者だったって言うのを誇りにしてるから自分の中の技術を間違ってると認められなくて頑固だ

技術者上がりじゃないマネージャは大体がディレクターやってましたという人でUI/UXとか言ってくるけどバックエンドは一切わからなくて設計なんてできない

そしてどちらもマネージャとしての知識がないのでマネージメントは上手くない

たまにスーパーエンジニアがいて、その人が開発をしつつマネージャー以上にマネージメントをしてプロジェクトをまわしている

それがWeb系と呼ばれるサービス系の実態

個人的にオススメするキャリアパスとしては

SIer設計を学びつつ開発は個人でやっていき、数年たったらサービス系の会社スーパーエンジニアとして無双すると良いとおもいます

開発は個人でもできるし、IPAドキュメントなんて1回も読んだ事のない人しかいない所で無双するのは簡単です

2020-06-25

anond:20200625063230

というか、

ASICやLSIを作ったことある人なら、当たり前すぎることなんだけど、

語弊があるどころかニュアンスが逆なんだよね。

マイクロアーキテクチャ共通化するっていうことは、

開発者にとって楽になるどころか難しい方向に行くんだよね。

フロントエンドのみArm命令に置き換えた形」という文言は、

「中身は前のまんまw」「命令セット入れ替えただけなんすわw」「命令デコーダarm化したSparc64です。」という意味ではなくむしろ逆で、マイクロアーキテクチャ共通になるように、DDRHBM差分を見えなくしたりレイテンシを調整したりetc...して、ほとんど全部Verilogを書き直したってことなんだよね。

で、なぜそこまでしてマイクロアーキテクチャ共通化するかっていうと

チップ検証で、過去資産活用するためなんだよね。

LSIチップ検証って組み合わせパターン天文学的数字すぎて分岐網羅とか全然できないんだよね。

ソフトウェア的な分岐網羅に換算したら0.1%となんじゃないかな。

そこでマイクロアーキテクチャ共通化してると、過去チップLSIテストケースを流用できるわけなんだな。

でも、カバレッジ全然ないのに、もしLSIバグがあると作り直しにウン億円ぐらいお金かかるからね。

これは国プロからそこらへんどうしてるんだろうね。

2020-05-22

anond:20200521225730

プログラミング言語を印象批評している記事に触発されて、自分も印象批評してみようと思う。

JavaScript以外にもブラウザ上でぐりぐりするのにはJava AppletとかFlashとかSilverlightかいろいろあったけれど、結局標準化を成し遂げたHTML5に淘汰されちゃった感じがする。LiveScriptからJavaScript改名されたり、規格を話すときECMA Scriptだったりといろんな別名を持つ。一応、プロトタイプベースオブジェクト指向言語なんだけれど、それを意識してコードを書く人がどれくらいいるかは謎。

Pythonは小さいコードを書くのには楽だけど、これで大きなコードを書くと思わぬ変更で思わぬことが起きるのでつらい。しばらく使うとPythonイヤイヤ病にり患し、goを使うようになるらしいとか、ならないとか。pythonで大規模なコードを万一書こうと思うなら、カバレッジが高いテストを書いてくれと思う。

Javaは初期のころオートボクシング / アンボクシングもなく、ストイックオブジェクト指向言語だった記憶がある。ただ、staticを多用してオブジェクト指向とは程遠いコード簡単に書けるので、Javaで書いているからと言ってオブジェクト指向だと思うのは禁物である

PHPWebネイティブ言語で、初期のころHTTP POST/GETなどで渡された変数がそのままプログラム中に出てくる機能初期化していない変数最初に使うと空文字列あるいは0で初期化するという機能があった。また、文字列数字臨機応変に切り替える機能もあり(今もそうかは知らん)、数字文字比較比較演算子(==)でシームレスにできる。パスワードチェックみたいなコードで===ではなく、==を使っているとPHPを知らないバカ扱いされる。

C#Hello Worldくらいしかいたことないから知らん。monoのような互換環境があるのは知っているけれど、わざわざPC Unix上でmonoを使う気分にはなれなかった。

C++黎明期に使った感じと、C++11以降に使った感じが驚くほど違う言語。今はかゆいところには大抵STLで手が届くし、autoを使えばイテレーション腱鞘炎になることもない。PC Unixにも最初から環境インストールされているか簡単インストールできるので毛嫌いせず使うとよいと思う。

Rubyはぎょっとする変更をよくやるというイメージ。これで書かれたプログラムを長年愛用してきたが、ぎょっとした変更を入れられて動かなくなったのでgoで書き直した。その点ではpythonも3でおいていかれたので嫌い。

CSS...はプログラミング言語なのか?そうか。

TypeScriptは書いたことないから知らない。JavaScriptだと大規模コードを書くとつらいのでTypeScriptを使おうという人がいるのは知っている。大規模なコードを書くとしたら、インタフェースに合った呼び出しかコンパイル時にチェックしてくれるような強く片付けされた言語のほうがよくなってくるというのはわかる。

Cは片付けし、構造化したプログラムを書きやすくしたアセンブラ...というイメージだったんだけど、C99くらいから便利機能がいろいろ入ってそうでもない感じになった印象。昔はCのコードを見たら最適化した後のx86アセンブリが見えていたんだけれど、最近は見えなくなってしまった。子供のころ、本屋で秘伝C言語問答 ポインタ編に出会ったのがこの業界に入るきっかけだったのかもしれない。ほかの言語でいろいろ楽に書けるからカーネルをいじるか、システムコールをたたくかするときくらいしか自分の中では出番がなくなってしまった。

これ以下のランキングのもその気になったら書こうかな。

ログイン ユーザー登録
ようこそ ゲスト さん