プログラマの雑談部屋 ★26
■ このスレッドは過去ログ倉庫に格納されています
>>294
どんなに呼び方を変えたところでお前のオナニーに付き合いたい奇特な奴なんぞいるわけないやろw >>295
現行の手順がロクでもないものだったとしても難しいよ
毎日ブツブツ文句言ってるから変更には賛成かと思いきや
いざ、変更するとなると反対意見ばかりほざく
じゃあ、自分らが納得する改善案を出して改善してみろと
ここまで権限を与えてやっても結局変えようとしない
俺の周りの奴がアホなんじゃなくて割とどこでもよく見る光景だと思う 【非婚】結婚障害の無能残業するな【離婚】
☆料金増やすか生産減らして対策しろ☆
偽装請負多重派遣業界搾取SE結婚相手の犠牲対策
巨額搾取させて結婚妨害するな!
無能残業して共働き妨害するな!
・IT社長に贅沢資金を搾取させるな
・客先経営資金削減の犠牲になるな
・平均年齢40歳未満の会社は辞めろ
・6時間/日以上PC使用の会社は辞めろ
・1,000万円/年以下報酬の会社は辞めろ
・100万円/月以下報酬の契約は断れ
・100万円/月以下報酬のプログラムは作るな
・実態派遣プログラムを作るな
・プログラムの料金以上に作るな
・プログラムの利益を搾取させるな
・プログラムを客先に渡すな
・不利益な依頼は断れ
・知的財産を渡するな
・客先指示に従うな
・生産利益を上げろ
・生産効率を上げろ
・契約外作業期日は断れ
・時間外労働違反は止めろ
・多重契約は断れ
・残業見積りは断れ
・残業しないで学習しろ
・残業しないで副業しろ
・残業しないで家事やれ
・偽装請負多重派遣は通報しろ
・損害賠償訴訟を怠るな
SEの結婚対策
https://amoo-re.com/articles/IK9K8 >>286
ブラックリストに入って仕事なくなるんだろ? >>294
グレース・ホッパー「よい考えならさっさとやりなさい。前もって許しを得るより、後で謝った方がずっと手っ取り早いんだから」 >>296
それだけに集中できる専門のチームや部署を立ち上げて年単位で時間をかけて取り組むような課題だよ
大した権限も地位もない上司に「俺が許すさあ改善しろ(本業の余力だけで予算は無しでな)」って言われたって「じゃあやります」とはならない
こういう無理解な上司や経営者を排除することが改革へのスタートラインなんだろうな 業務手順を変更するのにはリスクが伴う。
リスクを大幅に上回るメリットが提示されないと誰も動かない。
根本的に変えたいなら、
導入計画立てて、対費用効果見積もって、導入施策実践して証明するのが無難。
と言うか、客先にアプローチする内容を社内でも実践するだけ。
社内だからといって手を抜いたら相手にされないのはよくある事。 基本、日本のITなんてアホしかいないからどんなにメリットがあっても
「新しいこと覚えるの大変だから今までのままやってた方が楽なの…」
って言う奴ばっかりで、改善なんか無理。
改善なんかしようとしないで、もっとマトモな事やってる企業に転社した方が早い。
サルに人間になれって言っても無駄。なれないからサルやってるんだし。 日本では集団の中でも比較的低い生産性を基準にノルマが設定される
だから相対的に仕事が早い人にとってはすごい楽なんだよね
俺の場合だと遅くても15時にはノルマが終わってその後は暇つぶしして定時帰宅できてる
巡回してるサイトの更新がないと暇すぎて逆にストレスになるぐらい暇
同じような人は社内に結構いるんだけどみんな余力があることははっきりと声には出さない
自分らの使ってる方法論を展開すれば業務を改善できるんだろうけど
>>301のような面倒くさい手続きがあるから誰もやりたがらない
それに周りが効率化されたら相対的な優位性がなくなって定時で帰れなくなるかも知れない 上司が効率化を目的にしていないのに部下が効率化を目指すのは無駄
効率化の掛け声をかける上司は居るがただの掛け声
上層部ほど存在自体が効率化を阻害している >>291
仕事で?
Githubのアカ教えてとは言われるけど 小学校でプログラミングが必須科目になるから、
10年後には新入社員誰でもプログラミングができる時代になる。
そうなると年寄りになった俺たちは首になる。
今のうちにプログラマーを辞めて第二の人生に切り替えておくことをオススメする。 >>307
小学生から算数理科を学んでもそれが出来ない奴の方が圧倒的に多い この業界に来る奴はプログラミングできるできないは関係なく他業界でお祈りされまくった雑魚なんだよね
そんな雑魚どもに恐れを抱く必要は全くない
それよりも客先企業の非プログラマ正社員が本職プログラマより優秀になってしまうことのほうが深刻だ
他業界に就職できる連中は脳そのものが優秀だからプログラミングをやらせても本職より上手くなる
連中が外注するより自分でコードを書いたほうがはるかに安くて手っ取り早いと気が付いた時に俺らは職を失う ばかじゃん?
小学校のプログラミング必須なんて、全く意味ないよ。
だって、まともに教えられる奴がいないんだもん。
この国はもう、どうやったって、無理。 そうか必修化したら教員不足になるからプログラミングの講師になればいいのか
あーでも教員免許持ってねえ詰んだ プログラミングが出来て教員免許をもっていて、これから教員になろうとする人
ほとんどいないと思うから特別な処置がされると思う
補助教員として雇用されるんじゃないかな
だから公務員にはなれないし給料も安い 必修つっても小学校だろ
JK居ないんじゃ教師になってもな… >>314
前の授業が体育だったから着替えるの面倒臭いし・・・
ってブルマで授業を受ける子がいるかもしれない 今でも未経験でできる仕事と思われてるのに
プログラミング必須になったら
小学生でもできる仕事になってさらに賃金が下がるな プログラミングの授業をエロBDの交換会にしてやんよ 図工の時間をふやすんだ
絵が描けるやつはかしこい
日本はそういう人材がエロに吸い取られてしまってなんも残らんが KindleってAPIないの?
自分の持ってる書籍を管理するツールを作りたいんだがAPIが見つからない プログラムやってるとこの国がますます嫌になってくる >>322
ないですよ。
Kindleは各国の著作権やら法規制やら新しいデバイスに合わせて
常に変化していますからAPIなんて提供できないですよ! >>323
どうしていやなの?
おれはカナダとタイで仕事したけど、外国人って平気でウソつくよ。
つか、ウソつくのも仕事のうちと思ってるから始末におえない。
正直なほうがいいなんてのは日本だけ。 >>324
そうなんだ
ブック一覧とかコレクション操作とかその程度で十分なんだけど……
ヘッドレスブラウザで頑張るしかないのかな むしろデータ引っこ抜かれるからAPIなんか触らせてやらないんだと思うぞ。 >>320
これ職場に貼り付けておきたいわ
昼食も飲みも付き合わないやつが多すぎる プログラムの授業をエロ画像クローラーの開発にすれば捗る男子高校生なら 今どきクローラーなんぞ設定ファイル書く程度の難易度やろw インターネットがこれだけ発展できたのは
エロのおかげ お?BBAの上司に叱られてちんこバッキバキスレか? 色々な意見があるが
たった一つだけ言える真実がある
プログラマは家庭を諦めろ 詳細設計書とか言うソースの日本語訳ゴミドキュメントだけど
あった方が工数水増し出来て儲かるとかそういう実務と全く関係ない理由だったりするんだろうな
その設計書書く時間でコーディングしてたら開発要員集める必要なんて全くないよねっていう 詳細設計書ってどんなの作ってんの?
せいぜいデータの入力元と出力先、タイミングが書かれてる程度で
「ソースの日本語訳」ってどういう状態なのか想像つかん
かなり大雑把なフローチャートぐらいはついてくる時があるけどな >>343
こんなんだよ
こんなんが最初から用意されてることもあればコーディングした後ソースを元にこんな設計書を書くこともある
1.顧客データの件数分以下の処理を繰り返す
<顧客区分がA区分の場合>
@顧客情報登録変数の名前フィールドに顧客の名前を格納する
A顧客情報登録変数に住所フィールドに顧客の住所を格納する
<顧客区分がB区分の場合>
@DB検索処理を呼び出す 引数:顧客ID
2.DB更新
@DB更新処理を呼び出す
<DBExceptionが発生した場合>
@ログ出力する
A再度例外を投げる
3.ログ出力
4.TRUEを返却する ついでに関数名しか書かれてない見ても全く意味の分からないフローチャートがついてたりもする
あまりにも意味がないから無視してると存在を忘れて途中からソースとの不整合が起きたりして
もういつどこから忘れてるのかもわからないけど、どうせ誰も見ねえだろと放置
当然誰にも指摘されない
底辺の派遣常駐だがこんな世界
常駐先はNとかFとか 簡単か難しいかわかるから、
コーディングは若手とか他に割り振ったりできるじゃん。
この例えレベルのテストで工数取られるの正直めんどうだし、作文でテスト免除なら引き取ってもらえるだけ嬉しい。 なるほどね、そういう利点があるのか
穴掘って埋めてるような虚無感があったけど完全な無意味ってわけじゃないなら少しは気が楽になるな 関数の設計ならコメントかかせりゃいい
その関数を使う人向けのな
実装向けには多少の注意点だけになる
なんでも箇条書きにする奴は大抵ダメな奴 >>346
foreach (i in 顧客データ) {
if (顧客区分 == "A区分") {
顧客情報登録.名前 = 顧客の名前
顧客情報登録 = this.住所 = 顧客の住所
}
if (顧客区分 == "B区分") {
DB検索処理(顧客ID)
}
}
DB更新処理()
catch(DBException ex) {
ログ出力();
throw ex;
}
ログ出力();
return TRUE;
ループ変数使ってない
いきなり未定義の変数が登場
異なる型の変数に代入
DB検索処理の結果を捨ててる
DB更新処理のパラメータは?
tryばいけどいいの?
なにをログ出力したいの?
言語そのものが曖昧な日本語で書くからあやふや
IDEのサポートがないから矛盾だらけ
やけに手続き的だけどこれはCOBOLの設計書?
コーディングと同程度かそれ以上のタイピング量(工数倍増)
めちゃくちゃだ
酷すぎる 例えばの話に神経質になる・・・
エンジニアの悪い癖ですねぇ でもコードから逆に起こしてる仕様書ならこんなもんか
どうせいらないからやっつけるに限る >>352
これは例えばだけど実際の詳細すぎる設計書もこんなもんだよ
長いこと働いてるがこの手の形式で正確な詳細設計書なんて見たことない 設計書として書くべきことがおかしいから>>351みたいなのがでてくる >>347
仕様書がメチャクチャで非正規がどうすんだこれと言うと
こんな事も出来ないの
で、即チェンジ
で、メチャクチャなのをメチャクチャな方向で直せるアイディアマンが評価される
javaで6重ループ理解して8重ループの処理作る脳が柔軟な人みたいな 最底辺で非正規低賃金でソース書く人が
超能力で仕様を見抜かないといけない日本のIT業界。
くさってるよな システムエラーが出ても報告してこない製造者がいるんだけどどうしたらいい?
問題があれば報告したり相談するのも仕事のうちだと思うんだけど、本人は設計書通りだから問題だと思わないらしい
気が触れてるとしか思えないんだけど何か対策ってないかな? システムエラー吐いてもOKなところいくらでもあるしな >>360
そいつアスペか反日のキチガイだろうから、
別の人に交代させたら? 今の現場凄い嫌だわ
設計がこのくらいコーダーで考えろやみたいな感じで仕事を丸投げする上に、出来上がってきた物に文句ばっかり言ってる
完全に上下関係が出来てて、コーダーを労働力としか見てない
一緒にやるって意識がまったくなくて奴隷かよって思う
気分悪いわ コーダーがアルゴリズム考えるのかw
そりゃあ効率悪いなw >>360
仕様通りに動いてれば問題ないという認識こそグローバルスタンダード >>365
for(false){
そのくらい自分で考えろ
なんでこんな仕様にしたんだ
}
は業界のデファクトスタンダード >>366
コーダは要件定義からに決まってるだろバカか そんなん自分で考えろ
なんでこんな仕様にしたんだ
使えない派遣だチェンジ
これで成り立ってるのがIT土方業界 >>365
一切忖度するな
「こうですかね?(全く違う)」
ってメール出しまくれ >>371
堂々と聞け
ccにできるだけ偉い人付けて
メール出せ >>365
コーダーなんて奴隷だし、使い物にならなかったら切り捨てて別の入れるだけ。
奴隷かよって思う、じゃなくて奴隷だよ。何言ってんの。 >>373
コーダーのクセに何わけわからん事言ってんの?
てかなんでそんな仕様にするんだよw >>360
社内の人間なら教育
社外の人間なら作業マニュアル作って
それでも役立たずなら交換 >>375
だから聞けよ
メールで
その際にccに偉い奴付けてくだんねーことほざけないようにしろ >>378
それそれ
そーゆーくだんねー返しは許さない
回答もらえるまで自社で作業あるからねw(ないけど) 詳細設計書は作らなくてもいいよね(社長部長先輩同期)
って意見に必要ですって答えたら
君は詳細設計書ないとプログラム作れないの?
って言われたことあるんだけど
プロジェクトの要員に追加されたり自分が作ってないプログラムの修正やらされる事になった場合って普通はどうしたらいいの?
webサイトとかwindowsプログラムをvisualstudio使って.netで開発がメインの会社です 作業をするうえで分からないことをリーダーか分かる人に質問すればいいんじゃない 基本設計の副次資料として詳細設計があるんだから、省略しても問題ないはず。
ただ、QAとして詳細設計が欲しいとか非エンジニア用の資料として必須なら日本語で作らなきゃいけない。
・基本設計にI/Oがない
・可読性の悪いソース
・コメント、docなし
・ステップ数を圧縮する要件がある
などエンジニアに不利な話があるときだけエンジニア向けの詳細設計があればいいんじゃね。
普段から子供でもわかるような簡単で整理されたスコープの読みやすいコーディングが出来るかが技量だと思うね。 C#でいちいちコード書くやつって、ネイティブコードを直に書けない池沼だよね ここの人たちは賢すぎたりワンラインナーで書くから詳細が必要なんだよ。 大丈夫って言ったから確認しませんでした
みたいな話でしょ?
問題が起きた時に収集がつかなくなるリスクをどう捉えるか
あと作りっぱなしの売り切りなら問題ないけど、仕様変更とかあったら分析コストが実費になるリスクもあるな 正確でエレガントな詳細設計: 必要
日本で一般的な私大文系の書いた詳細設計: 足を引っ張るだけのゴミ そうやって学歴とかでマウント取り始める奴がいるから話が進まないんだよなぁ プログラマはドロップアウトしたゴミが30歳まで食いつなぐための仕事
30超えたら大体精神病んで生活保護
もしくは自殺 いまの30代は高卒も大卒も就職氷河期だったからろくな経歴積めてない。
経歴がまともな30代は貴重だから適当にちやほやして使い倒したほうがいい。 仕様がなくても忖度してコードを書くことを要求されるのが
日本のプログラマ ■ このスレッドは過去ログ倉庫に格納されています