あお工場勤務プログラマー

アプリに不具合があるなら対応する必要はありますが、 ・トークルーム中に確認もしない ・その後も説明書も読まずに質問 ・次のステップの話 とあり、完了と思ってたら、返金対応しないなら大金を払ったのに詐欺で訴訟ときました。 3.5万で要件と違う、返信全然来ない、夜中対応させられてたのに🙄

ココナラで画像処理の依頼を受け、納品しトークルーム期限切れで完了となり、 数日対応してましたが、一部うまく検出できないとのことで、設定値を変えてトライを伝えましたが結果に対する返信はなく、次のステップの話になりました。 その後インフルエンザにかかり返せていない間に返金しろとの連絡が

社内にシェアさせていただきました。まじでいい！！

ココナラで納品した後に音信普通になり、期限が来て取引完了となりました。その後も質問が何度も来て対応していたのですが、完了していないとのクレームが運営経由で来ました。 1週間以上放置して返信したり、言ってることと画像が違ったりでやり取りのコストがかかり過ぎる人はさっさと損切りだな汗

うちの工場でも二足歩行ロボットやってるけど、工場で活用するやらこっちの方が良い気がしました！

負荷テストってこういうツールでやれば良いのか！ 実装以外の知識がないため、この辺がおろそかになってました。。 業務中はこういうの勉強してる余裕がないので家でAI先生に教えてもらいながら勉強📚

引き継ぎされずに丸投げされた際に、要件定義、設計書もなかったため、最低限なぜその仕様にしたのかはまとめてと言ったら、コード読めば分かりますよねって返された。 既に数部署に導入されてたけど、メイン機能すらちゃんと動かずバグばかりでコード読んでも何も分からなかった（現在進行形）

AIに書かせる言語、C#はマジで有力だと思う。Blazor, Entity Framework Coreあたりを採用すると、フロントエンドのJavascriptもDBと繋ぐSQLも全部いらなくなってマジでC#一本になり、「ビルドが通る」という状態の信頼性がめちゃくちゃ上がるので強い。テストもしやすい。

製造業の工場→社内ソフト開発に転向。 聞く人もおらず、独学で小規模なものを1人で開発。 ベテランの経験に基づく指導が欲しいと思い、少し転職活動もしたけど、年収が結構下がる まずは現状は維持して、クラウドソーシングでメンターを探して指導してもらうのがコスパ良いかな💡 #プログラミング

@satoru_takeuchi 自分も後者です！ 工場で作業してて面倒だなと思ってたけど知識なくて自動化できなかったものが、ソフトやり出してできるようになって楽しいといった感じです。 (難しいことはできませんが)

「プログラミング、コーディングそのものが楽しい」人と「手段は問わず欲しいものを作りたい」人のどちらかといえば、わたしは良かれ悪しかれ確実に後者である。そして前者になりたかったけど、そうではないことを数十年で思い知らされてきた

まだIISしかやったことない😅 メーカーさんが作ってくれたWCFをIISで動かしてたので、 それを真似てWebAPIやBlazorをIISで動かしてる程度ですが

paizaの転職エージェントから最近メール来るので面談してみました。 製造業で工場作業10年→工場で使うためのソフト5年（ずっと独学で個人開発）って話したら、企業打診20件中15件が書類OKで面接希望とのこと。 ソフトのレベルとしては低いので書類もほぼ通らないかなと思っていたので逆に驚きました😅

部内向けWebアプリの認証方法で ・Entra ID（申請が毎回ちょい面倒） ・自作ログイン（運用・管理が重い） で考えていましたが、 調べてたらAD認証（IISのWindows認証）なら手間少なそうなので、明日はAD環境とブラウザの資格情報自動送信まわりを調査してみよう！

