  |
はてなキーワード: メンテナンスとは
本日未明より、アタイたちの艦隊これくしょんでは、「2020年梅雨イベ」こと期間限定海域【侵攻阻止！島嶼防衛強化作戦】が開始された。
提督の皆さん、大変お待たせしました！現在サーバ群開放前の最終確認シークエンスを実施中の「艦これ」重メンテナンス＆アップデート、同作業完了を以て開始される期間限定海域【侵攻阻止！島嶼防衛強化作戦】、その「前段作戦」作戦情報をお知らせしてまいります！#艦これ— 「艦これ」開発/運営 (@KanColle_STAFF) June 26, 2020
なんだかイベント前のメンテナンス中にトラブルが発生し、イベントの開始が日付をまたいじゃったそうだけど、ま、いつものことよ。
どうせ、アタイなんて爆睡してたし。イベント開始が数時間遅れようが、もーまんたい。
寝坊はしたけど、提督の端くれであるアタイも、デイリー任務を片付けつつ、
だいたい分かった。
とりあえずイベントの第一作戦海域、いわゆる「E1」海域は、イベントの第一段階に用意されている、いつもの輸送作戦みたい。
期間限定海域【侵攻阻止！島嶼防衛強化作戦】
01▼第一作戦海域
作戦海域：オホーツク海千島列島沖
「鎮魂、キ504船団」
北方での兵站輸送作戦を主軸にした作戦です。同作戦を見事攻略突破した提督方の艦隊には、特I型駆逐艦七番艦「薄雲」が合流します！#艦これ#期間限定海域#島嶼防衛強化作戦— 「艦これ」開発/運営 (@KanColle_STAFF) June 26, 2020
海域の最終マスにいるボスを倒せば、輸送作戦成功。無事に揚陸地点に物資がお届け出来ましたってことになり、物資の輸送目標量を示すゲージの残量が減る。この「輸送ゲージ」がゼロになれば、この海域はクリア。ドラム缶や大発動艇などの輸送用装備を積んだ艦娘で艦隊を組んで送れば、ゲージはより早く減らせる。
でも、アタイは輸送装備を載せない。すると１回ボスを倒しても輸送ゲージは最大でも26程度しか減らない。アタイが選んだ攻略難易度「甲」の場合、開始時点での輸送ゲージの目盛りは750。だから30回ほどボスを殴らにゃいけない。手間である。時間もかかる。
でも、それでいい。ナゼって、ボスを殴った報酬としてある程度の確率で海防艦をゲットできるらしいから。なら、チマチマと何十回でもボスを殴って、少しでも多くの海防艦たちを救い出しちゃう！どうせ、先を急ぐワケでもない。先行する頼もしい猛者たちRTA勢からの情報を待ちながら、アタイは、イベント第一段階のボスを殴る！殴る！殴る！！そして、海防艦たちをゲット！ゲット！げ～っと！
海防艦、可愛いおチビちゃんたち。ウェルカムよ！ドロップしたら、アタイの牧場で丸々太らせて、アタイの可愛い古参艦娘たちのエサにしてあげちゃうんだから！
それにしても、今回のイベント。初日からイベント海域に出撃するなんて、アタイらしくない。いつもなら、先行するガチ勢からの情報をまとめた攻略記事を読んで、数日してから「あー、面倒ねぇ」なんて呟きならがのんびり出撃するのが、いつものアタイ。
夜が明ければ暑い太陽光を避けて、吸血鬼の棺桶ならぬ快活CLUBへと転々とする日々。
財布もクレカも母港に置き忘れて出撃した途上、銃殺刑も覚悟で、発作的に敵前逃亡。
褒めてよ、経済産業省。
風の噂で、解雇が決まったと聞く。
｢こんな時に無職になったら不幸だわ。コロナ禍失業の諸手続で大繁盛なハローワークなんて、まさに三密だわ、三密ｩ！｣
なんて、テレビと会話してたけど、
まさにその不幸に墜ちたわけよね、アタイ。
ふふ。もう、ネカフェで艦これやって、しばし、現実逃避しながら、少しずつ精神のゲージの回復を待つしかないじゃないの。
そう言えば、ここも３年振り、か。
警察官だから不審者ではないというのは理屈がおかしくて 警察官が逮捕されることは歴史上あって問題に成るから
警察官でも不審者でないことは警察官であるということ以外で立証する必要性があるから
最初に警察手帳を見せたりして許可を得るという手続きが必要になる。
サーバの運営管理者であるから レンタルしているサーバのメンテナンスは不審ではないといわれても それは難しい
定期メンテナンス以外でメンテナンスが入ったら 不審だろそんなもん
ものにはよるけど
サボってるわけではないんだよ
管理職だから残業してもOKというのはある程度はなりたつんだけど
管理職だから、自分が疑われても管理職だから安心というのはいえない
もっと厳しい。
現場で十分な数の先輩がいるわけでもないため
不十分な知識でまちがえたスレッディングについて長年学んでいる人を否定できず
ようするに 車でいうと
タイヤのグリップ力が 高い車と 低い車が現場でバトルで 出会った現場に 普通のドライバーがいて その話を聞くと 事故る
そのため１度整理中 いままでは 現場で先輩が教えていたが それでも 事故
そこに大量の学生となると 考慮が必要で 技術開示請求なる 嘘から出た真まで 現場で飛び交うとの噂
現場で口伝 先輩から交配へ が 学校教育でどこまで安全先生について教えておくべきか？ そりゃ 技術開示請求とか いわれるわな
それこそ車載をやりました。作りが甘くて、車載のプログラムがバグで治せないことが発売後発覚とか そりゃ言われるだろうな。
ある車種が大ヒット そのご１０年後に ブレーキ周りのプログラムにマルチスレッディングのバグが発覚 設計上の問題で 治せない場合
そりゃいわれる。
組合せ論上 ナノセカンドを扱っていて 数兆回に１回のバグが起き得るっていわれると そりゃそういうふうに判断するだろうな。
いままでは、よかったが
看過できない組み合わせがあって、禁止する前に 禁止ではない方向で相談したい そりゃそうだ
↓
おれらならとれるが、おっしゃるように 十分なノウハウがない経験がないチームだと
かつ
十分な数の先生がいるとは言いがたい場合が起き得ることを否定しきれない
まだ時間はかかるが、私レベルなら、１０年かかるわけではない。
Hyper-Thread 90程度であれば、自分以外が書いたコードであっても 十分な時間があれば制御は可能
って そりゃ 下手すりゃ死ぬ
だけどそういう話ではなくて 十分な休養をとって、体制を作って プログラムをメンテナンスするなどは当たり前
そういうレベル。
危険性はそりゃHyper-Thread 90ともなれば そりゃたかい。シングルCPUよりマルチコアのほうがそりゃ制御は大変。同じこと。
ここ最近の COVID19Radar https://github.com/Covid-19Radar/Covid19Radar 上でのゴタゴタにより、開発者の @kazumihirose さんが https://twitter.com/kazumihirose/status/1274616019420471296 疲弊してしまいっているのを見て、(今回の揉め事の根本的な原因はソフトウェアがOSSとして公開されているのが原因ではないと思うが)いたたたまれない気持ちになったので書く。書いてみた結果ただのとりとめもないOSSへの愚痴になってしまった。
いくつかのOSSプロジェクトのメインコントリビュータとして関わっています。
私の周囲のソフトウェアエンジニアがOSSに対して以下のような意見を述べているのをよく聞く。
確かに、OSSは特定の企業に所属していないので特定企業の方針で運営が捻じ曲げられる心配がなく民主的で、細かい実装が気になったらソースコードを読むことが出来、顔も合わせたこともない優秀なエンジニアと議論を交わし共通のゴールに向かってともに開発を進められる。OSSは楽しい。
しかし一方、OSSメンテナのバーンアウトが近年問題になってきている(なんとなくここ数年で目につく数がなんとなく増えてきている)気がする。
というのも、OSSを運用していく上では楽しく優秀なエンジニアと開発をすすめるだけではなく、ドキュメントを読めば分かるようなことを質問してくる人、PR に対して changes required を下すと怒ってくる人、Twitter でこのライブラリは使いにくくて最悪だと罵ってくる人、こういった普通の会社ならカスタマーサポートさんがワンクッション挟んでくれる人たちに対しても開発者が直接対応しなければならない。
元々楽しくて始めた/関わり始めたはずのサイドプロジェクトだったのに、いつの間にか日々やってくる頓珍漢で再現環境のないバグレポートや、Issueも立てずに突然提出される意味不明なPRに対して、義務感で、就業後や土日の時間を削って、根気よくコメントを続けていると、何で貴重な自由時間をこんな訳のわからない連中のために使っているんだ?という気持ちになってくる。
実際、私の関わっていた一つのプロジェクトでは、もともと6人ほどいたアクティブなコントリビュータが徐々にプロジェクトを離れていき、(私を含めて)2人はメンテナンスに疲れてしまったのでしばらく距離を置くと宣言し休みを取っている(あまりに精神が回復したので戻れるのかは不明...)。
こういう現場を見ていると、手放しにオープンソース万歳！透明性最高！と言いながら自分自身は大してOSSに貢献してない人たちに対して苦い気持ちを覚える。
一方、私の関わっているもう片方のプロジェクトは非常に円滑に運用が回っていた。もうひとつのプロジェクトと何が違ったかというと、そちらのプロジェクトはいくつかの企業がソフトウェアエンジニアの業務時間の半分/全部をそのプロジェクトのメンテナンスに費やしていたのである。(何人かのメインコントリビュータが企業から出向する(?)する形で運用している)。
issueへの一次対応などの日々のつまらないタスクは業務でメンテナンスしてくれているエンジニアがやってくれるおかげで、他のメンテナが対応する必要のあるissueやPRは減り、みんなが開発やバグ対応に集中できている。業務でOSSに取り組んでいるエンジニアにストレスはないのかと聞いたところ、多少大変ではあるけれどお金をもらいながら自分の仕事をオープンにできるし、仕事だと思えば多少のストレスは我慢できる。とのことだった。
このプロジェクトに限らず、なんとなく長期間運用がうまくいっている大規模なOSSプロジェクトはだいたいどこかの企業が支援しているような印象を受ける(Facebook とか MS とか Google とか(大企業ばっかだな...))。もちろん全てのソフトウェア企業に大してOSSに大して大金をつぎ込めというのは現実的ではないが、open collective や github sponcers なんかに企業として少しずつでも寄付してくれたら、OSSコミュニティはもう少し良くなるんじゃなかろうか。
結局何が言いたかったかというと、エンドユーザー(OSS利用者)がめちゃくちゃ増えてきた昨今、個人レベルでそれなりの規模のプロジェクトをメンテナンスしていくのは最早厳しくなってきており、結局企業によるバックアップなんかがないと持続的な開発は難しいんじゃないかと思っている。
今日になって思ったより多くの方に読んでいただいて驚いています。あまりオープンインターネットで話しにくい話題だけど皆がどう思っているのか気になっていたので嬉しい。増田がブクマされても通知は来ないんですね(そりゃそうか)。
@bouzuya
まず焦点を当てている持続可能性が見出しから思い浮かべるものより狭いんだと思う。「最悪フォークすれば持続可能」みたいなのがぼくだと最初に思い浮かぶ
確かに、OSSの持続可能性という少し主語の大きいタイトルにしてしまったが、この文章はソフトウェアの持続性というよりかはOSSに携わる人のバーンアウトに対する憂いをつらつらと綴っているもので、ソフトウェアの持続性という意味では他にも色々やりようがある気はする。
また、私が目にしたうまく回っているのが企業による支援を受けたプロジェクトだったので、バーンアウト対策として企業による支援について述べたが、企業による支援がなくともうまく回っているプロジェクトは世の中にはいろいろあるだろうし、今後OSSは企業による支援がないとやってけないと決めつけるのは早合点ではあった。反省。(とはいえ問題意識は変わらないし、その一つの解決策が企業による支援だと思っているのも変わりない)。
---
自分の記事を読み直してみて、一番問題に感じているのはユーザーサポートの工数なんだなと分かったが、@mathane さんがその問題への一つの解答をつぶやいていた。
@methane
雑な質問やバグレポート（99％レポート者のミス）をする場所は、とにかくメンテナ以外の人が回答しやすい場所でしてもらう事が重要だと思う。
これは確かに。私はまだOSSコミュニティど初心者なので、こういうOSSをメンテナンスする上で重要なことをどんどん知りたい。
・サーバー費はXサーバーで年５万くらいのだったはず。X30とかなんとかそんなやつ
・専属なのか月何本契約なのかわからんけどライター数人雇って97％の純利ってなぁ。
・97％も純利出してくれる質の良いライターたちなら離さないように普通もっとお金出すだろうし、ライターも交渉してくるだろ。
もっと出した方がいいかもしれんけど、元々ライターなしで１億超えてるのよ。
・サーバー費はXサーバーで年５万くらいのだったはず。X30とかなんとかそんなやつ
・専属なのか月何本契約なのかわからんけどライター数人雇って97％の純利ってなぁ。
・97％も純利出してくれる質の良いライターたちなら離さないように普通もっとお金出すだろうし、ライターも交渉してくるだろ。
もっと出した方がいいかもしれんけど、元々ライターなしで１億超えてるのよ。
こんな簡単なプログラムのメンテナンスに時間かかるなんてボッタクリ
それSIerさんにもいってあげて
間違えるとお客様の情報にすこし近づく部分。ただし直接はまだわからない。簡単だろう。なんどもなんどもみなおして１日おいて 翌日みなおすおれは。
年1億PVを受け入れるサーバー費やメンテナンスの担当者、専属なのか月何本契約なのかわからんけどライター数人雇って97％の純利ってなぁ。
それで年収1億ってなぁ。
97％も純利出してくれる質の良いライターたちなら離さないように普通もっとお金出すだろうし、ライターも交渉してくるだろ。
97％の純利が出る業種なんてないとは言い切れんが、そんだけの利益率なのに1億PVで年収1億ってのは無理があるわ。
https://anond.hatelabo.jp/20200605021641
わたしはこの記事の一行目に挙げられている作品のひとつ、アプリゲーム「ダンキラ!!!-Boys,be DANCING!-」のプレイヤーをしている。タイムリーな記事だと感じたので、ダンキラサ終が決定して自分が経験したことを記録として残しておく。
ダンキラはいま現在サービス終了へのロードマップの真っただ中にある。オフライン版が実装予定なので、比較的円満な部類に入るのだろうが、「ならよかった」とは簡単には思えないのが本音だ。後述するが、新規ガチャは実装されるものの、なぜか有償ダイヤ（ガチャをするときに使用するアイテム）は購入窓口は閉まっている、という奇妙な状況も未だ続いている。結局のところ、プレイヤーが納得するしないに関わらず終わるときは終わる。なんとなく事情は透けて見えるものの、はっきりとしたことはきっと永遠にわからない。親とアプリゲーは生きているうちに大事にするに限る。という言葉に尽きるのだろうけれど。
２０１９年５月２１日にＫＯＮＡＭＩよりリリースされた３Ｄモデルリズムゲームで、いわゆるデレステみたいな感じ。キャラクターがダンスバトルをする中高生で、楽曲がヒップホップやバレエ、ジャズやインド歌謡曲など多岐にわたる点が特色だ。白泉社とコラボしており、泉ジュン子らベテラン作家による短期集中コミカライズが行なわれた（単行本全３巻発売中）。現在は月刊ＬａＬａにて番外編を連載中、だった。
５月２０日１８時、定例メンテナンス明けのアナウンスにおいて、ダンキラはサービス終了が告知された。８月５日をもってオフライン版へと移行するとのことだった。
売上的にも遅かれ早かれ……という印象だったが、いくつか違和感が残る告知だった。それは以下のような点である。
② 課金……有償ダイヤの即日販売終了、にも関わらずガチャは続行
③ コンテンツ……新規楽曲、新規ガチャ、新規ウェアの予定が八月まで緻密に組まれている
④ そのほか……アニバーサリー関連グッズのアニメイト特設予約販売が何の気もなしに始まる、LaLa連載版番外編が6月号時点での次号予告では続きそうだった（が内容を急きょ変更し7月号で打ち切り）
何はさておき、課金窓口を閉めるのはおかしい。サ終するならするで、八月までパァーーーッとプレイヤーにガチャを回させて儲ければいいのに（そしてプレイヤーもそれを望んでいる）それをしないのだ。にもかかわらず新規コンテンツの追加は八月までこれまで通り行うのだという。お陰でプレイヤー一同はみみっちい無課金プレイを強いられている。一周年を祝うおめでたいアニバーサリーガチャなのに、ある重課金者は泣く泣くミッション石をかき集め、ある廃課金者はカドスト見たさに副垢でリセマラを繰り返す。なんなんだ？これは。
というか、コンテンツ、まだまだいっぱいあるじゃんと思う。ウェアの３Ｄモデルはもう作ってるんだろうし、キラートリック（必殺技モーション）も結構作ってあるっぽいし、１０～１２章のフルボイス本編もおそらく収録済。向こう一年のキャラクターのバースデーボイスもたぶん収録済で、でもそれをなぜかゲーム内で売るんじゃなくてツイッターで動画公開するんだなあ、これが。その辺のコンテンツを全部売りつくして、半年くらい地味～に復刻イベントでジワ稼ぎして、それからサ終でいいじゃない。なんでそんなに急に死ぬのか。
印象としては、「サ終自体はいずれするつもりではあったが、なんらかの外部的要因でその時期を早めざるを得なかった」「なんらかの事情で課金窓口継続が困難になった」といったところか。ダンキラの母体はＫＯＮＡＭＩであり、ＫＯＮＡＭＩと言えば今回の新型コロナウイルスによってコナミスポーツジムが大打撃を受けている。そのしわ寄せがゲーム部門にもやってきたのではないかとなんとなく推測する。全ては推測だ。そして真実は永遠に明らかになることはない。ただこれだけは確かだ。ダンキラの世界は今閉じようとしてる。
オフライン版で個人的に悲しいのは、コンテンツの新規追加が見込めないことだけではない。
たとえば、ログインボイスがないこと。当番（艦これで言う遠征みたいな、放置クエスト）もないこと。オフライン版は時が止まっており、そこには時間は流れない。
たとえば、課金ができないこと。現実でいくら稼いでも、それが推しの新しい声や顔や衣装に生まれ変わることは決してない。
現実の世界で嫌なことがあっても、ダンキラにログインすればそれを忘れられた。ダンキラのホーム画面を開けばキャラクターが話しかけてくれた。ほとんど毎日顔を見て声を聴いて、推しというか家族に近いものだったような気さえする。オフライン版であろうとオンライン版であろうとそれが画面の向こうの存在であることに変わりはない、けれど、コンテンツが終了してしまえば、きっといずれ、わたしは彼らに魂を感じられなくなるだろう。
あーあ、と思う。バレンタインランキングイベントに推しの生誕ガチャ。楽しかったなあ。合わせてそれなりの額を課金したけど、こんなことならもっとじゃぶじゃぶ課金すればよかった。恒常☆５はいま３凸で、４凸にならないとカドストの後編が読めない。ずっと課金し続けていればいつか読めると思っていたけれど、こんなことならもっとじゃぶじゃぶ課金すればよかった（二度目）。いまやっているイベント、スコアアタックのランキングなんだけど、現在の課金の封鎖された状態で過去の課金額を競う悲しいイベントと化している。ガチャなんて所詮ギャンブルだけど、課金要素有キャラクターゲームにおける課金とは現実の通貨によってキャラクターの世界に介入することであり、少なくともそれは、わたしにとっては愛に近いなにかだった。でもそれができないんだっていうね。
ホーム画面を開くたびに余命数か月の家族に面会している気分になってしまって（自分にとっては紛れもない事実だ）、最近は会うのもつらい。そんな自分を薄情に感じる。
こんなにハマるつもりなんてなかったし、ダンキラ以外にも面白いゲームなんて山ほどある。ブルゾンちえみじゃないけれど男は三十五億いるしスッパリ辞めりゃいいのだ。でもわたしと推しのおもしろユカイな華の紅鶴学園生活は、この世でただひとつわたしのiPadの中にしかないんだよなあ……
が年々進んでるらしいけど
恋愛なんて
30%くらいの顔が平均レベルで、性欲過多でガッついている良く言えばバイタリティあふれる男が
取っ替え引っ替え
やってるんだから
そりゃまぁそうなるでしょ
顔の美醜なんて抜きにして
「いい歳になったしそろそろ所帯持つか」
頼むからセンスのない奴はプログラマにならないでくれ。迷惑だから。
これが最もプログラマになってはいけないタイプ（犯罪行為などの言うまでもないことを除けば）。
たとえば
等。
不要なものを作ることで、プログラムは複雑になり、メンテナンスの手間は増え、バグは発生しやすくなる。
一定レベル以上のプログラマが最も自然だと同意するような実装（「実装しない」という選択肢もふくめて）をパッと思い付けない奴は、センスが足りていない。
将棋で言えば、駒がぶつかったら先ず取る手を考えるといった基本的な手筋が思い浮かばないようなもので、現実的に使い物にならない。
これは、「Code Complete」「The Pragmatic Programmer」等の著名なプログラミングの本に共通する結論である。
これが「The Pragmatic Programmer」にあるDRYの原則である。
要するに、すべての情報が単一のソースから決定されるべきということだ。情報が二重化すると、それらの間で不整合が生じバグの原因になる。また、二重化した情報は、修正の手間が二倍になる。
たとえば、ユーザーのプロフィールを管理するレコードやクラスに「生年月日」と「年齢」を同時に保持する必要はない。年齢は生年月日から計算できるからだ。
世の中には、「xxxFlag」みたいな不要な変数を作ったり、共通のロジックを抽出せずにコピペコードを濫造するダメプログラマーが多すぎる。
もちろん、合理的な理由があって、この原則が適用されない場合もある。
たとえば、多くの言語組み込みの配列や文字列は、その要素と長さを二重に管理している。配列の長さは要素を数え上げることで求まるが、それには要素数に比例した計算時間がかかるためだ。
ただし、こういう場合でも、公開されたメソッドによる操作では、必ず内部の変数は同期されるように作ることが可能である。それをしないのは、怠慢でしかない。
一文字変数とか連番とかは論外だが、「ary」とか「setData()」みたいな何の情報も伝えないような変数名・関数名を付けるやつ。
正直、コードの読みやすさなんて6〜7割くらいは変数名の付け方で決まると思っている。
名著「The Art of Readable Code」も、半分以上が変数名の付け方に関連する内容だ。
なぜ変数名が曖昧になるのかと言えば、怠慢を除けば理由は2つある。
1つは、コードを書いた奴自身が、そのコードの機能を明確に言語化できないということ。
もう1つは、1つの関数で多くのことをやりすぎたりしていて、その変数の役割が曖昧になっているということ。
たとえば、関数の内部で宣言した変数は、多くの言語では関数の外からは参照できない。
スコープは狭い方が良い。これはほとんど全ての状況に適用できるプログラミングの大原則だ。
スコープが広いということは、ソースコードの多くの場所からその情報を参照・変更できることを意味する。
たとえば、クラスのメンバ変数は各々のインスタンス内でしか参照できないが、静的な変数はすべてのインスタンスが共通に持つ。このため、静的な変数を変更すると、すべてのインスタンスに影響を及ぼし、影響範囲の把握やテストが困難になる。
スコープを広げるか狭めるか、2つの選択肢があったとして、広げる方に心が傾く奴は、プログラマをやめた方がいい。
結果的にメンテナンス困難なコードを生むというのも勿論だが、単に書くだけでも、スコープが広い方が書きづらいのだ。つまり、必要もないのにわざわざ変数のスコープを広げようとする奴は頭のおかしい奴しかいないということになる。
複雑なメトリクスなどを持ち出すまでもなく、たとえば1メソッドの行数が何百行もあるとか、1クラスのメンバ変数が何十個もあるとか言うの。
これは論外である。プログラマとしての能力云々以前に、明らかな怠慢であり、社会人としての常識が疑われる。
定期的にメンテナンスされ続けているOSSのソースコードなどを見ると、関数（メソッド）の行数は平均して5〜10行。20行を超えるものは稀である。
長いものであっても、外部で定義した関数を順番に呼び出しているだけであったり、リクエストをハンドリングして各々の処理に振り分けているだけのようなものがほとんどである。
それを超えているコードは、合理的な理由があってそうなっていることよりは、単に悪い設計であることの方が多い。
これらは実はプログラミング云々というより、内容の理解力や国語力の問題なのである。
ある情報を得るために必要十分な情報は何かが分かってないから、余計な変数を作ったり、無駄に変数のスコープを広げたりする。
そして、自分が作るものを正確に理解していないから、適切な名前がつけられないし、適切なモジュール分割ができない。
それがすべての原因。
こういう人がまず身につけるべきは、プログラミングのテクニックではなく、日本語を正しく読む力。
低学歴が「プログラミングなら自分でもできるかも」なんて思っちゃいけないってこと。もちろん、下請けのSIerとかで使い捨てのコード書きとして働くことはできるが、上に書いたような最低限の力がないなら、それ以上を望んではいけない。
ちなみに、上に書いていることと反対のことを思っている人も世の中にはいる。
特に、昔からプログラミングをしてきた自称ベテランに多い。その人は、能力があるというよりも、単に現代の開発に際して必要な知識がないだけなので、真に受けないように。
また、大学でコンピュータサイエンスの基礎を学びたての学生なども、知識をひけらかしたくて上と反対のことを言う傾向がある。その程度のことは、良識のあるプログラマはみんな分かっているのだが。
(最新 | 前) 2020年5月30日 (土) 15:38 36.11.224.138 (トーク) - whois (10,300バイト) (あめぼ教信者（トーク）による第254791版を取り消し 前回取り消された理由をよく読んでください) (取り消し)
(最新 | 前) 2020年5月30日 (土) 14:57 あめぼ教信者 (トーク | 投稿記録) 細 (10,726バイト) (0503氏の考え方では特に統計はいらないようなので再取り消し。一方で今後Taxin氏は短編・コミック・PCゲーム等すべてを精査して記述して下さいね) (取り消し)
(最新 | 前) 2020年5月28日 (木) 09:39 Taxin (トーク | 投稿記録) (10,300バイト) (取り消し。定期的なメンテナンスが必要になる上、「ラスボス」の定義も確たるものがなく、短編・コミック・PCゲーム等すべてを精査した記述とも思えない) (取り消し)
(最新 | 前) 2020年5月27日 (水) 23:45 あめぼ教信者 (トーク | 投稿記録) (10,726バイト) (→色の理念) (取り消し)
おっ、バトルですか？
