プログラマの雑談部屋 ★8 [無断転載禁止]©2ch.net

■ このスレッドは過去ログ倉庫に格納されています
1仕様書無しさん
垢版 |
2017/06/23(金) 12:04:27.51
プログラマは
こちらで雑談してください。

ユーザ、ＳＥが馬鹿過ぎる、
上司が陰険だからもう辞めたい、
もう少しまともな仕事に転職したい、
彼女が欲しい、
などなど愚痴、妬み、妄想などなんでもどうぞ。

※前スレ
プログラマの雑談部屋 ★7
http://medaka.2ch.net/test/read.cgi/prog/1496071945/
2017/06/23(金) 13:42:33.31
インターン先で
「君はC++ではなくCで記述するのね」って言われたんで
「違いは何ですか？」て聞いたら「君はクラスを使わないね」って言われた・・・
開発環境C++でクラス使わないってどんな行為なの？
4仕様書無しさん
垢版 |
2017/06/23(金) 13:58:36.26
>>3
cがクラスの概念が弱いんじゃね
その会話の流れから
2017/06/23(金) 14:10:26.48
開発環境っていうか使用言語だったわ。使用言語がC++なのに
クラスを一切使わないね、って言われた
ヤバいやつなんだろうか？
6仕様書無しさん
垢版 |
2017/06/23(金) 14:15:15.45
Cで書いてあると他の高級言語から呼び出すのに便利

特に何の理由もないけど分からないから使わないってだけならヤバイ
2017/06/23(金) 14:25:39.30
>>6
なるほどなぁ
クラス跨ぐと呼び出すのメンドイし後々読み返すのダルイから
なるべく一つのクラス内で完結するように記述するようにしてたんだけど
そういった所でいうとまずい書き方なのかなぁ・・・
2017/06/23(金) 14:43:48.30
はー高級言語やりたいわ
今クッソマイナーな言語やってるからググっても何も出てこないから辛い
9仕様書無しさん
垢版 |
2017/06/23(金) 14:46:48.36
>>2
柴田というのが、柴田文彦を示しているのなら奴の本はダメ。
あいつ馬鹿のくせにええかっこしだからな。

どういうアルゴリズムを学びたいのかわからんけど、
「C言語による最新プログラム事典」1992年
というのがアマゾンで１円で古本が売られているから、
それを勉強しなさい。
10仕様書無しさん
垢版 |
2017/06/23(金) 14:51:31.31
>>3
＞　「君はC++ではなくCで記述するのね」って言われたんで

小さなコードならCでも全然OKだけど
複数の機能があるとC++のほうが楽かもしれない。

おれは合計200ステップ以下で関数が６つ以下ぐらいならCで作るけど、
それ以上ならC++かな？
11仕様書無しさん
垢版 |
2017/06/23(金) 14:53:42.77
>>7
Blobアンチパターンまんまの
メンテナンス不可能なプログラムでも作ろうとしてるのか

それはさておきC++の仮想関数だとか
テンプレートだとか、例外だとか、RTTIだとか
そういった機能は出力されるプログラムのサイズやオーバーヘッドを増やす可能性がある
だからCを使うという人もいる
スペック的に余裕のあるPCならともかく、組み込みだとそう言うのは大事かもしれない

C++でもこれらの機能を使わなかったり、切ってしまったりすれば同じな気がするが

プラグイン書くとかで共通ABIが必要な時もC
C++で書いて
後からC APIでラップする、という事も可能かもしれんが
そんな事するぐらいなら最初からCで書くと言う者は居てもおかしくない
12仕様書無しさん
垢版 |
2017/06/23(金) 15:09:56.85
前スレ>>946
＞　情報学科の大学生なんだけど
＞　今年からプログラミング学んどって思ったんだけどこれって今まで学んできた物理とか数学の知識って使うのか？
＞　受験勉強とか大学の勉強で数物頑張ったのにプログラミングなんてパソコンカタカタするだけで文系どころか下手すりゃ中高生でもできるだろって考えたら何やってんだろって思う。
＞　プログラマーってことは情報学科出た人多いと思うから是非とも教えて欲しい。