「スタッフエンジニアとしてどうやって見積もりしているか？」(How I estimate work as a staff software engineer)という記事。 ・ソフトウェア開発の見積もりが正確にできるという考えは、業界の「丁寧な嘘」 ・経験豊富なエンジニアほど、プロジェクトの正確な見積もりは不可能だと知っている ・Tシャツサイズによる見積もりは、時間に変換されることを避けるためのエンジニアの抵抗に過ぎない ・「見積もりを2倍にして20パーセント足す」といった計算式は、根拠のない気休め ・企業が非合理な見積もりを続けるのは、それが組織内で何らかの役割を果たしているから ・見積もりが可能なのは、作業が極めて小さく、内容が完全に理解されている場合に限られる ・現実のソフトウェア開発の多くは、未知の領域を調べる「研究」のようなもの ・コードを実際に調査するまで、何が必要になるかを事前に知ることはできない ・事前にすべてを設計する手法は、現代の複雑なシステムでは機能しない ・ソフトウェア開発の時間の90パーセントは、事前に予測できない未知の作業に費やされる ・見積もりは、エンジニアが効率的に開発を行うために作られるものではない ・実際には、見積もりはエンジニアではなく、上位の役職者の意向によって決定される ・エンジニアが長い見積もりを出せば短縮の圧力を受け、短すぎればバッファを積まれる ・見積もりは、マネージャーや経営層がプロジェクトの予算や継続を判断するための政治的道具である ・「作業内容から期間が決まる」のではなく、「期間から作業内容が決まる」のが実態 ・期間の長短によって、エンジニアは採用する技術的なアプローチを無意識に調整している ・1週間しか時間がなければ、不完全でも動く簡略化された手法をエンジニアは選択する ・見積もりを始める前に、そのプロジェクトの背景や政治的な重要性を把握すると良い ・「どれくらいかかるか」ではなく「この期間なら何ができるか」を考えるのがプロの仕事 ・既知の作業量よりも、コードベースの中にある「未知の不確実な領域」を警戒すべき ・具体的な完了日を断定せず、常にリスク評価とセットで回答を行う ・マネージャーに対しては、単一の数字ではなく、複数のプランとトレードオフを提示する ・不確実性を理由に見積もりを拒否することは、非技術者に判断を丸投げする行為 ・マネージャーと協力して妥協点を見つけることは、エンジニアの背信行為ではない ・見積もりのやり取りを通じて、エンジニアは組織内での信頼を築ける ・普段から現実的な調整に応じているからこそ、本当に不可能な時に言葉の重みが増す ・プレッシャーのない環境でのみ通用する見積もり手法は、実戦では役に立たない ・既存の巨大なコードベース上での開発は、新規開発よりも見積もりが圧倒的に困難 ・良い見積もりとは、ビジネス上の意思決定を支援するための実利的な情報提供ではないか ・見積もりは科学的な計算ではなく、組織内での期待値を管理するためのコミュニケーションの1つ seangoedecke.com/how-i-estimate…

Blazor Serverで作成した検索アプリを運用していますが、SignalR(WebSocket)だと1日に数回リロードエラーが、、 リトライ/タイムアウト調整で改善したところ、頻度は減少 Long Pollingに切り替えたら今のところエラーなし。 速度も問題ないし、Long Pollingで運用かな💡

@shisyamo_mossan 勉強中というのは伝えてあったのですが、IIS＝古いというイメージで過剰反応されたような気がします😅 普段はLinix + dockerの環境でやっているようなので。 適切な受け答えができるレベルのWeb系の知識をつけたいと思いました😂

Webチームの人に WebでIIS使ってるのはレガシーのまま新しいことを覚えたくない人の怠惰だと言われた 自分はblazorを勉強しようと簡単なアプリ作ってIISが相性良いかなぐらいで使っています。 Webの知識が無さすぎて何に対して文句言われてるのかも良く分からず、何言ってるか分からないと回答して終了

@shisyamo_mossan そうかもしれません汗 確か、渡してきた職場の他のアプリも全部脳死で全乗せだったので。 共通化の罠は自分もやってしまっています😇

@shisyamo_mossan 全く読み解けないですね😅 仕様書も開発時のメモなども何もなく、コード読んでも読み解けず 複数箇所の事業部に入れた後のものだったので、諦めてそういうものと思うようにしました(　˙-˙　)