プログラマの雑談部屋 ★197
■ このスレッドは過去ログ倉庫に格納されています
ワイヤレスはいくつか試したが耳にフィットしない、重い、壊れやすいんで有線に戻した 有線快適だよ ワイヤレスでも軽いのあるんよなぁ もう有線の鬱陶しさには戻れんわ あらゆる感覚が鈍い人はワイヤレスでいいのかもしれん 感覚が過敏だからイヤホンの重さや、触感の悪さ、音質などが気になって作業に意識が集中できない Web会議で突然繋がらなくなって焦ったよ 有線は信頼性の証 骨伝導のやつはまあまあよかった 無線のデメリットと釣り合う以上のメリットがある 可能性って蓄積して行くものなのか? 例えば1%の確率のものが5回あったら5%? >>591 サービスがバズって忙し過ぎてから辞めれば良かったのに なんでRDSってストレージ容量でIO速度が変わるんだ? まだまだ容量余ってるのに100Gとか無駄に積まないといけない やりづらくて開発遅れて損するのは会社だし別にいいよ 俺はDDD勉強できるから(やりづらいのが分かったというのも含めて) こんなギリッギリになるまで放置とか 余裕のないスケジュールとか、どの口が品質を語るんだ? DDD案件初期段階ではスイスイ進むのだがシステムを拡張していくとどっからどこまで1つの集約にすべきなのか分からなくなってコードがぐちゃぐちゃになる 巨大な集約を作ってしまうのはdddをちゃんと理解してないパターン >>602 コロナ禍で減ってたけど、少しずつ増えてきてるみたいな話はエージェントが言ってた >>603 DDDはちゃんと理解することができない難しい開発手法なんだと思う 集約の定義はみんな悩んでてハッキリとした正解がない やばいなぁ、あの連中 あとで調べて色々決めるために曖昧に書き替えたのかと思ってたら なんにも調べずに何も決めずに感覚で作り始めたのか? >>604 なるほど それなら勢いで会社辞めても大丈夫そうだな そういえば最近Ipが枯渇してるとか言う話を全く聞かなくなった気がするんですがなんでですか? キエエエエエエエエエエエエエエエエエエエエエエエエエエエエエエエエエ >>605 実践の方の本には明確なヒントがかかれてるけどな そもそも複雑性と戦うための設計やし トレードオフも発生する以上もちろん設計に明確な答えはないとも言えるが シンプルなものにあえてdddを使うとかしなけりゃddd自体が設計を難しくする事態も避けられるし ddd自体が難しいとは違うと思う DDDとかわかりやすいサンプルコードを公開すればいいのに 誰もしないよね >>610 貯金はいくらなの? 老後はどうするつもり? const order = orderRepos.get(orderId); order.addDetail(foo, bar, baz); orderRepos.save(order); DB.insertOrderDetail(orderId, foo, bar, baz); どっちがいい? 上だな 上はクラスになってる 下はただの関数だから 下が明らかに駄目なのは汎用でもないstaticメソッドになってて 明らかにこれから似たような大量のメソッドがそのDBクラスに大量に作られる事よ ヘルパーとして下を用意して中には上が入ってるのは別に良いと思う DB.OrderDetails.insert(orderId, foo, bar, baz); I think Simple is the Best! Thanks! DDDってすぐなんちゃらRepositoryって名前つけるよね 基本は上だと思うが 状況によっては下の方が良い場合もあるかな Web開発にWebフレームワーク使わずに Wordpressを選択することがあるのと似た感じで… リポジトリは直接触れるの? サービス経由じゃないの? GraphQLは万能な解決策だと思って期待したのだが調べてみるとどうもそうではないようだ 結局のところ僕たちがほしいものってSQL over Httpsなんだよね 万能薬だと思って導入するもんじゃないな うちのとこはなんならrestに戻した 流行りに乗っかってる自分に酔いたいだけの人が誇張した表現で持ち上げるのが良くない そんな素晴らしいならもっと速く普及してるだろ コピペしようとしたらテーブルデータ編集してしまった やばい 山口恵梨子女流がCM出演 もっと棋士は人気出て良い 能力的にはサッカー選手とか野球選手と同列でもええのにどうしても性的魅力に欠けるのがな >>637 マトモな仕様書降ってきて その通りに作るだけで良ければ その年収でも良いかなと最近は思い始めた 疲れてるのかな >>637 手取り14マンマンからしたら遥かにマシ >>637 おめーの経歴が雑魚過ぎるのか舐められてるか どっちかやろな 年収交渉って今貰ってるのより+10パーセントアップぐらいが相場? >>629 偏見だけどシンプルにKVSで済むようなストアにもRDBMS使ったりしてそう >>635 何言ってんだお前 プログラマーが能力無いって思われるから意味わからないこと言うのやめなよ >>645 零細で初級者がワンオペで自社開発やってるようなところだと充分ありえる お前らのポートフォリオって何? ホームページとか持ってる? >>649 どう言うフレームワークを使って、バージョン管理システムはなにを使って、サーバーはなにを使って、CSSつかって 見たいのが求められる >>618 オーアルマッパーでDB操作やりたくねー >>648 零細の小さいシステムならなおさらRDBがベスト NoSQLってRDBのCRUD特性と柔軟性を捨てて限られたシナリオで超高パフォーマンスを出すためのものだからね 小さいシステムで使うようなものじゃない 現場わからんプロマネが雰囲気で 会議セッティングして迷惑なんやが どこにでもいるんかい >>658 2行目までは共感 3行目の意味が取れなかったが 某5chブラウザ 使わせてもらっておいてアレだがあんま技術に長けた人が作ってないなこれ たぶんメモリリーク起こしてるし 時間できたら作ろうかな あなたの薄毛はどこから? 私は元から! 彡⌒ミ (´・ω・`) n__ η > ⌒\/ 、_∃ (∃)/ ∧ \_/ \_/ \ 丶 _人人人人_ >テレッテレーレー<  ̄Y^Y^Y^ ̄ >>661 まじかーサンクス しばらく見てないうちにそんなことになってたとは >>581 落とし物どんだけ届けられてると思ってんだ gitのコンフリクト解消極めてるやつって見た瞬間一瞬で直せちゃうもんなの? コンフリクトするといつも正しい治し方が分からずこれでいいのかなと不安になりながら直してプルリクしてる SVNならテキトーでいいのにgitはプレッシャーが重い 大きなシステムで全体のコードの把握は到底無理 一部改修したがエラーで動かない 詳細設計もドキュメントもない 聞ける人もいない お前らならこういう時どうする? そもそも全体のコードを把握しなきゃならんシステムの時点で糞やん? 適切にモジュール分割されてて、自分が使うモジュールのインタフェースを見ればいいだけになってるはずやろ? なってないならそんな糞コードの面倒を見る義理はない! 基本設計書だっつってるのにステップレベルで自然言語プログラミングコードみたいなの書いてきちゃうし、 実装見たらその基本設計書の流れと全然違うコード書いてあるし。 中国人というか低レベルの奴はやってる事メチャクチャだな。 でも出来るプログラマってどんな状況でも障害対応能力も相当高いよね >>672 いるいるw その設計書も書かれてることはむちゃくちゃやねんなw 設計書が間違ってるか確信持てないから上にも言いずらい、その結果、少しのクソが積み重なり結果巨大なクソになりました この世で何が一番クソかと言われれば デバッグできる環境がないシステムでしょ 開発ツール上でデバッグでコード辿れさえできれば まあどんなゴミコードでも大抵なんとかならん? デバッグ環境かある程度まともなログがあれば大抵なんとかなる どっちもなければ最低限のログだけでも出すようにしないといけない >>679 Lambdaでステップ実行したいんだができない クラウドって開発しにくいよな ログしっかり入れるとコードがなんか汚くなるんで嫌なんだが皆の衆は気にならんのか??? doHoge(await getFuga()) ↓ let fuga = null try { fuga = await getFuga() console.debug(fuga.id) } catch(e) { if (e instanceof Xxx) console.error("このエラーの原因はたぶんアレだ。設定を確認してね") if (e instanceof Yyy) console.error("プギャー") throw e } doHoge(fuga) ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる