  |
はてなキーワード: 開発者とは
指摘はそこじゃないと思うんだ
最近ってさ、IT開発者のイメージって、みんなWEBサービスでさ
手を動かせという場合、なんかサービスを作ってみろ、なんだよな
それこそ、知識が中途半端でも動かして公開するのが大事、みたいな
この考え、反吐が出るほど嫌いなんだよ
なんでって、WEBで公開して、誰でも触れるのに、それがどんなトラブルを産むか想像できない奴になるから
色んな所で公開されてるコードを切り貼りしてサービス作っても、むしろマイナスだよ
意図的に削除した部分とか
面倒だから書かなかった部分とかに、学ばなければならないモノが詰まってるのに
手習いでサービス公開して、秘匿すべき情報ばらまいたり、クラックされて公害になったりしても
この界隈の連中、寛容なんだよな
「手を動かせ」とか言ってるやつも、視野が狭いよな
そういうやつって、WEBのスクリプトとかしか想定してなさそう
んで、Google Map APIとか使って、緯度経度から住所を判定するサービス作ってみましたとか、Qiitaに投稿しちゃうんだろ？
つかぶっちゃけ、独学でやろうって場合、プラットフォームとそれにあった開発環境、ネイティブなのかWEBなのか、みたいな部分を自分の中で解決できないなら、やる意味ないんだけどな
そういう人間は「開発環境も、開発目的も、正解のコードも、全て与えられる」スクールとか専門学校で勉強するのオススメ
んで、会社入って、「開発環境と開発目的」を与えられる、サラリーマン開発者になるのがいいよ。
やりすぎると、富士通のケースツールに開発用の定義が全てされてないと何も出来ない、みたいな無能を生み出しちゃうけど、そこまで行くのって大手だけだしな
たとえば、DI（Dependency Injection）で検索すると、すごい数の解説記事が出てくる。それも、プログラミング初心者向けではなく、開発者向けに。
だけど、ぶっちゃけDIなんて、解説が必要なほど難しいこととも、内容のあることとも思えない。
これって、アレと同じなんだよな。数学でいつまでたっても、(-1)×(-1)=1になるたとえ話とか、0.99...=1の説明とかに夢中になってる人たち。普通に数学ができる人は、そんなのはさっさと卒業して内容のあることやるものなんだが。
おそらく、理解力の低いプログラマと、コードは書けないがオブジェクト指向は大好きなポエマーの相乗効果で、こういう話題が盛り上がったんだろうなー。
今更、こんな本を読む必要はないです。いや、出版された当時でも実質的な価値はなかったと思います。
また、挙げられている23個のパターンには特に根拠はなく、著者が思いついたものを挙げただけです。
Code Completeにも書かれているように、GoFのデザインパターンは使える状況で使えば保守性が上がるというものでありません。たいていの場合は無駄に複雑になるだけです。必要のない場面では使うべきではなく、使って良さそうに見える場面でも、ドメインモデルを再検討した方が良いです。優れたソフトウェア開発者であれば必ずそうします。
GoFを推薦している人というのは、以下の特徴があるように見えます。
実際は、GoFのデザインパターンはほとんど有用ではなく、またまともなプログラマなら仕事の片手間にぺらぺらと読んでいれば、内容も底の浅さも理解できる程度のものでしかないのですが。
これと非常に似たものに、麻雀の点数計算があります。麻雀の点数計算は、普通の知能のある人からは無意味に複雑なものに見えますが、麻雀プレイヤーの多くは合理的なものだと思っているようです。この理由は単純で、大多数の麻雀プレイヤーは頭が悪いからです。だから、点数計算が無意味に複雑なシステムであることが理解できず、また普通の人なら1日で覚えられる点数計算を苦労して覚えたから価値あるものだと思いたがるわけです。
誤解しないでいただきたいのは、「デザインパターン」という概念自体は重要であるということです。しかし、GoFは別に「デザインパターン」の原点とか典型とかでは全くないのです。理解力が低いとそういう勘違いをしてしまうようですが。
SESでキャリアをスタートさせるデメリットは、業務でも技術でも自分の核となるものが見いだせないこと。
よく言えばクライアントに合わせてフレキシブルに対応できるとも言えるのだが、たいていは最初に入った現場の慣習をすりこまれてしまうことになる。
プログラミングの技術なんかは移り変わりが激しいし、複数言語を操れるようになって初めて技術力を口にしてもいいくらいだ。
SESからOSなりネットワークなりのコアテクノロジーの開発者になれる人は少ないだろう。
一般人はアプリケーションなり運用なりに携わるのだから、長くいた現場の業務でも大学の専攻でも核となる業務知識を深めてほしい。
前からプロジェクトとしては存在していたPine Tabのことが最近話題になっていて、
https://daily-gadget.net/2020/05/16/post-15100/
なんでいまさら？と思ったら、もうじき出荷開始とのこと、おめでとうございます。
https://www.pine64.org/2020/05/15/may-update-pinetab-pre-orders-pinephone-qi-charging-more/
ブクマのコメントを見ると、特にRAMのスペック不足で使い物にならなそうという意見が多い。このスペックのタブレットにUbuntuを入れるなら、まあそうだよなという感想しかない。
でもあらゆるLinuxディストロがUbuntuみたいにリソースリッチな環境で使うことを前提として作られてるわけではなくて、省リソースと安定性を優先して作られていて組込み用OSに多く使われているArch Linuxのようなディストロもそれなりに大きな勢力として存在してる。
じっさい、Pine TabはArm版のArch Linuxを公式にサポートしてる。
https://wiki.pine64.org/index.php/PineTab
ちなみに、この記事↓の人は開発者で、Raspberry Pi Model 2にArch Linuxをインストールして普段使いデスクトップ環境を構築してる。Raspberry Pi Model 2のRAMは1GB。著者の構築した環境で、RAMの常時使用量は165MB。
https://opensource.com/article/20/3/mac-raspberry-pi
この記事に影響されて自分でも古いThinkpadにArch Linuxを入れて、ストレスなく使える程度にリソースは食う環境を構築してみた。
Firefoxを起動したとたんに使用量が跳ね上がって800 MB-1GBくらい。
なので、RAM 2GBのPine TabにArch Linuxを入れて普段使いや開発環境として使うのは全然ありだと思う。
こういうことを考えるのは面倒くさいし、もっときれいなGUI環境でタブレットを使いたい人は無印のiPadがいちばんスペックとコストのバランスが取れていて手軽なのでは。
他に詳しい人の意見も知りたい。
それについて、自分なりに何故評判が悪くなったのかを述べていきたいと思う。
元々、バグなどで問題はあったものの、ファンたちは「楽しい」という理由から気にせずに遊んでいた。
そんなバグすら許すファンたちからも見放され始めたのは、主にEP4からだ。
ここ暫く評判がずっと悪いのはEP4で起きた問題を、未だに永遠と引きずり続けているからに他ならない。
そして、それはおおよそ簡単に解決出来るような代物でも無いのだ。
※ここではバランスとかそういった話をするつもりはありません。
では、EP4の時に何が起こったのだろうか？
実は、EP1～3とEP4～6にかけてで開発スタッフが大きく変更されているのだ。
EP1~3の時は、シリーズの過去作にも関わっていたようなベテランスタッフ達が数多くいたのだが、
EP4からは一部残ってはいるものの、かなりの人が抜けて一新されているのである
これにより、従来の開発とは様々なものが変わったため、EP4から既存のユーザー達と「楽しい」が合わなくなってきているのである。
結果、バグですら我慢していたユーザー達からすらも背を向けられているというわけだ。
「何故そんなことが起きたのか？」と疑問に思う人は多いだろう・・・それについて解説していきたいと思う。
EP3～EP4にかけて、運営スタッフの離脱がとにかく多かった。
そして、そんな開発者が抜けた開発チームが今日（こんにち）の運営を行っている というのが実情である。
では、何故開発者の離脱がEP3～EP4にかけて多かったのか？
セガは隠しているのか知らないが、理由はひとえに「パワハラ問題」である。
これを聞くと、「誰がした？」とか「何故起きたのか？」とか様々な疑問が出てくるだろう…
それについて、具体名は出せないが分かる人には分かる文章で答えていきたいと思う。
最初に「誰がした？」の答えを言うと、「某EP3ディレクター」である
EP3ディレクターと聞くとファンはすぐに顔が浮かぶだろうが、そうその人である。
彼はこのゲームのニコ生配信などにも顔を出していて、プレイヤーの中にはファンも多く「SGNM」の愛称でも呼ばれている。
そんな彼を見たことがある人は意外に思うかもしれない。
配信で映っている彼は、「端正な顔立ち」「優しそうな表情」「皆にも丁寧な対応」と素晴らしい好青年に映っているだろうから、
配信だけを見ている人たちは、「まさか、彼がパワハラを行なっていたなんて・・・」と、信じられないだろう。
尚、彼はその問題が発覚して以降、このゲームの開発チームから外されてしまっている。
もはや、生配信で顔が映ることすら許されないほどに…
そこでみんなが思うのは、「何故起きたのか？」だと思う
彼は元々このシリーズのファンだった。学生時代からこのシリーズが大好きでずっと遊んでいた。
元プレイヤーから開発スタッフに加わったこともあり、この新シリーズにかけては人一倍情熱が強かった。
そんな彼は当初携帯ハード移植のディレクターに抜擢されていた・・・そして、それすらも成功に収めた。
その甲斐もあり見事EP3ではディレクターに抜擢されたのだった。
当然、彼は張りきった・・・EP3の間だけとはいえ長年好きだったシリーズのディレクターに抜擢されたのだから
これでEP3の評判が上がれば、EP3以降もディレクターを任され 最終的にはシリーズディレクターも夢では無いだろう。
そんな夢を抱いていたかは定かではないが、相当な野心に燃えていたことは 生配信中のEP3ディレクター発表での男泣きを見れば明らかである。
ここだけを聞けば、「彼は悪くないのでは？」と思う人がいるかも知れない
毎日怒った、毎日説教した、毎日怒鳴り散らした、毎日いびり倒した・・・
当然、それは男女新人ベテランなどは一切関係ない・・・開発現場からは毎日彼の大声が聞こえていた。
泣きだすスタッフがいても、仕事に戻ってこないスタッフが現れても・・・彼は一切気にしなかった
彼の中では、ゲームをより良くするため仕方のないことだったからだ。
だが、そんなことを続けていたために数か月後にはスタッフとの間には大きな溝が生まれてしまっていた。
暫く経つと、開発スタッフの中からポツポツと会社を辞めだす人が出始めた、
最初は入って間も無い新人達だった・・・ここで気づけていれば、まだ傷は浅くて済んだだろう。
だが、当時の人事担当も兼ねていたTNKマネージャーは「入ったばかりの新人達がすぐ辞めていった・・・俺って見る目が無いのかな？」などと言うだけで、全くその状況に気づけずにいたのだ。
そして、更に時間が経っていくと各担当部署のリーダー格や長年運営のサポートしていたベテランスタッフまでもが辞めだしていった。
ここでようやく、この現状に気づいた上層部たちは急遽対策を行うことにした。
まず、EP3終了と共にEP3ディレクターはその責任から開発チームを外された・・・
（まぁ、本人には原因を伝えられていないので、彼は何故開発チームから外されたのか未だに分かっていないだろう・・・）
そして、人柄が温厚で開発スタッフ達からも常々好評だった男、当時EP3ディレクターのサポートをしていたHMSKをEP4ディレクターに配置した。
が、時すでに遅し・・・把握してから対策が行われるまでに既に多くのスタッフたちが辞めていった後であった。
こうした体制変更が行われ、新体制となった中でEP4の運営が開始されたというわけだが
開発スタッフが欠如した状況で運営したEP4~EP6が、散々な状況だったのは多く人が知っているだろう。
そうそう・・・何故こんな話をしたのかを言うと、最近になって一部のユーザーからはこんな意見が出始めたからだ
「このゲームを立て直すためにEP3ディレクターを開発に戻せ！」と・・・
だが、もう一度冷静になって考えてみて欲しい・・・
この状況を生み出したのは誰なのかを・・・本当にゲームの評価を下げたのは誰なのかを・・・
なお、EP3で辞めていった多くの運営スタッフ達だが、無事に某大手ゲーム会社へと転職したという・・・
そのゲーム会社もオンラインRPGを運営していたので、開発としても都合が良かったのだろう。
元セガにいた多くの優秀な開発スタッフを引き入れた別の会社の某オンラインRPGだが、
運営当初の不評だった時とは打って変わって、見事に＜新生＞となり復活を果たした。
無駄やで そうなったら開発者ツール（ChromeならF12）出してその警告削除するし
一回消したことを察知して更に出してくるサイト合ったけどHead情報とbody内下部になるスクリプト群消すだけの話だったわ
てかアフィブログしたことないからよくわからないんだけど、今の広告ってクリック報酬じゃなくて見られるだけで報酬でるんじゃないの？
アドブロックされても見られた判定になるんじゃないんか？
開発リーダーやマネジメントをやったこともあるが、基本的に今でもずっとコードを書いているし今後も書くだろう。
俺はよくバグを出す。ひどいバグもよく出す。障害報告書が必要なバグの原因となるのが俺の設計・実装・テスト観点の見落としに由来していたことはしょっちゅうだ。どうすればバグがでなくなるか、テストの技法を学んだり、アーキテクチャの勉強も何年もしている。勉強したことを共有するのが好きなので登壇も時々する。それでもやっぱりバグを出してしまう。
手ひどい障害をおこしたときは俺も誰かの設計したアーキテクチャで、誰かの指示のもとコードを書いて、テストをして、俺が責任を持たないで済む仕事をしたいと思う事もある。
けど、ビジネス側に「これが決まらないと実装できません。以上」と優秀でビジネスに寄り添わない開発者に突き放されて宙に浮いた要求を「完全ではないけどこうすれば要求は限定的ですが満たせそうですね」とかやっちゃうんだよ。
俺は上司やビジネスにとって都合のいい存在なので、優秀でビジネスに寄り添わない開発者よりも出世してしまう。俺は優秀な開発者の軽蔑を感じながらも大事な機能を任されてバグ入りの機能をリリースしてしまう。
きついなーと思いながらも、そんなとき俺は黒田硫黄の「セクシーボイスアンドロボ」の一節を思い出す。「もっとうまくできる人がいれば、その人に投げ出していたかも。でも、それをやる人はほかには居なかったの」(voice11. 鍵)
俺の尻拭いをさせられている後任が何人もいることも、もちろん知っているし罪悪感に苛まれる夜も多い。
けど、俺は才能はなくとも常にベストを尽くしているんだ。その時、それをできる人間は「宇宙で私だけ」(voice3. エースを狙え！)だったんだ。お前はその時その場にいなかったか、寄り添わなかったか、手を挙げなかったんだ。