書いてる内容からするとFランの馬鹿のようだな。
その程度の数学や物理は社会では使い物にならないから、
安心して奴隷プログラマになってくれ。
2017/06/23(金) 15:10:55.05
>>11
やばいなぁ、8割方何言ってんのかわっかんない・・・(´・ω・`)
一つのクラスで完結させようとするとクッソデカくなって、むしろ可読性とか落ちるって事と、
C++の機能を使うとメモリ？を想定より喰う場合があるから軽くするためにCを使うっていうはなんとなくわかった？と思う
ABいとかAPIはまともに触ったこと無いからチンプンカンプン・・・
2017/06/23(金) 15:37:48.99
設計者が実装終わる期間まで設計しててよく考えたらなんかおかしい
なんで今テーブルのカラム足りないとか言うのか…
15仕様書無しさん
垢版 |
2017/06/23(金) 15:58:22.09
おまえらって何歳？
20代とかでもいいよ
16仕様書無しさん
垢版 |
2017/06/23(金) 16:13:25.90
>>13
Blobアンチパターンはこれを見ろ
https://thinkit.co.jp/article/929/1?page=0%2C1

あまりに何でも出来すぎるって事で
オブジェクト指向言語だと「ゴッドオブジェクト」と呼ばれる事もある

あまりに沢山の状態用変数に依存してたら
テストすべきパターンが多過ぎて
テスト漏れが生じる恐れが出てきて、自動テストは困難になるし
ドキュメントも書けなくなるな

コードを新しいプロジェクトで再利用する時はどうするんだろうか？
まさかコードを切り貼りするとか言わねえよな？

その切り貼りしたコードに変更が必要になったら両方に変更が必要に・・・とかなる可能性がある
そんな事になるぐらいなら最初から小さな部品に分けて
再利用可能にしておけ

あるいはデータ処理のコードだけ利用したいのに
GUI初期化や設定ファイルの読み込みまで行われてヤキモキするかも
17仕様書無しさん
垢版 |
2017/06/23(金) 16:24:52.96
>>7
そりゃクラスを使ってないな
2017/06/23(金) 17:31:47.97
>>15
アラサーだけど未経験中途だからあんまりできない感じ
2017/06/23(金) 17:33:11.43
>>9
すみません
この本です

新・明解C言語によるアルゴリズムとデータ構造
2017/06/23(金) 19:37:34.87
>>16
Oh.....
使い回したりするならやはりクラスで部品に分けた方が良いんですな・・・
しかし他で使うことが無いものまで部品に分けた方が良いんだろうか？
21仕様書無しさん
垢版 |
2017/06/23(金) 20:05:37.34
>>20
馬鹿でなかったら気にする必要はない
あれもダメこれもダメこーしろあーしろ
ってのは馬鹿でも最低限の品質を維持できるように考えられた苦肉の策にすぎん
22仕様書無しさん
垢版 |
2017/06/23(金) 20:24:22.93
絶対に他人にコードを渡したりしないってならそれでも良いんじゃね

渡される事があったら渡された側は
意味不明で阿鼻叫喚だが
こんなの弄るぐらいなら書き直した方がマシっても思われるかもしれない
23仕様書無しさん
垢版 |
2017/06/23(金) 21:34:52.97
３万のプログラムってどんなの？
24仕様書無しさん
垢版 |
2017/06/23(金) 23:40:31.83
3万ステップということ？
言語は？
25仕様書無しさん
垢版 |
2017/06/24(土) 00:53:13.44
php
26仕様書無しさん
垢版 |
2017/06/24(土) 00:57:09.77
言語って？
27仕様書無しさん
垢版 |
2017/06/24(土) 02:08:46.88
デザパタをガンガンに使ったら、先輩に、わかりづらいおかしなプログラムだな、
と言われた。結局、派遣さんに一から作らせていた。
おれには未来がなさそう。
2017/06/24(土) 03:42:02.52
デザパタは複雑なものに名前をつけることによって一言でわからせる効果があるが
それがいくつも織り込まれてるならわかりやすい設計書が必要だな
あとはもっと簡単に書けるのに必要以上にデザパタ等を使うのも悪手だ
2017/06/24(土) 03:45:44.51
>>27
よく言われるけど
適用根拠がないんだよ
なぜ？そのパターンで良いのか?
これを説明する資料を作らんくせにほい作りましただけ言うから
まったくわけわからん
30仕様書無しさん
垢版 |
2017/06/24(土) 09:30:29.41
それを言っちゃうと逆の立場でも同じだよ

デザパタを使って自然に綺麗に書ける部分で
あえてデザパタを使わないならその理由を説明しなきゃならない
ルールチェインで書けるのになんでif elseの羅列っていう複雑な構造を選んだの？
ストラテジーで書けるのになんでenum switchっていう複雑な構造を選んだの？
それをいちいち資料化して説明してと言われたら辟易するだろ
なんでそんな当たり前のことを聞くんだ？ってね

デザパタは何も特別なことをしているわけではない
当たり前にたどり着く書き方に類似性を見つけて名前をつけて知識を共有しただけ
例えばif elseの羅列はみんな書いたことがあるからある意味パターンと言えるね
それにif/elseチェインパターンって名前をつけて共有しようということになったとしよう
なんでif/elseチェインパターンを使ったのか資料化してよと無駄な労力を強いるメンバーがいたらモチベーションが低下するよね
2017/06/24(土) 09:47:49.61
>>30
それを設計書に書けばいいじゃん
2017/06/24(土) 09:49:21.07
内容が正当であるかどうかだよ
適用するデザパタと今回の仕組みがどのくらい似てるか説明してくれればいい
2017/06/24(土) 09:50:22.64
デザパタにクラス図が書いてるんだから
今回のクラス図もそれにそって書けばいい
34仕様書無しさん
垢版 |
2017/06/24(土) 10:18:31.90
実用的なものは仕様がはっきりしてるけど、面白くない。
35仕様書無しさん
垢版 |
2017/06/24(土) 10:23:25.80
俺にはデザパタも非デザパタも特別な違いがあるようには思えん
やりたいことを素直に書いたらこうなるよね
ああこれってどこかで見たなそういやデザパタでこんなんあったな
そんな程度の気楽さで書いてるから
かしこまって「何故人はデザパタを使うのか」なんて哲学者みたいなことを考えたり文書化するのは時間の無駄じゃないかな
2017/06/24(土) 10:25:27.79
>>35
そんなエピソードどうでもいい
お前が書いた設計書が正しいかどうかだよ
ただ、デザパタ参照は通らないだろうね
今回の設計に適用することの正当性を説明する必要がある
2017/06/24(土) 10:26:24.46
設計書を評価する側もデザパタかどうかは関係ない
2017/06/24(土) 10:34:05.75
設計書ってそんな細かく書くの
39仕様書無しさん
垢版 |
2017/06/24(土) 10:34:12.75
>>36
正当だよ
だってOOPで無理なく自然に書いたらそうなるってコードしか書かないもん俺
いちおうレビューで説明もするけど毎回、まあ当然そうなりますよねって合意に落ち着く
その説明であえてデザパタを引用することも無い
何故なら俺はデザパタありきではなく、ただ単に自然なコードを書いただけだからね
君が妄想してるように有名なデザパタを使いたかったので、無理やり当てはめてみました、なんてことは実際ありえないからね
2017/06/24(土) 10:38:00.28
>>38
デザパタの粒度でもいいんじゃん?
簡単でしょあれ
時間もかからんし
2017/06/24(土) 10:38:31.94
>>39
んじゃそのまま設計書に書けばいいよ
42仕様書無しさん
垢版 |
2017/06/24(土) 10:43:58.25
議論するより数字で示す方が経営者は納得する
同程度の規模のプロジェクトを幾つか用意して手続き指向とオブジェクト指向に分けて作業させる
中立の品質管理チームが両者のプロジェクトについて様々なメトリクスを測定する
コストや品質が数字で如実に示されるので言い逃れはできない
ちなみにうちの会社でやった時はオブジェクト指向の圧勝だったよ
2017/06/24(土) 10:50:22.35
>>42
おかしいな
処理数は同数になるはずなのになｗ
2017/06/24(土) 10:50:59.29
>>40
デザパタ存在しか知らんのよね 不勉強で申し訳ない
今の職場の設計書は画面の見た目とIOとDBはあるけど
ロジックとか一切なくて 実装する人がいい感じに作ってねって感じだからどこにデザパタ入れたらいいのかわからない

そしてその状態で新人に毛が生えた程度の実装者に丸投げ
45仕様書無しさん
垢版 |
2017/06/24(土) 11:27:45.38
ビジネスロジックがないならデータモデルからUIとテーブルを生成が簡単だね
デザパタどころかコードも殆ど書かないと思う
2017/06/24(土) 11:53:13.95
クラス図の吹き出しに書いときゃいいじゃん、○○デザパタでやりますって
47仕様書無しさん
垢版 |
2017/06/24(土) 12:31:38.12
「吹いた」ってやつか
2017/06/24(土) 12:35:53.07
リポジトリバターンなんか使おうものなら、
なんで１クラスで済むのを分けるの？
とか言われるでしょ。
49仕様書無しさん
垢版 |
2017/06/24(土) 13:03:20.61
UIからSQLまで全てが詰まった神クラスはもう嫌だ
信仰を押し付けるな
50仕様書無しさん
垢版 |
2017/06/24(土) 13:09:21.44
. 　　　　　　　　　　　 　　⊂⊃
..　　　　　　　　　　　　(ヽ､　　 ノ),
..　 　 　　　　＿ノ⌒ヽ､ミ（　 ） 彡 ,ﾉ⌒ヽ､
　　　　 　　`ｰ,へく,'　 ）彡⌒ミﾞ （ ､,` ヘ　ｰ'
　　 　　　　ノﾉ, ,　ヽ （ (´･ω･`)ﾉノ　　 　＼　また神の話してる
　　　 　　　　　　'ノﾉノﾉ(|　　　|)八ヽ)八）) ）
　　　　　　　　　　　　 　(γ　/
　　　　　　　　　　　　　　 し/
2017/06/24(土) 13:11:26.78
すべてシングルトン
52仕様書無しさん
垢版 |
2017/06/24(土) 13:12:20.07
GUIとDB処理を分けておけば互いに影響を与える事なく改修や再利用が出来る
偉い人にはそれが分からんのですよ
2017/06/24(土) 13:16:25.37
どうせだれか後でリファクタリングするやろ→肥大化
2017/06/24(土) 13:25:08.64
>>52
GUIの項目増えてDBいじらないなんてことありえないけどね
また、その逆も
だって入力した項目どこに保存するのよ
もしくは増やした項目どっから設定するのよ
55仕様書無しさん
垢版 |
2017/06/24(土) 13:31:16.00
ドメイン層以上ならリファクタリングなりリライトなりすりゃいいんだがデータベースがな
ありとあらゆるところから直接DB参照されてるからそう簡単には変更できない
言うなれば全てのインスタンスをシステム間で共有のグローバル変数で管理して
それらの全てのフィールドをパブリックにして寄ってたかって全員でいじくり倒すようなものだ
全部の依存関係や振る舞いを把握してる人はどこにもいないし調査するだけで長いプロジェクトになる
そんなコードが10年20年という年月をかけて各企業の資産として積み重ねられてきた
会社を潰してやり直すぐらいの覚悟がないとどうしようもない
保守的な老舗企業が多い日本はもうダメだ
56仕様書無しさん
垢版 |
2017/06/24(土) 13:54:03.83
全部一箇所に詰め込めば良いって奴は
汚いUIの教務アプリしか作ったことないやつだろ
MVCとか全否定かよ

SOLIDの原則: Part1 - 単一責任の原則(Single Responsibility Principle)
https://code.tutsplus.com/ja/tutorials/solid-part-1-the-single-responsibility-principle--net-36074
57仕様書無しさん
垢版 |
2017/06/24(土) 13:57:27.08
>>54
場合によってはuiもdbも同時に変更する時はそりゃ当然ある
ポイントは変更する『理由』だよ

uiから見ればdbが変わったから変更したのではなくビジネスルールが変わったから変更したってこと
dbから見ればuiが変わったから変更したのではなくビジネスルールが変わったから変更したってこと

そうではなくてuiが変わったからdbを変えるとかdbが変わったからuiを変えるって理由での変更が頻繁に起こるならそれは悪い設計だ
2017/06/24(土) 14:10:03.78
>>57
超絶レアケースじゃん
59仕様書無しさん
垢版 |
2017/06/24(土) 14:22:42.11
ゴッド・オブジェクトって
コピペプログラミングの温床になるよな
設計変更が必要になった時には手遅れだ
60仕様書無しさん
垢版 |
2017/06/24(土) 14:32:36.81
>>53
実際はそうなるよね→肥大化＋スパゲティ
61仕様書無しさん
垢版 |
2017/06/24(土) 14:34:43.89
>>58
そのとおり
uiを変えるからdbも変えるとかdbを変えるからuiを変えるってのは滅多にないレアケースなんだよ
ただしちゃんと設計してればね
2017/06/24(土) 14:39:09.55
>>61
は?どっちかだけなんてありえないだろ?
業務が変わるのにdbそのままなんて絶対にない
2017/06/24(土) 14:43:32.21
想定してる状況がクソ
ui変えたいなんて今の情報じゃたんねーもしくはデブ過ぎて重いから
変えたいのがほとんどだっつの
dbから変えなきゃレスポンスクソなまんまだし、たりない場合は
uiに合わせて情報の格納方法から変更しなきゃならねーに決まってるだろ
仕事舐めてんのか?
つーかサーバーごとお買上げだろその変更

毎度あっしたー♪
2017/06/24(土) 14:45:12.18
UI見直すなら処理もリファクタリングするやろ→frmMain.csに処理全部書いちゃう
65仕様書無しさん
垢版 |
2017/06/24(土) 14:46:30.25
>>62
なんかの仕様変更がった
分析した結果あるエンティティの振る舞いを変えるだけで実現できそうだ
フィールドの変更は必要ない
永続化変更の必要もない
データベースの変更も必要ない
パブリックプロパティも変更ない
uiも変わらない

このようにシッカリしたシステムでは仕様変更でuiもdbも変わらんということはよくあるんだ
できの悪いシステムでは本来必要ない依存関係が沢山あるせいでuiやdbを巻き込んだ変更になりやすい
君はそういうできの悪いシステムばかり扱ってるからそういう常識が出来上がってしまったんだろう
嘆かわしいことだ
66仕様書無しさん
垢版 |
2017/06/24(土) 14:51:15.68
>>63
仕事を舐めてるのはお前だろ
情報が足りないからdbのフィールドを追加する
情報が足りないからuiのフィールドを追加する
のであって
uiのフィールドを追加したいからdbにフィールドを追加するんじゃあないんだよ
バカすぎてわからないか

レスポンスにしてもそうだ
クエリを書き換えるからといってそれがuiに波及することはない
ボトルネックのapiと外部から見た振る舞いを維持したまま高速化するのがレスポンス改善の基本だ

お前のやってる仕事はまさに素人そのまま
めちゃくちゃもいいところだ
67仕様書無しさん
垢版 |
2017/06/24(土) 14:58:27.74
そもそも決まったフロントエンドが無い場合も増えてきてるというのに
フロントエンドとバックエンドが密接に関係してたらビジネス展開できないだろ
金稼ぐ気あるのかね
2017/06/24(土) 15:00:18.79
>>66
甘いんだよバーカ
そんなの動くわけねーだろハーゲ
しかも金とれねーだろ無能
ユーザーは情報量を少なくしてスピードアップしたいっつってんのにdbそのままで動くわけねーだろカス
お前の想定なんてなんも作ったことのないやつの戯言
69仕様書無しさん
垢版 |
2017/06/24(土) 15:03:42.35
AndroidアプリとiOSアプリと
UWPアプリとWindowsデスクトップ版と
Linuxデスクトップ版と
Mac版と
Web版全部作って

Web版以外は無論HTML5使わない作りで
2017/06/24(土) 15:04:29.21
まあ落ち着いて考えてみろよ
htmlのみてくれだけ変更して早くなるかって話よ
webapiの変更必須だろ?
2017/06/24(土) 15:05:22.93
>>69
pc版とandroid版で同じだと思ってんの?
72仕様書無しさん
垢版 |
2017/06/24(土) 15:46:30.94
>>68
あらら相手しちゃダメなタイプだったか
バイバイ
2017/06/24(土) 15:46:50.18
>>72
はい逃げた
74仕様書無しさん
垢版 |
2017/06/24(土) 18:36:37.62
『逃げるが勝ち』

プログラマ名言集第一巻第五章より
75仕様書無しさん
垢版 |
2017/06/24(土) 19:10:45.13
会社のコーディング規約にインスタンス変数の使用はなるべく禁止って書いてあったんだけど(バリバリのオブジェクト志向言語)目が点になって理解できなかった。
76仕様書無しさん
垢版 |
2017/06/24(土) 19:27:45.00
>>62
年齢表示を増やすのに、普通は年齢フィールドを増やしはしない
2017/06/24(土) 19:32:12.08
プログラマって未来にモノを残せない職業だよね
数年、長くても二、三十年で消滅するようなものを作ってる
建築物のような死後にも残り続けるものではない
2017/06/24(土) 19:56:29.50
抽象化できないやつと仕事すんの嫌だなぁ、
もっと具体的にしてくれなきゃ分かりませんって、コピペ増やす気かよ。
2017/06/24(土) 20:10:21.66
建築物も世界遺産レベルにならないと崩壊するだろ
それか修復
プログラミングも変わらない
2017/06/24(土) 20:26:01.46
>>76
どっから入力して、どこに設定するの？
年齢を表示したくない場合は?
またその設定は?

ハイ、考慮不足やりなお〜し

って余裕で突き返されるね
部長までいかんで課長チェックで返ってくるレベル
2017/06/24(土) 20:37:19.46
>>80
バーーーーーカ
2017/06/24(土) 20:38:51.41
>>81
ｳﾜｰｰｰｰｰｰｰｰﾝ(´Д⊂ヽ
2017/06/24(土) 20:48:50.69
>>75
それが理解できない程度ならまだまだだな
2017/06/24(土) 20:59:27.16
ホント、プログラマってバカだな
「違うだろ！違うだろ！違うだろ！」
お互いにブリブリ言い合って譲らないのなｗ
こんなもんそういうケースもあるし、そうでないケースもあるってだけじゃん
原理原則の話じゃないのにどっちが正しいなんてない
議論にさえなってないのを気づこうな
85仕様書無しさん
垢版 |
2017/06/24(土) 20:59:31.23
staticおじさん登場(hey everybody!!)
2017/06/24(土) 21:55:33.34
>>84
少なくともお前が馬鹿だって事は判った
2017/06/24(土) 21:57:13.75
いつになったらこの世からプログラミングなんていうつまらない仕事が消えてくれるのか
2017/06/24(土) 22:12:23.61
宗教とIQと教養の壁は分厚い
こいつとは分かり合えないなと思ったら無理に説き伏せようとせず
同じプロジェクトで仕事をしないことが大切なんだとおもう
マネージャーはその辺気を使ってチーム編成してほしいな
2017/06/24(土) 22:22:38.10
プログラミングは簡単だ。

1本信念をつくる。
決してブレてはいけない1本の道だ。

道半ば、多少道に迷うこともあるが、きっとお前はこの道に戻るだろう。

そして、望むのであれば、この道を永遠に進むことができる。
2017/06/24(土) 22:43:27.37
>>75
20超えたインスタンス変数をもつクラスをみる機会があれば理解できるよ
2017/06/24(土) 22:48:30.21
100列を簡単に超過する極悪テーブル
全部パブリックプロパティで振る舞いゼロの貧血エンティティ
オブジェクト指向とはなんだったのかトランザクションスクリプト
これが日本のIT業界の現状なんだよね
この劣悪なアーキテクチャを規約で強要してくるところすらある
92仕様書無しさん
垢版 |
2017/06/24(土) 22:52:44.19
にさえなってないのを気づこうな
2017/06/24(土) 23:15:30.54
職場にアメリカ人がいたことがあったけど
全く残業はしないし納期に遅れようがお構いなくすべて定時帰りだったわ
聞いた話ではアメリカではこれが普通で残業で間に合わせるのはあり得ないらしい
2017/06/24(土) 23:25:27.96
改めて自分はどれほどの実力か知る為にC＃で簡単なジャンケンゲーム作ろうとしてVS起動したんだけどさ・・・
haloWorldしか書けなかったよ・・・・
2017/06/24(土) 23:28:43.53
まああっちは問題あればクビにするだけだし、合理的
2017/06/24(土) 23:34:14.96
>>93
そりゃあアメリカは全てが自己責任だからな
2017/06/24(土) 23:35:06.04
haloWorld
98仕様書無しさん
垢版 |
2017/06/24(土) 23:43:58.98
あっち系はヤバいからプログラマーは迂闊に手を出さん方が良い
99仕様書無しさん
垢版 |
2017/06/25(日) 00:46:55.60
>>80
なんの話してるの？
就職してからまたおいで
2017/06/25(日) 01:09:20.25
キチガイ女議員と同じことやってるｗｗ
みんながんばれー
101仕様書無しさん
垢版 |
2017/06/25(日) 01:35:54.48
しかしアメリカ人はワーカホリックとも聞くし
他の企業はともかくアップルはブラック企業とも聞く
2017/06/25(日) 01:46:04.06
アメリカアメリカうっせーな
お前らどれだけアメリカ知ってんだよ？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。