  |
はてなキーワード: デザパタとは
フリーランスでゲームエンジン担当したり調整したりの仕事を今でもやってます。
「ITがつまらなくなった」「ゲーム制作がつまらなくなった」のは違う角度の話も入りますが同意です。
おそらく現在４０歳あたり以降の人たちは「めちゃくちゃコード書けた時代」の人たちだったと思います。
私もめちゃくちゃコード書いてましたし、他人のコードも修正してたし（それでキレられたり１日中討論したりも）、何より車輪の再発明がすごく楽しかった。
Game Programming Gemsが唯一の経験者のナレッジの詰め合わせで、貪るように読んでましたね。懐かしい。
というよりそうでないと生き残れなかった。
何よりもコードを書くのが楽しい、起きてる間は全てコーディング、アーキテクト、新技術の調査に時間を充てるような生き方しか出来ない人たち。
生産性？それよりもテンプレートプログラミング面白くね？意味あるか分からんけど。そういやこのコンパイラいいよね、メモリの使い方上手くてさあ。
プログラミング全般の技術力は、正しい知識を身に着けているかも重要なんですが、それよりも重要なのはライブラリの仕様を覚えるくらい何度も何度もアウトプットすることなんですよね。
DirectXやOpenGLの仕様を追えばだいたい効率的な計算方法や描画手法は身についちゃうので。
技術体系に紐づくものだったり、デザパタとかある程度知っておくものもあるにはありますが、何なら自分で見つけたくらいの方が遥かに理解度が高い。
頭で創るより、実際に書いてコンパイラ通して目で確認するほうが何倍も重要。
3Dゲームの知見がまだまだ日本に足りていない時代、ドラマチックな演出を行おうとしたら別の技術が必要になった。
今の時代では、ただFPS/TPSにすりゃええって回答になっていますが、模範解答として映画しかモデルが無かったんですよね。
しかも日本の画作りは時間を使った画作りより、止め画、見栄を軸とした画が多くて、海外のセンスとはジャンルが違う。
最先端の技術を生業にしていた大手ゲームパブリッシャー、デベロッパーは頭を抱えていました。
なにせ、個人の技術で戦ってきてしまっていた日本では太刀打ちできないことがわかったからです。
すでに海外では映画や映像の最先端の技術者やクリエイターをかき集め、サイエンスとしてナレッジ化を進めていました。
物理学者を集めまくってたのもそのときだったのを覚えています。
結果的に、大手は各社最高のグラフィックエンジンやクロスコンパイルエンジンを自社開発しようとして、（ほぼ）全て断念していますね。
……ただフォローのつもりで言いたいのですが、失敗ではあったと思いますが、そこで得た技術は非常に重要なものでして
日本は失敗を許容しない組織が多く、初めるのが遅く、辞めるのも遅い、それでいて二度と挑戦させない文化なので育つ土壌が無いんだと思います。
だいたい誰かが俺仕様で作ったクソみたいなコードを修正して、高速化したりメモリリーク改善したりがメインです。
「またコレか…」のパターン多すぎる。これがつまらなくなった所以です。
GCの仕様くらい考えたらなんでスパイクが起こるかわかるやろ……なんで調べんのなんて思うこともあります。
ただ出来ない人が多い、才能の無い人がビジネスだけでゲーム作ってる時代でもあるので、そのおかげでおまんま食べられてるんだよなって考えてます。
プロジェクトが破綻してることも多くて、その大部分はエンジニアがクソすぎるってのが多いですね。
体制の問題もあるにはあるんですが、ゲームにこだわることもなく、ただ稼げるで来ちゃった人たち。
だからそんな人達に何か伝えても響くことも無いし、生き方も違うので何も言わない。
ゲーム自体もどこかで見た何か。なので正解が存在するのでアーキテクトや制作に頭をひねる必要も無い。
感謝されるのでやりがいはあるんですが、当時激論を交わしていたような人たちはゲーム業界から離れ超ホワイトな外資系や大手でぬくぬくやってます。
幸いなことにソーシャルゲームバブルが起こり、その波に乗れた人たちです。
たまたま私の周りはコミュニケーション能力や問題解決能力、分解能力が高かったのでちゃんと地位を築き、ちゃんと生活しています。
ソフトウェア開発における名著とされる読みものがある。かつて、そういった著作のエッセンスをひたすら抜き出して黙々とまとめていくはてなダイアリーが存在した。2010 年代のことである。GoF のデザパタ本とか UNIX 哲学とかピープルウェアとかそういうの。ジュンク堂の本棚でいえば「SE 読みもの」というやつだ。業界に入って間もなかった当時の自分は、技術的な相談ができる大人が周囲にいなかった。いま思えば、残業中のオフィスで長いコンパイルを待つあいだ、ぼんやりとこのはてダを読み、目の前のやるせないソースや、所属するチームが置かれた状況について思いを巡らせながら、ガス抜き感覚でこのはてダを読む時間が好きだった。どの項目も歯切れの良い紋切り型の文体で読みやすく、読んでいるうちに不安のかたまりがスルスルと解かれていき、気持ちがラクになるような気がしたのだった。
その後、わたしがアラサーになるころには、そこで紹介されていた大部分の原著は書店で購入し物理的に所持するに至っている。あのはてダがなければ、本屋でも仕事関連の棚で足を止める人間にはなっていなかったのではないかと思う。その後、当時のはてダの内容を抜粋したものが秀和システムで書籍化され出版される運びになった。ファンだったわたしは発売をとても楽しみにしていた。が、本屋に並んだ書籍を手にとってみると、あのはてダにあった宝物のような輝きはすっかり失われていた。なぜかはわからないけれど、説得力が損なわれている気がしたのだった。書籍化の都合、はてダに貼られていた Amazon へのリンクが取り払われ、原著との接続性がいくぶん薄らいでしまったせいかもしれない。またこの書籍化に伴って、はてダも閉鎖されてしまった。もっとも新刊の売上にも関わるだろうし、あの「要約」は原著に対する網羅度がかなり高いもので、権利面ではかなりグレーなものだったように思うから、閉鎖されるのは当然の成り行きだったと言える。が、自分の成長期にあたる年代にあのはてダがあったことは本当にキャリアの上で助けになったと感じているし、原著を所持していてもなおあのはてダを参照したいという思いがあるくらい、とても優れたものだった。他人の「きれいなノート」を借りて勉強していたような感覚というか、そんなような。「新人に読ませたい n 冊の本」というタイトルのクソ記事がもはや春先の業界の風物詩になっているが、そんな記事とは段違いにもっと直接的に本が持つ価値を訴えてくるコンテンツだったのだった、少なくともわたしにとっては。
図解界隈というのが流行っていると聞いて、そんなはてダがあったことを思い出した。結局のところ「SE 読みもの」も自己啓発本に他ならないし、個人的に DDD
なんて宗教だとすら思う。それにしても「要約」がきっかけで世界が広がるとことは実際あるかもしれないよ、ということが伝えたかった。
言ってないけど。
Cから派生したCやJavaなどでやってるのはオブジェクト指向プログラミング。
クラスというものを作って、「カプセル化」、「継承」、「ポリモーフィズム」を三本の矢にして
これを提唱しているのはオブジェクト指向プログラミングを日本語で解説しているWikipediaなので間違いない。
現在の日本人に対してオブジェクト指向とは何かと問えばこれのことなので、これさえ押さえておけば会話に問題はない。
なまじっか真のオブジェクト指向に精通していると、英語版wikipediaでオブジェクト指向を学び、smalltalkなんかかじった日には、現代日本におけるオブジェクト指向がいかに偽物かわかるだろうが、奇異にみられるのはあなた自身であることを付け加えておく。
そのデザパタの意味、メリット、デメリットを自分なりに理解した上で
ファイル書き込み中に他システムが読み込んだり書き換えたりする心配が無いケースとか、
実質同じ処理だからといって同一の関数にすると他の誰かがバグ修正して特定のフローの時だけ処理を変えたつもりが全フローにおいて処理が変わっちゃうとか
そういうのを見極めるの重要。
https://adventar.org/calendars/2660
とかやってて乗り遅れた。乗り遅れたので増田に書く。
最初に少し自己紹介をする。新卒は出版社、そのあとベンチャー2社を渡り歩いて、いまはわりと大きい会社でWebの仕事をしている団塊ジュニア。出版社時代は概ね雑誌の編集で、連載やったり特集やったり。ムックや書籍も同時進行でやっていくスタイル。このアドベントカレンダーに参加してるやつらはだいたい友達（そうでない人もいる）。とくに仲が悪いのは……って、そういうことを増田だからって書くのはよくない。
以下に書く内容はタイトルの通り、編集を辞めて違う仕事をしても、あー意外と編集者やってたときのスキル役立つよなーって話。最初に目次的なものを書くとこうなる。
なんか真面目くさいな。最悪だ。最悪だと思っても書けちゃうのがプロ（鼓舞）。
別に言葉は「仕組み化」とか「見える化」「体系化」でもいいんだけど、乱雑にいりみだれてる言葉や事象を、いい感じに整理して、まとめなおす作業一式。まとめた結果は図とか短い文章になってコミュニケーション素材として用いる。会議資料になったり、営業ツールになったり、報告書になったりする。
出版社じゃない場所で仕事してみると、この「まとめなおす」機能が壊れていることがわりと少なくない。だいたい仕事はなんでもたいへんで、状況はかんたん明快！なんてこともあんまりない。だからといって、いい感じに整理しておきましよ！みたいなこともほとんどない。見てるだけで整理して章立てしたくなる。ラフを書くノリでホワイトボードにポンチ絵書いて、適当にキャプションを口で言うだけで「わかりやすい」という反応が得られる。便利。
で、部下や同僚が同じことできないと不便だから教えてみると、抽象化能力とか、抽象化したモノとモノの関連を整理する能力に欠けているとわかる。デザパタみたいにして教えてあげると、すいすいできるようになったりする。まあ地頭はわりと効くけど、どっちかっていうと訓練。取材やインタビューのまとめとかした編集者は鬼訓練されてる感じ。あとクソ原稿を直すのも似た作業ですね。量が質を作るジャンル。
だいたいどんな会社でも、会議などの社内コミュニケーションで残念なことをいうやつはいる。モチベーション下げる能力がすごい高い人、たぶんユビキタスに存在するんだ。これはアレだ、どんないい記事で、売れて、読者の評価高くても、DISってくる人はいるアレ。元編集者的にはそっくり。そういえば売れたこともDISられたこともない編集者さんはがんばろう。
若いうちはなかなか難しかったり、傷ついたりするかもだけど、想定能力と、度胸、切り返し能力あたりが見についてくる。予測力っぽい感じ。これがめっちゃ効く。だいたい知的労働をする会社は、対人コミュニケーションが主たる仕事、かつストレッサになりがちなんで、そこの予測力や度胸、切り返し能力があると、とりあえずバカ扱いはされない。
あいまいな定義を、ほどよく確認したり、論理の矛盾をいらいらさせないように指摘したりってのは、取材やインタビュー、あるいは査読した結果をフィードバックする感じとよく似ている。人格攻撃しないで、コンテンツそのものに目線を向けながら品質を上げる行動みたいな。結果議論が進む。これ便利。
なお人格が壊れている編集者は、ここがだいてい壊れてる感じする。そういう人ほど優秀ってのもまたある。人格壊れたまんま、かつて優秀だった、みたいな人もいて、これはしんどい。若くしてこじらせちゃうのと同じくらいしんどい。ぼくにもしんどみがあります。メンタルヘルス〜
メーカーっぽい会社の場合、プロダクトアウトが強すぎてマーケ不在ってことはわりとよくある。わりといけてる雑誌屋の場合、ここがしっかりしてて、自分の仕事がどう部数（＝売上）に効くかを体で覚えてて、これがよい。例えば定期購読者増やしたいとか、ECでまったくおんなじ構造の話があるので理解がはやい。
プロの物書きやプロの編集者は「うけてなんぼ」の世界だということをよく知ってるゆえ、勝手に学んじゃうってことだと想像する。いまのWebマーケはいろいろ計測できるけど、impだCVRだCPAだってのは、知ってる概念がなんか別のアメリカ人言葉で言い換えられただけで「うけてなんぼ」を知ってて、自分でやってたって人は、たいてい難しくない。
広告仕事もしてた人だとなおわかりよいかも。Web媒体というか、読者さん課金がない媒体の経験だけだと厳しいかもしれない。炎上だけやってる人のうち、インターネットを利用してインターネットの価値を下げてるってわかってやってる人ははやくほろんでほしいな。でてくる広告をマイナスクリックする技術まだか。
なんかふつうの会社の人をみていると、書くことで精神エネルギーを使い切って、読む人のことまで神経届いてないっぽい人が少なくない（全員だとはいってない）。いや出版社にもそういう残念な人いるけど、割合がだいぶ違う。あと、読む人をわりと簡単にダマさえると信じてる人も多い。ちゃんとした編集者のみなさんはよくご存じの通り、そんなわけない。
プロ編集者は目の前の文章が読者にどう読まれるかの想像力を発揮してる時間が長い。めっちゃ長い。結果訓練されまくって、文章を書く前に脳内読者の文句が想起されたりするまでゲシュタルトが鍛えられる。これがめっちゃ便利。結果として「まとめたもの」の生産性が高い。これに、最初に書いた抽象化能力や構造化能力が組み合わさると「優秀」って思われやすい。いや訓練の結果なだけなんですけど…。
逆にいうと、そこらへんを売りにしていくとうまくいきやすいってことかも。決められた手順の繰り返しより、乱打戦とかゲリラ戦に向くみたいな売り込み。いやせっかく編集やめるんだったらもう少し落ち着いて仕事したいってのはわかるんだけどもまあ（時代）。
だいぶだるくなってきたので、ここから先は端折ってく。コミュ力とか交渉力はふつうにみんな使うし、編集者ノリのままでわりとOK。会社や業界によっては謙譲の度合いとか忖度の度合いとか変わってくるけど、まあ大事なところは本音ってのは間違いない。服装や出社時刻は違う。外資はいったことないのでよくわからん。なんだっけ、まあ誠実ならOK。不誠実なやつはすぐに編集者やめてくれ。
世の中の人は恐ろしいほど、本も雑誌も読まない。Webも見ない。読み続けることに慣れてない。一方編集職の人は、大食いチャンピオンレベルで文字を摂取する。結果として知識量は多くて、かつ元ネタとして活用するように脳内におさまってるんで、そのまんま役に立つ。くそ便利。意識高まらないようにしつつ大量に読む技術、まじで編集者を支える技術だと思う。なお筆者はいまでも奥付から読むみたいなクセが抜けない。習慣怖い。
まあこれは編集じゃなくても仕事してりゃわかるか。てか編集スキルじゃなくね？
おしまい。こういう尻すぼみなスタイルよくないと思いつつも、読み直すとかあんまりしなくなってる元編集者なので初稿ってことで。どうせ編集アドベントカレンダーなんだから、もうちょっといけてる感じにだれか編集してくれたらうれしいかも。元原稿がこれじゃ、だれもやりたくないかw 送り仮名とかたぶんそろってないし。まあ項目5つくらいにして、順番入れかえたいよねふつう。
＊＊＊
編集を離れてもう5年ほどになる。やってたころは「編集はぼくに向いている仕事」って思っていたけど、まあそれ以外でも別に極端に向いてないってことはないなって感じ。たぶん知的活動とコミュニケーションがない仕事ってほとんどないってことなんじゃないかなー。
ということで、まだ編集で消耗しているみなさんは、年末進行まっただなかな人も少なくないと思いますが、なによりご健康に留意してほしいなと思いつつ、これからもよい仕事をぜひおねがいします。今はいち読者として、いろいろな記事や読み物を楽しみにしています。ノシ
プログラマとして超一流になるにはどれくらいの規模の企業が最適かという問題。
超一流の定義として、
に加えて
を想定している。
非プログラマのエンジニア（例えば化学や機械系）は設備にも試行錯誤するのにもお金が必要だし、
必然的に資金力のある順で成長環境が整っているというイメージ。
でもプログラマだけに関しては資金力や規模＝成長環境というわけではないんじゃないか。
自前でサーバーを用意・運用できるだけの資金力があればいいわけだし、100人規模の会社でも事足りる。
データ分析なんかも情報系の学士ならいつでも学びなおせるだろう。
優秀な奴もただ多ければ多いほどいいというわけでもなく、連絡が取れる人という意味でだ。
10万人規模の会社でも、仕事の中で会う人は多くて50人とかだろう。
さらにそういう超大規模会社はセキュリティ上アウトプットの自由度であったり業務の多様性であったりが制限される。
候補順として
といったところか。前半と後半のスキルの重視度合いで２と３が交代しそう
すごい今更だけど、1に対してだけ少し。
基本的に、まだ発展途上にあるものほど、理論面が強調されがちなんだと思う。
今の関数型言語は、まだデザインパターンが、色々発案されだしているけど、確立しきっていなかった頃のJavaやオブジェクト指向の時代、みたいな感じ。
Javaで言うデザパタは、関数型言語では大体、モナドとしてまとめられるわけだけれど、そのモナドを色々発明するために、圏論をしっておくに越したことはない、みたいな感じなんじゃないかと。
もっとも、そろそろすでに出てきているデザパタ≒モナドを利用するだけの、純粋な学習者も増え始めている頃合だから、気になりだしては来るタイミングなんだろうけど。
動的言語は使わない。
動的本をすべて捨てる(人の手に渡るような捨て方はしない ちり紙交換がよい)
動的DBは使わない。リレーションのない動的DBは使わない(mongoDBやNoSQL系）
動的オープンを紹介してくるメデイアのステマに気づき騙されない
Silerが勧めてくる技術は独立できない技術だからやらない 関わらない
職務経歴書に黒歴史(PHP Java JavaScript Ruby RoR Html5)を書かない
PHP Java JavaScript Ruby RoR Html5の仕事は請け負わない
C# Objctive-cだけ使う
VisualStudio Xcodeだけ使う
VisualStudio Xcodeを機能をフル活用する
WindowsServerを使う
デザパタを覚える
コミュニケーションはOffice 365 redMine,イラレGit Svnを使う
動的言語をこれ以上広げるな 罪を重ねるな 脆弱性をばら撒くな トラブルを撒くな
セキュリティに問題のある動的言語はどこにいってもトラブルになる
原発のシステムにRuby,RoR,PHP,JavaScriptを使いたいと思うか？Silerはなら提案してくるだろう儲かるから
使えば必ず原発はハックされる
C# ASP.netは2007年頃から海外では大流行だった 一方日本のメディアは盛んにLAMP!LAMP!RoR!RoR!煽っていた
C#（静的言語）は14年前のソースが今でも使うことができる。VisualStudioにはソースを自動バージョンアップ機能があり書き換えてくれる。 コードが負債にならない コンパイル時バグがわかる DLLのバージョンをチェックしてくれる ブレイクポイント リモートデバッグ
動的言語・オープン系は 手作業で直す どこにバグあるか実行しないとわからない 脆弱性が出るたび バージョンアップ、機能追加のたびに修正することになる リファクタが使えない 負債言語
この数字を見て動的言語関係者はびっくりしているだろう。 14年前のPHPソース 使えると思うか？関係者は首を横に振るだろう。時間と人手をかけて改修すれば使えるかもしれない(多くの場合作り直したほうが安上がりという結論になると思うが) 脆弱性や仕様変更がたくさん埋まっているソースだ 修正には手間と時間と予算がかかる
C#なら一瞬で最新の.netフレームワークのバージョンに書き換えてくれる。エラーや警告の表示も一緒に出力されるから手直しが簡単
PHPを捨てたほういい理由
今はRoRのステマが醜くそれに騙されて使ってしまった人がいるが、今後、仕様変更やバグ、脆弱性は出続け、そのたびに全ソースを検索し手動で手直しをしなければならなくなる それは新しいことをやっている時に起こるだろうし、今やっている新しいことが負債に変わる。作れば作るほど負債が増え、前に進むことができなくなる言語 それが動的言語 メンテナンスが常に必要でほっとけばハックされる。保守や改修に人が多く必要で中間業者は儲かるのでメディアや無料育成を通して広めてくる 煽っておいて自己責任の国 日本
静的言語のサーバーサイドで何がいいかというと 自分は C＃ Asp.net(asmx or webApi) Ado.net 接続 & 非接続のDataSet 管理.exeアプリ(C# WinForms)をお勧めする やり方
もうお分かりいただけただろうか？動的言語とはSilerが定期的に仕事を得るために広めたガラクタ言語だったということを この言語をいつまでも高い稼働の保守作業が必要だ。機能追加、言語の仕様変更、脆弱性を修正するのにお金も時間もかかる Silerはパンク屋だったのだ。 メーカー製の静的言語を使えばここまで時間も手間もかからなかった。
これ以上元請けはSilerが言われるがままにガラクタ言語を導入しないほうがいいだろう。技術者はSilerが無料で教育してくれるからといってガラクタ言語を学ぶのはやめたほうがいい。(洗脳されて信者になるな) 特に技術者はこの言語をマスターしたからといって独立はできない。なぜなら、５人以上のプログラマーが働いてやっと出来上がるものがほとんどだ。手間がかかるということは自分が一番よくわかっているはずだ。言語とともに使い捨てられる運命にあるのだ。IT経営者やSilerはその方が都合がいい。こき使ってやめられても独立できないのだから。雇ってはこき使って使い捨てる。まさにIT版のねずみ講 上のしか儲からないようになっている。 それに加えて酷いピンハネ。１００万で売って７割以上搾取 一人送れば７０万円入る世界だ。Silerにとって開発現場は炎上すればするだけよい。言語は脆弱性があればあるほどいい、システムが手間が掛かるなら掛かるほどいい その分人を送り込めるからだ。その辺にいる素人を適当に教育して３年開発の下駄はかせて送り、現場を炎上させて新たに人を送り込んで利益を得ている。
#1 PHPで改修しようにも簡単には改修できなくて、その間にハックされ情報が流出すること結構あるようだ @WikiはPHP
#2 2013年 Javaフレームワーク Strutsのサポートが終了した こういうフレームワークをメデイアで煽っておいて最後は自己責任される。オープン言語はやってはいけない
#3 これはどの業界にも言える事だが、気合い、根性の気合馬鹿から組織を乗っ取られないようにするにはどうすればいいか考えないといけない。コミュニケーションで社員を懐柔し組織を乗っ取った筋肉馬鹿は面倒なことを気合い根性で乗り切ろうするから失敗する。日本はそのしわ寄せがまず下くるから会社が壊れる。脳筋バカは最後まで居残る。（○ーイズ、○ルマー、○ニー、旧日本軍、ジオン軍）タバコ室や残業は特定の社員を仲良くさせるからだめなんだろう 履歴書の項目が少ないのも問題なんだろう 理系か体育会系,血液型,さう脳とか履歴書は書く項目が少なすぎる
#5 仕事の最終目的はコミュニケーションではない コミュニケーションするコストが高いといつのまにかそれが目的に置き換わってしまう事がある。コミュニケーションの得意な奴が本当に優秀な人をさしおえて前にでてくることだってある。Office 365やRedMineイラレSVNなどでコミュニケーションコストを下げることで優秀な人が大声を張り上げなくても力を発揮できる環境を作るべきだ
#6 事務仕事のツール化、自動化、ロボット化、コミュニケーションコストを低くするツールの導入で、声が大きい人や事務だけ得意な人が権力を握ることを防ぐ事が出来る
#9思えばSiler業界は自分たちが儲かりがたいためにガラクタ言語(Java,PHP,RoR,Ruby,Js,Html5,Flash)に人材を誘導しすぎた。出来損ない言語の非効率な生産性と保守作業は社会の進化が遅れ世界とのソフト技術に差がついてしまった。人材も非効率的なスキルしか身に付かなかった。それしかやらせてもらえなかった。
しょーもない言語は社会の発展を止め、技術者を路頭に迷せた。有益な言語を一つだけ覚えさせ、いろんな業界で使い回した方が業界的にも技術者的にも幸せになれたのではないか？
C#はロボットや組み込み機器,医療機器,WEB,スマートフォン,ゲーム,CG デスクトップアプリ,業務用ツール 様々なところで使う事ができるのだ。
特にロボットはMocrosoft Robotics StudioというVisualStudioのロボット版の開発環境が2006年頃から出ており、ロボット産業を発展させることだってできたのだ。(そのころのIT業界はJavaとLampが主)
続き
C# Objctive-cだけ使う
VisualStudio Xcodeだけ使う
VisualStudio Xcodeを機能をフル活用する
WindowsServerを使う
デザパタを覚える
コミュニケーションはredMine,イラレGit Svnを使う
動的言語は使わない。
動的本をすべて捨てる(人の手に渡るような捨て方はしない ちり紙交換がよい)
動的DBは使わない。リレーションのない動的DBは使わない(mongoDBやNoSQL系）
動的オープンを紹介してくるメデイアのステマに気づき騙されない
Silerが勧めてくる技術は独立できない技術だからやらない 関わらない
職務経歴書に黒歴史(PHP Java JavaScript Ruby RoR Html5)を書かない
PHP Java JavaScript Ruby RoR Html5の仕事は請け負わない
動的言語をこれ以上広げるな 罪を重ねるな 脆弱性をばら撒くな トラブルを撒くな
セキュリティに問題のある動的言語はどこにいってもトラブルになる
原発のシステムにRuby,PHP,JavaScriptを使いたいと思うか？Silerはなら提案してくるだろう儲かるから
使えば必ず原発はハックされる
C# ASP.netは2007年頃から海外では大流行だった 一方日本のメディアは盛んにLAMP!LAMP!RoR!RoR!煽っていた
C#（静的言語）は14年前のソースが今でも使うことができる。VisualStudioにはソースを自動バージョンアップ機能があり書き換えてくれる。 コードが負債にならない コンパイル時バグがわかる DLLのバージョンをチェックしてくれる ブレイクポイント リモートデバッグ
動的言語・オープン系は 手作業で直す どこにバグあるか実行しないとわからない 脆弱性が出るたび バージョンアップ、機能追加のたびに修正することになる リファクタが使えない 負債言語
この数字を見て動的言語関係者はびっくりしているだろう。 14年前のPHPソース 使えると思うか？関係者は首を横に振るだろう。時間と人手をかけて改修すれば使えるかもしれない(多くの場合作り直したほうが安上がりという結論になると思うが) 脆弱性や仕様変更がたくさん埋まっているソースだ 修正には手間と時間と予算がかかる
C#なら一瞬で最新の.netフレームワークのバージョンに書き換えてくれる。エラーや警告の表示も一緒に出力されるから手直しが簡単
&blanklink(PHPを捨てたほういい理由){http://www.slideshare.net/neuecc/c-22979400?v=qf2&b=&from_search=42}
今はRoRのステマが醜くそれに騙されて使ってしまった人がいるが、今後、仕様変更やバグ、脆弱性は出続け、そのたびに全ソースを検索し手動で手直しをしなければならなくなる それは新しいことをやっている時に起こるだろうし、今やっている新しいことが負債に変わる。作れば作るほど負債が増え、前に進むことができなくなる言語 それが動的言語 メンテナンスが常に必要でほっとけばハックされる。保守や改修に人が多く必要で中間業者は儲かるのでメディアや無料育成を通して広めてくる 煽っておいて自己責任の国 日本
静的言語のサーバーサイドで何がいいかというと 自分は C＃ Asp.net(asmx or webApi) Ado.net 接続 & 非接続のDataSet 管理.exeアプリ(C# WinForms)をお勧めする やり方
もうお分かりいただけただろうか？動的言語とはSilerが定期的に仕事を得るために広めたガラクタ言語だったということを この言語をいつまでも高い稼働の保守作業が必要だ。機能追加、言語の仕様変更、脆弱性を修正するのにお金も時間もかかる Silerはパンク屋だったのだ。 メーカー製の静的言語を使えばここまで時間も手間もかからなかった。
これ以上元請けはSilerが言われるがままにガラクタ言語を導入しないほうがいいだろう。技術者はSilerが無料で教育してくれるからといってガラクタ言語を学ぶのはやめたほうがいい。(洗脳されて信者になるな) 特に技術者はこの言語をマスターしたからといって独立はできない。なぜなら、５人以上のプログラマーが働いてやっと出来上がるものがほとんどだ。手間がかかるということは自分が一番よくわかっているはずだ。言語とともに使い捨てられる運命にあるのだ。IT経営者やSilerはその方が都合がいい。こき使ってやめられても独立できないのだから。雇ってはこき使って使い捨てる。それに加えて酷いピンハネ。１００万で売って７割以上搾取 一人送れば７０万円入る世界だ。まさにIT版のねずみ講 上のしか儲からないようになっている。Silerにとって開発現場は炎上すればするだけよい。言語は脆弱性があればあるほどいい、システムが手間が掛かるなら掛かるほどいい その分人を送り込めるからだ。その辺にいる素人を適当に教育して３年開発の下駄はかせて送り、現場を炎上させて新たに人を送り込んで利益を得ている。
#1 PHPで改修しようにも簡単には改修できなくて、その間にハックされ情報が流出すること結構あるようだ @WikiはPHP
#2 2013年 Javaフレームワーク Strutsのサポートが終了した こういうフレームワークをメデイアで煽っておいて最後は自己責任される。オープン言語はやってはいけない
#3 これはどの業界にも言える事だが、気合い、根性の気合馬鹿から組織を乗っ取られないようにするにはどうすればいいか考えないといけない。コミュニケーションで社員を懐柔し組織を乗っ取った筋肉馬鹿は面倒なことを気合い根性で乗り切ろうするから失敗する。日本はそのしわ寄せがまず下くるから会社が壊れる。脳筋バカは最後まで居残る。（○ーイズ、○ルマー、○ニー、旧日本軍）タバコ室や残業は特定の社員を仲良くさせるからだめなんだろう 履歴書の項目が少ないのも問題なんだろう 理系か体育会系,血液型,さう脳とか履歴書は書く項目が少なすぎる
#5 仕事の最終目的はコミュニケーションではない コミュニケーションするコストが高いといつのまにかそれが目的に置き換わってしまう事がある。コミュニケーションの得意な奴が本当に優秀な人をさしおえて前にでてくることだってある。 RedMineイラレSVNなどでコミュニケーションコストを下げることで優秀な人が大声を張り上げなくても力を発揮できる環境を作るべきだ
#6 事務仕事のツール化、自動化、ロボット化、コミュニケーションコストを低くするツールの導入で、声が大きい人や事務だけ得意な人が権力を握ることを防ぐ事が出来る
#7思えばSiler業界は自分たちが儲かりがたいためにガラクタ言語(Java,PHP,RoR,Ruby,Js,Html5,Flash)に人材を誘導しすぎた。出来損ない言語の非効率な生産性と保守作業をしている間に社会の進化が遅れ世界とのソフト技術に差がついてしまった。人材も非効率的なスキルしか身に付かなかったしそれしかやらせてもらえなかった。
しょーもない言語を技術者に学ばせて社会の発展を止め、技術者を路頭に迷よわすよりも、有益な言語を一つだけ覚えさせ、いろんな業界で使い回した方が業界的にも技術者的にも幸せになれたはずだ
C#はロボットや組み込み機器,医療機器,WEB,スマートフォン,ゲーム,CG デスクトップアプリ,業務用ツール 様々なところで使う事ができるのだ。
特にロボットはMocrosoft Robotics StudioというVisualStudioのロボット版の開発環境が2006年頃から出ており、ロボット産業を発展させることだってできたのだ。(そのころのIT業界はJavaとLampが主)
http://gigazine.net/news/20121231-kiva-system/
それを開発している会社の採用情報 採用言語はC++ C# Java
http://www.kivasystems.com/careers-at-kiva/
PHP RoR JS Rubyなんてどこにも書いていない 数年もすれば仕様が変りバグや脆弱性を出す危ない言語だとわかっているのだろう こんな危ない言語は使ってはいけない
Mocrosoft Robotics Studio
http://www.saturn.dti.ne.jp/npaka/robotics/index.html
https://www.microsoft.com/en-us/download/details.aspx?id=29081
続きはWEBで
PHPerの問題点は、視野が狭いこと。典型的には以下のような悪癖を持つ。
何も知らないからPHPを愛せるんだよ、PHPerは。だからまず、HTML、CSS、JavaScript、SQLを覚えろ。次に、Javaに移行しろ。そんなに難しくないよ、Java。特に大量にコードを書けるPHPerは、速度が出てライブラリ化が容易なJavaの方が向いている。今はVPSがあるので、小規模案件でも問題ない。
15年間ほどPHPはインターネットを支えてきたが、そろそろ設計の脆さが問題になっている。PHP 6の開発が振り出しに戻ったのは、不幸な事故ではない。ウェブで仕事をしていれば、PHPとJavaで共通する知識も多い。PHPerはJavaを覚えてPHPとさよならしろ。そして恥ずかしい悪癖を直すべきだ。
プログラム自体を好きになって、好きを原動力に色々やれるのが一番理想的なんですけどねえ。
原理原則系の本は、SICPを途中まで読んだとか、コードコンプリートとか、アーキテクチャ系だとCODEとかの啓蒙書に近いのを読んだくらいですかね…。
あとオブジェクト指向の本は結構読みましたね。デザパタを暗記するとかは無理ですが、原理的なところはだいぶ理解してると思います。
（言語仕様とかと違って、ある程度抽象的なので理解しやすいですね。使う頻度が高いというのもありますが）
他にも細かい勉強は色々齧ってますが（プログラミング言語を作る、という本で再帰下降パーサの辺りまでやったりとか）、いかんせん根本的に興味がないのですぐ忘れますね…。
文字列処理云々も、K&Rとか読んだときに一通り勉強してるはずですが、すぐ忘れます。
上っ面だけでなく原理が重要というのはある意味その通りだと思いますが、自分にとっては上っ面の細かい仕様とかが一番苦痛なのが辛いところです。
結局実務では上っ面が必要ですからね。できればpython辺りで全て済ませたいですが、すぐ処理効率だのなんだのといった面倒な話になりますね。
生きるの辛いです。
いや、えーと、この話に関しては、ガチプログラマの方々がどういう価値観で人を判断するのかとかが良くわかってとても為になってます。
ほんと、分散環境で大規模データ処理だの、高速ネットワーク通信だの、ガチプログラマが大活躍のこのご時勢、当分続きそうだと思ってます。
時代の流れ、ニーズの変化に応じて柔軟に対応できるのが本当に優秀な人なんだろうと思いますが、自分にはなかなか難しいですね…。
そろそろ四月ということで、職業としての「プログラマ」になる方も、はてな界隈では多いでしょうか。なにはともあれおめでとうございます。マの世界へようこそ。私も４月になるので、心機一転頑張りたいなと思い、働いて学んできたことや言われてきたことなどをつらつらと書き出します。
仕事のルールはたくさんあります。その中で座右の銘ではありませんが、指針となるような一つ目標があるといいでしょう。私が念頭に置いているのは「三年後に気持ちよく転職できるようにする」ということです。結構移り気が激しいタイプなんですよね。でも人には嫌われたくないという。「気持ちよく」というのがポイントで、会社を「気持ちよく」辞めて転職するのは今までに辞めていった先輩をみていてもなかなか大変そうです。「気持ちよく」辞めるための仕事術を「上司」「同期」「後輩」「自分」という点であげてみました。大切なのは「気持ちよく転職できるようにする」ために周りの人を気遣いそれを示すことで「あいつはよく頑張ってくれた」「次も頑張ってもらいたい」「また一緒に仕事をしたいな」と思ってもらい惜しまれつつ転職できるようにすることです。
あなたの上司は仕事全体の進捗の管理とメンバーの割り振りを考えます。そのために各人に割り振った仕事の進み具合や仕事量に無理がないかを把握する必要があります。あなたはそれを考えて、自分が行っているタスクの状態をきちんと上司に報告しましょう。現状に無理があるようなら、その状態と代替策を上司に相談しましょう。
大抵の人は忙しいのと、別の問題で頭を使っているため、きっとあなたが頭を悩ませて質問したいと思っている、その特定の問題について、あなたほど深く考えていないでしょう。そんな時にただ質問も投げられても、相手も一から考えてしまうので、お互いに負荷が高くなってしまいます。それで相手のことを考えて、技術的な質問や方針などの相談の際には質問の後に「こうしてみようと思う」「この点が問題なのでこうすれば解決するはず」など、それなりに自分の答えをもって、質問や意見をすべきです。そうすれば相手もそれをベースに自分の意見や経験を考えながら伝えることが出来るため、あなたの質問に答えることがそれほど重荷ではなくなります。
楽しく笑顔で働きましょう。笑う門には福来るではないですが、多くの人は笑顔に惹き付けられるものです。また上司も基本、自分の舵取りでメンバーが楽しく仕事出来ていると思いたいものです。それに応えましょう。
会社には多くの場合、コーディングルールやドキュメント規則があります。「こうしたほうが早いのになあ」とか「こんなのクールじゃない」とか考えることもあるでしょうが、ルールに従いましょう。３年後に後輩に「ここはクールじゃなかったらこうした」と説明するのは大変ですし、きっと３年もたてば、その「クール」も変わっているはずです。もしどう考えても効率が悪いようなら会社のルール自体の改善を訴えましょう。
上と矛盾するようですが、急ぎ仕事（こればかりやる会社もある）をやる場合は、ドキュメント不要ということもあります。そんな場合でも最低限の仕様等のドキュメントの記録を残しておきましょう。引き継ぐ後輩に口頭で伝えるのは手間というより、忘れている部分も増え、伝言ゲーム状態になります。これは、人日を割当られていないのにやるわけですから、ちょっと大変ですが、意識しておきましょう。
自分がどう考えて、どう上司とやり取りをしていたかを簡単な記録でいいので毎日つけましょう。将来の後輩が見た時にきっとそれが、励ましや何かのヒントになるはずです。
自分についてはこのひとつだけ。失敗をしないのは仕事をしない人だけです。三年後にはどうせ転職するのですから、失敗をおそれずルールを守りながらも常に新しい何かを探して創りだしていきましょう。そうすれば転職の際に自分はこういう挑戦をしてきたという自信が出来ますし、以前の会社で思い切れば未練なく辞めることが出来ます。
失敗は怖いですが、それを少し減らす方法として「失敗を想定する」プログラマ的に言えば「例外処理」を考えておくというのがあります。人はわからないものは怖いですが、失敗した、間違いを犯した場合はこうすればいい、最悪こうなるということがわかっていれば、その恐怖は減るものです。そしてその「例外処理」を書きおわったなら、明日のことを考えて、思い悩むのは辞めて、その日、その日の仕事を頑張りましょう。
仕事の進め方について書いてみましたが、冒頭でも述べたように、プログラマは一サラリーマンである以上に一職人です。プログラムについての勉強を常にしましょう。勉強は会社をやめても人を裏切りません。プログラム言語についてはもちろんですが、それだけではありません。仕事をしているとついつい忘れがちになりますが、基本的なデータ構造とアルゴリズムやデータベースの仕組みやネットワークの仕組み等の計算機科学を知っておくことが大切です。またプログラムの組み方については、デザパタやエンタープライズアーキテクスチャパターンなどを知っておくと仕事をすすめやすいでしょう。
私のおすすめは「勉強会駆動勉強」です。何か勉強したいな、身につけたいなあと思うことがあったら、それをテーマに近くのコミュニティの勉強会の発表申し込みをします。人に教えようとすると自分のものにしなければいけませんから必死に勉強します。するとその知識が身に付くのはもちろんこと、その分野について詳しい人と周りに思ってもらえるかもしれず、また第一人者からアドバイスを受けることもできます。なかなかの一石三鳥です。
勉強のことについて、最初と逆になりますが私たちは一職人ですが一サラリーマンです。ハッカーといえど、社会人としての基本的な知識である英語や数学や経済学をおさえておきましょう。経済学は感覚とは違う部分で社会が動いていることがわかり、おもしろいです。私のおすすめは「スティグリッツ入門経済学」ですね。また習慣として毎日のニュース（日経）や週ペースの経済雑誌（東洋経済等）を読んで、基本的な現代経済をおさえておきましょう。自分の仕事を社会の目から客観的におさえることが出来ます。
最後に。仕事のことや勉強のことをたくさん書いてきました。しかし、仕事に最適化しても人生はおもしろくありません。運動を適度にし、自分の趣味を見つけて興味を持ち（私はアニメとラノベ読み）、いろいろなことを学んで、楽しみながら人生を過ごしましょう。
これマジ？
俺、未経験（もちろん非情報系専攻）で業界に入ってプログラミングやることになって1年くらい経つ。
その間の学習の軌跡はだいたいこんなもん。
実際にはコード書く以外の仕事してる期間も結構ある（半分くらい）。設計考えたりとかアルゴリズム考えたりとか。
でも俺、ギークとかなんとかみたいな変態的プログラマの人たちには全く追いつける気がしないし、わかんないことだらけで俺センスねーなーと思うことしきり。本当に。
「珠玉のプログラミング」っていう本があるけど、あれみたいにビットレベルでコンピュータの原理を最大限活用してパフォーマンスの高いコードを書く、みたいな考え方がさっぱり身につかない。
でもこのエントリ見ると、俺もちょっとは自身もっていいんじゃね？って気がしたわけだ。
でもやっぱりそんなことは無いのかな。
ちなみにデザパタ関連およびOOP関連では『デザインパターンとともに学ぶオブジェクト指向のこころ』っていう本がマジオススメ。感動的にわかりやすい。
