  |
はてなキーワード: ソースコードとは
http://anond.hatelabo.jp/20160902031012
はてブで批判してる人たちよりよほど志のある学生さんだと思うので、いろいろ書いてみます。おっさんのたわ言ではありますが、元記事の人にすこしでもヒントになればと思って。
まず、日本の大学で勉強しても実用的なソフトウェアが書けるようにはなりません。どういうことかというと、「情報系の大学に行けば○○が作れるようになる!」という世間一般の期待と、実際に大学で教えている内容には大きなギャップがあるということです。
これは大学が悪いのではなく、大学はそもそもそういうものであって、それが世間に認知されてないというだけです。
具体的に挙げてみましょう。
大学で教えてる内容ってこんな感じなので、ゲームやアプリやサービスを作ることが目的の人から見ると、役に立たない内容にしか見えませんし、実際たいして役に立ちません。その証拠に、大学の情報系学科を出ていないのにゲームやiOSアプリやWebサービスを作っている人はゴマンといるし、逆に日本の大学の先生でゲームやiOSアプリやWebサービスを作れる人はほとんどいません。
これは重要なことなのでもう一度書きますが、日本の大学の先生でゲームやアプリやサービスを作れる人はほとんどいません。大学の先生が得意なのは、プログラムを書くことではなく論文を書くことです。論文のためにプログラムを書くことはありますが、あくまでおまけです。
そのため、大学で勉強してもゲームやアプリやサービスが作れるようにはなりません。だって教えている側の先生が、ゲームやアプリやサービスを作ったこともなければ、作り方も知らないんだから。
そういう経験のない人たちばかりですよ、日本の大学の先生って。そんな人たちの授業を受けて、アプリやサービスが作れるようになると思うほうがおかしいでしょう。
ためしに、先生方のTwitterアカウント名でGithubを検索してみてください。いまどきGithubにアカウントがないとか、あったとしてもTestCaseすらないコードとか、そんなものばかりです。「研究内容をライバルに知られるわけにはいかないからGithubは使わない」という言い訳する人がいそう。けど、本当はGitが使えないだけでしょ？
あるいは、先生方の個人ページや研究室の紹介ページを開いて、HTMLソースを見てみてください。doctype宣言がないとか、viewportの指定がないとか、Pタグの中にULタグを使ってるとか、そんなのばかりです。HTMLすらろくに書けない人が、Webアプリを作れると思いますか？きっとXSSもCSRFも知らないですよ。
ですので、そういうことを勉強したいなら、ベンチャーやIT系企業に入るべきです。大学でそういうことを勉強しようとしても、教えられる人がいないから無理。
（「大学はそんなことを教える場所ではない！」と怒る人いると思うけど、教えられる先生がいないという事実をごまかすために怒ってるだけだから。）
とはいっても、大学の先生がプログラムがいっさい書けないというわけではないです。彼らが得意なのは、コンパイラやインタプリタやOSやソルバを作ることです。これらも実用的なソフトウェアと言えなくはありませんが、ゲームやアプリやサービスとはジャンルが大きく違います。
そのため、大学の情報系学科に進めばコンパイラやOSや機械学習ライブラリを書けるようにはなるかもしれませんが、それはゲームやアプリやサービスではないので、繰り返しになりますがそれらを作りたい人には大学は向きません。
じゃあ大学で授業を受けるのってムダなのかというと、必ずしもそうではないです。
大学で教えている内容って、ゲームやiOSアプリやWebサービスが一通り作れるようになってから、その先を目指すときになって初めて必要になることが多いです。たとえば、
こういうときになって、初めて大学で教わった内容が生きてきます。逆にいうと、そういう状況にならないと、大学で教わった内容は生きてこないと言えます。（情報系の学科で学んでいるなら、ライブラリや言語やOSを「使う人」ではなく「作る人」にぜひともなってほしいですね。）
元増田は、社会に役立つ実用的なソフトウェアを作りたいようです。しかし残念なことに、大学が教えている内容はその目的には合致していないことを説明しました。
こういう事情なので、元増田には大学をドロップアウトしてIT系の会社に入社することをお勧めします。ドロップアウトが難しいなら、インターンやバイトでなんとしても入り込むことです。
入るべき会社は、教育に力を入れている会社です。20人未満の小さな会社では教育に力を入れている余裕はないので、小さな会社はやめたほうがいいです。簡単にぐぐってみたところ、はてなやPixivやクックパッドやDeNAやドワンゴは教育制度が確立しているようです（違ってたらごめん）。そういった会社に入ったほうが、大学の授業を受けるよりも、元増田の目的にかなうのは間違いありません。
そして何年か働いて、iOSアプリやWebサービスが一通り作れるようになったら、大学に入り直すことです。これはとても効果的なので、元増田には強くお勧めします。
上で説明したように、大学というところは、ゲームやアプリやサービスの作り方は教えてくれず、それらが作れるようになって初めて役に立つことを教えてくれます。そのため、元増田はIT系の会社に入ってアプリやサービスの作り方を勉強し、それらが作れるようになってから再度大学の門をたたくのが、いちばん効率的です。
なお繰り返しますが、入るべき会社は「教育に力を入れている会社」です。今のIT系企業では、インターン生を「格安で使えるバイト君」としか見なしていない会社が多すぎます。そういう会社は、コストが掛かることはいやがるので、教育もろくにはしてくれません。逆に教育に力を入れている会社では、インターン制度を「将来の戦力を選別する期間」と見なしています。
残念ながら、そういう会社は東京に集中しているようです。例外は京都のはてなくらいでしょうか。地方の大学生にとってはつらい現実なので、はてなやPixivやドワンゴは地方でのインターン開催をお願いします。あとレベル5は九大と九工大の学生を鍛えてあげてください。
余談ですが、学生さんにひとこと：
インターンやバイトで潜り込む先の会社を選ぶときは、就活と同じような時間をかけて選んでください。バイトだからとかインターンだからという軽い気持ちで会社を選ぶ大学生が多いから、それを食い物にしている悪質経営者があとを立ちません。インターン生が「格安の学生バイト」として使われている現状を是正するために、学生のほうでも注意してください。
ドロップアウトを進めた手前、書こうと思ったけど、長すぎるのでやめた。
リツイートが100超えたら書く。
まだまだ一部のエンジニアにとって、という話だよね。
少なくとも英語の読み書きができないと最新のテクノロジー情報をキャッチアップできないとか、stackoverflow読めなくて問題解決できないとか、オープンソースにコントリビュートできないとか、これはまさにその通りだよな。オレもオレなりに英語力の不足を痛感する機会は腐るほどある。
でも日本にいる80万人以上のITエンジニアのうち、そうした能力を必要とされないエンジニアがこの日本の大部分だ。
なぜならSIerみたいな受託開発・運営がソフトウェア業界の売上高6兆ぐらいのうち半分以上で、かつ彼らの大部分は日本語ドキュメントが充実してる枯れきった技術を使い続けるから。
枯れた技術で安定性を担保ってのはわかるが、公式のサポートが終わってるJava4~6,PHP5.0~5.3を使ってんだよ。保守じゃなくて新規案件だよ。COBOL,アセンブラみたいな化石言語を保守し続けるところもあるがあれはもっと別の世界から来たナニカって感じだな。そっちはよく知らん。
オレは新卒で入った受託ソフトハウスや大手SIerで計8年働いて、6年ぐらいはwebアプリのプログラマ・SEとして色んな現場みたが、オレも含め一緒に仕事する人は誰も英語なんて求められてなかった。英語読むより怪しいExcel仕様書なりソースコードのコメント読むなり顧客のメール読むなりして汲み取るのが大事だし、コーディングで困ったら日本語でググればまずヒットする問題ばかり。
コーディングで英語を使うと可読性が下がるから変数名・メソッド名・データベースのテーブルやカラム名もヘボン式ローマ字表記で書けってわけ。顧客マスタは「KOKYAKU_MASUTA」だし、担当者は「TANTOUSHA」と「TANTOSYA」で表記ゆれ、笑えるよな。
とにかく言いたかったのは、docker1.12だとかRails5だとか機械学習の新しいフレームワークだとかそういう話題でワイワイやってる層とはまったく別の層がいて、そいつらに英語は全く必要ないしこれから先の何年も求められずにやっていくだろうっていうこと。
悲しい愚痴、以上。
この記事を読んだ。
http://anond.hatelabo.jp/20160619185731
元COBOLエンジニア、現Rubyエンジニアとして増田の記事がどうしても許せなかったので反応してみる。
この記事もこんなタイトルだけど、これもやっぱり主語が大きいと思う。
汎用系の現場でもRubyの現場でも優秀な人はたくさんいたし。
今では信じられないほどの経験を当時（といっても2年前）はしていた。
改めて今、RubyというかRailsを始めてよかったなーと思う。
いやー、これが一番ひどかったな。
まず静的デバッグ（机上デバッグ）といってコンペアファイル、ソースコード、コンパイルログをそれぞれ紙出しして提出用（クライアント）、リーダー、上司用の3部印刷する。
全てマーカーを塗った後に赤入れする為にそれぞれ分けるんだ。
そしてインデントもレビュー指摘項目なんだけど、紙出しされたもののインデントが正しいかチェックするんだよ。
定規で計るんだよ。半角スペースが5ミリだったっけな。
それで5ミリずれてたら指摘するんだよ。目がつかれたよね。
っていうか品質に対する意識は今のほうがよっぽど高いし効率的だよ。
これもびっくりだよね。
専属の社員がいた。SIerなんて人を突っ込んだもの勝ちだから、上手いこと言って検証要員とかいって突っ込んだんだろうね。
ダンプがだいたい1時間くらいかけて出てくるから、それを裁断してホッチキス留めしてマーカー。
ネットは使えない。現場に入る時も持ち物チェックとかあるしな。
常に貸し出し台帳は予約で埋まっていたな。やっと借りれたのは現場離れる1週間前だったなんてこともあった。
まだまだあるんだけど、これだけでもひどい現場だったなーって思う。
そもそも設計→開発→レビュー→手戻り→設計→開発...のループだったから前に進めてないし。
Gemとか外部のコードを信じきるとか、もちろん質の低いRubyエンジニアというか現場はあると思う。
この先もっともっとブラックボックスなフレームワークを使うようになるかもしれないし、環境も何もかも全部おまかせでPaaSが主流になるかもしれない。
http://b.hatena.ne.jp/entry/s/medium.com/mediumjp/2b0da4969e65
だいたいはここらへんのコメント
id:koiz アメリカでは、光を思いっきり入れたクリエイティブが求められることが多い(特に西海岸だし、スイムウェアは)。自分のセンスで左の方がいい！この写真家はクソ！ってなる人がrawデータを貰いたがるタイプなのだと予想
id:Memeo このレタッチ写真屋が勝手にやったんじゃなくて用途やデザイン案に従って仕上げたもんなんじゃない？/ カレー作って今からルー入れようって時に「もうそれでいいから食わせろ」と言われても困るだろう。
で言い表されてると思ったんだけど、スターを集めてるブコメでは誤解が解けてないようなので。
まず、カメラマンの仕事を理解していないひとが多い。カメラマンは写真家と違って、クライアントの要求にあった写真を撮るのが仕事なんだよね。「フレアがわざとらしい」とか「レタッチ前の写真のほうが好き」と言っている人は、カメラマンじゃなくてクライアントのセンスに文句をつけている。
次に、本文でも親切に「レタッチを前提として撮っている」と書いてあるように、レタッチは下手な写真をごまかす手段としてではなく、クライアントの望む理想的な写真を作り出す手段として使っている。「RAW現像を前提としてあえて暗めに撮っておき、現像時に明るくすることで暗部の階調を残す」というようなテクニックは常套手段。なのでレタッチ前の写真が下手という指摘は外れているし、そういう誤解があるからこそ元データを納品したくないんだよ。
元記事はカメラマンの立場からRAWデータを渡せない理由を説明し、それでもクライアントの不利益が少ないことを説明して理解を求める内容。「RAWデータは作りかけのもの。自分の名前で世に出したくはない」「そのことでクライアントに不利益が生じないようきっちりと仕事をしているので、理解してほしい」「しかしカメラマン側も事前に契約を詰めるなどの取り組みは必要」という流れ。その流れを踏まえてブコメを読むと、とんちんかんなブコメがかなり多いことがわかる。
いわゆる写真の加工に対して、アレルギーを持った人が多いんだろうなと再認識させられた。身の回りにある写真はほとんどが加工済みだし、iPhoneで撮った写真でさえ元から強烈な補正がかかってる。ここまで写真が身近になった今だからこそ、写真の現像やレタッチについてカメラマンからも発信していかなければならないと思った。
id:toksato 結局なんでレタッチ前の写真を渡さないのかよくわからなかった。
本文中に"レタッチが終わるまでは、自信を持って「自分の作品です」とクレジットを付ける気にはなりません。"って書いてある。
ただ、元記事は「レタッチ前データを渡したくない理由」「レタッチ前データを渡す必要が無い理由」「同業カメラマンへの提言」がまぜこぜに書かれていて、主旨が読み取りづらいとは思う。
id:Akamemori お前それフィルムカメラでも同じ事言えんの？
ブコメで多数指摘されてるけど、銀塩時代も加工の技術はあった。現像やプリントの段階で、色味やコントラスト、シャープネス、粒状性は変えられるし、覆い焼きで部分的な明るさを変えることもできる。デジタルで幅が広がったのは確かだけど。
id:atoh 契約時にきちんと詰めろってだけの話だった。
id:aromabird 契約次第としか。中間制作物も納品義務のある契約なら納めるし、無ければしない。別料金。ただそれだけ。
本文で"撮影の前には、契約が成立しています。""これは、プロのカメラマンである以上、事前にしっかりと内容を詰める責任があります。"ときっちり書いてある。このコメントに星が集まってるのが理解不能なんだけど、みんな本文最後まで読んでないの？
id:nasuhiko レタッチっていうかほぼRAW現像の話だろこれ。翻訳者がわかってないのか、それらも含めて原文がレタッチって言ってるのか。プロでさえ1枚のベストショットの背後に何十何百という失敗ショットがあるのは同意。
海外の"retouch"は現像も含めた写真の加工全体を指す。"no retouching"なら、撮影後いっさい手を加えていない写真のこと。
id:kazoo_oo 追記でぐだぐだと契約だなんだ言い訳してるけど、前段ではそのrawファイルが自分より優れた現像者に出会う可能性を潰すことの理由を説明できてないよね。 </bockquote>
これは文章の読み取り方の問題。自分よりも優れた現像者に出会う可能性は潰しきれないが、カメラマン側の能力で相当小さくしている。カメラマンの被る不利益との天秤で、原則RAWデータを渡すことはできない。ただし信頼関係や契約次第で対応することはできるというのが本文の論。
IT業界でクライアントが「あとで使うから作ったソースコードや旧バージョン全部ちょうだい」って言ったら普通に断られると思うんだけど、それと同じ話。
id:jassmaz jpegだけ送られてきたらキレるわ。rawファイルもいらない。psd ＋ pngを送るのが常識では？
psd＋pngが常識というのには同意。その上で、クライアントが求めるものはまちまちなので、契約をしっかり詰めておきましょうというのが本文の内容。
id:oscdis765 これ右がレタッチ後なんだよね？左のが良いのが沢山あるんだけど
id:mfigure 上手けりゃ、原版渡せとは言われないでしょ。加工後の方が上手いといえない写真が多いんだけど、よく言うわ。
id:kantei3 思いあがっている。あと、左の方が良い写真が多いので、都合のよい例すら選べない低能なんだな、と。
id:paradisemaker いやー、商売が成立してるんならいいけど、元々のカメラの腕が良くないし、レタッチもそれほど上手くない。デジタル時代のカメラマンって感じだなぁ。
この手のコメントが多いのが本当に悲惨。使用イメージが頭にあるクライアントがカメラマンと話しながら詰めた結果、右みたいなタイプの写真が希望にあったというだけ。あなたたちがどっちがいいと思おうがまったく関係ない。仕事で右みたいな写真が好まれがちだからこそ、private workもそういう味付けにしてポートフォリオとして公開しているんだろう。
「デジタル時代のカメラマン」ってのがよくわからない。フイルム時代、大多数の人が見ていた写真は加工の入ったプリントと、よくて現像済みのネガぐらいで、RAWデータに相当する未現像ネガは見られなかったはずなんだけども。
id:zheyang う～ん、今でも撮影時に設定を絞り込んで、レタッチを最小限にしてる人もいるんじゃないか？／作例のレタッチ（フレア）がわざとらしくてCGくさい。この人の写真家としての腕がちょっと怪しい。
写真家とカメラマンは違う。「写真道」でも極めるならともかく、クライアントの希望に適う写真を納品するという立場において、レタッチを忌避する理由はどこにもない。最高の成果物を納品するためには、「撮影時に設定を絞り込んでレタッチを最小限にする」より「撮影時に設定を絞り込んだうえでレタッチで仕上げる」のほうが良いというだけ。フレアがわざとらしいとか、クライアントに言うべき。
id:xevra くだらんこだわりだ。写真家とカメラマンは違う、カメラマンならとっとと出せ。単に現像スキルに自信がないってだけなんじゃないの？ 面倒臭い奴に発注するのはやめたい。
5000枚の未選別データを欲しいならそうするけど、それには相互の信頼関係が必要だし、契約段階から要求しておいてほしいという話。
id:aceraceae いらないとこ白飛びさせるの好きな人なんだなってことがわかった。
この人の好みもあるかもしれないが、クライアントの希望にもあっているからこそそれで納品されたんよ。あと向こうの雑誌や広告をちょっと見ればわかるけど、こういう派手でやり過ぎっぽい写真はかなり好まれてる。
このブログが、人気だ。
「「京大出て専業主婦なんてもったいない」と言う人は、じゃあわたしが何をすれば許してくれるのか」
http://seramayo.hatenablog.com/entry/2016/05/23/121352
京大を出たが、就職したり、研究者になったりせず、専業主婦になったことに対して、他の人からその行為を「もったいない」と言われたという話だ。
http://anond.hatelabo.jp/20160524012315
一方で、高等教育もコストが掛かるんだよという意見をいう人も居る。
http://anond.hatelabo.jp/20160524045830
それは、「天賦の才能は神から与えられたもので、返す必要がある」という指摘だ。
これはもしかしたら、上のブログでもったいないと言ったという話に繋がるかもしれない。
東大京大に入る程の頭脳は神から与えられた天賦の才能だ。天賦の才能を持つ人は社会にその才能を還元する義務があるのではないかと考えている。例えば、プロスポーツ選手は単に試合をするだけではなく子供にスポーツを教えたりする。それは単に人気取りの為だけではなく、彼らが与えられた天賦の運動能力を社会に還元させるという目的もある。
ハテブの中にノブレス・オブリージュの話が出ていたが、優れた能力を持つものは、より多く社会に貢献すべしという主張に通じるのかも知れない。
京大を出て専業主婦をする人のエントリーに関して感じる違和感は、「天賦の才能」に対する意識の欠如だ。彼女の頭脳は彼女の努力の賜物ではあるが同時に、神から与えられたものでもある。その意識が低いように感じる。
研究者になったり企業人にならず、専業主婦を選ぶことも立派な人生だ。それでも、自分が「天賦の才能」を与えられていることを時々は思い出して、例えば自分の子供だけでなく、貧困層の家庭の子供に勉強を教えるとか、恵まれない人にも何かを教えるとか、与えられた才能を活かす方法を考えてみてほしいな。
ちなみに私は、ソフト開発に天賦の才があったようで、良いソフトウェアが書ける。
だから私は仕事としてのソフトウェア開発だけじゃなくて、休日にgithubにソースコードを上げたり、qiitaにコードを書いて検証した結果を上げたりしている。
自分に優れた能力があると思っているのなら、その能力を自分一人に独占するんじゃなくて、他人や社会に還元する方法を考えてみてはどうだろう。
「ダメなアルゴリズムで書かれたコードは、いくらでも捨てて書き直せる。しかしデータ構造に問題があった場合、プログラム全体の書き直しに発展してしまう」
この話と微妙にカブるようでカブっていないが、言い方だけ真似たものとして
「クソな下請けはいくらでも代わりを探せる。しかし元請けの回し方がダメだったら全員でデスマ確定」
という話もある。これまた開発経験者ならよくご存知だろう。
すなわち、最低でも年収500以上は確実に貰っているであろう、エリート様揃いのITゼネコンの中にも、一握りの、まさに一軍というべきデキる人達と、そうじゃない人達がいると。
そして一軍と二軍以下では、マネージメントにおいて天国と地獄くらいの差が出るのだから恐ろしい。
というかなんでそれだけの年収に見合う学歴がある人達なのに、デキる人が一軍扱いされるほど少数なんだよ、意味わかんねえ。
学歴というのは、努力の仕方、効率の見極め方についての上手い下手の最も分かりやすい数値だと個人的には思っている。
そうなれば当然高学歴は、システム開発という極めつけの頭脳労働で、そのパフォーマンスを遺憾なく発揮し、協力会社含めて皆をハッピーにするのだろう…そう、一軍ならね。って、全員じゃねーのかよ！
具体的にはこうだ。
良い方から説明すると、一軍のマネージメントは要件定義から寸分の隙もない。
顧客の経営戦略に基づいた要望を良く理解し、仕様に取り込んでいることは勿論、システム間通信のような、後でとんでもない話が発覚して色々揉めそうな部分も、既にこの段階において顧客の協力を取り付け、キッチリまとめていたりする。
とにかく裏で細かく調査していたことが見て取れて、仕事したんだね～という感じである。
それから設計に取り掛かるのだが、やはり要件定義の段階で「どうしても見えない部分」はあって、下請け以下が作業の過程で洗い出した結果、それが時にはリスケを招く事故になることがある。
しかし一軍の人らは、本来最後の手段であるリスケにも比較的前向きで、それについての顧客説明もしっかりしているのだろう、大して揉めること無く妥当な落とし所にたどり着くのだ。
また、下請けのグループ(≒サブシステム単位)に必ず1人以上プロパーを配置し、現場感の吸い上げと「同じ釜の飯を食ってる」感の醸成にも抜かりない。
それもあって、現場でよくありがちな「あの人ら(元請け)何も分かってない」という陰口は最小限になる。
強引にまとめるなら、リスクが常に頭にあって、かつその取り方について常に考えを巡らしている。「かもしれない」運転をしつつ、逃げ腰にならない姿勢は見事である。
そして、二軍以下は上述の一軍の振る舞いが全くできない。本当に全部できていないのだ。
要件定義は客の要望を汲み取る所から既に漏れ漏れ、当然後ろの工程で揉めそうな部分は一切見ていない。
設計の大元、ひいてはシステムの大元になる部分がこれだけ不完全だと、その時点でデスマ化・炎上は約束されたようなものである。
その後に起こる事態は、もはやここに詳しく書くまでもない。
穴だらけの要件定義を、場当たり的に客に相談しながら埋めていく作業が設計のお仕事になり、それが相次ぐ仕様変更を呼ぶ。
結果どこまでExcelやソースコードをいじっても作業量が減らない、いやむしろ増える。しかも成果物が増えてくる各フェーズの終わりが近づくほど、「横展開」という名目で作業量が爆発的に増大するのだから始末が悪い。
各成果物を直しきれず「修正漏れ」という事故を仕込むことも頻発し、それに伴い品質も凄まじい勢いで低下する。
それでもケツは絶対に動かない。それどころか人員の追加すら出来ない元請けもいる。お前ら見積もりドンブリ過ぎだろ。
現場では脱落者が日常的に出る。でも下請けチームにプロパーが1人もおらず、そうした危機的な現場感が上に届かない。それも合わさって「あの人ら何も分かってない」という愚痴が漏れ聞こえるようになるのだ。
こんな体たらくじゃテストに漕ぎ着けるなんて夢のまた夢だし、仮にどうにか辿り着いても、何がどう動けばいいの？ってレベルでグダグダだったり。
いやもう、マジで元請けの人らは何やってんの？という感じ。優秀な人が何十人もいるのに機能していないとか、なんでそんなことになるんだか。
（※一部記法 [ ＞＜｜ ] は変換されてしまうため全角にしてあります）
| 記法名 | 書式 | 機能 |
|---|---|---|
| 見出し記法 | *～～ | 日記に見出し（h3）を付けます |
| 時刻付き見出し記法 | *t*～～, *t+1*～～ | 見出しに編集時刻を保存し表示します |
| name属性付き見出し記法 | *name*～～ | 見出しに好きな name 属性をつけます |
| カテゴリー記法 | *[～～]～～ | 日記にカテゴリーを設定します |
| 小見出し記法 | **～～ | 日記に小見出し（h4）をつけます |
| 小々見出し記法 | ***～～ | 日記に小々見出し記法（h5）をつけます |
| リスト記法 | -～～, --～～, +～～, ++～～ | リスト（li）を簡単に記述します |
| 定義リスト記法 | :～～:～～ | 定義リスト（dt）を簡単に記述します |
| 表組み記法 | ｜ ～～ ｜ ～～ ｜, ｜*～～ ｜ ～～ ｜ | 表組み（table）を簡単に記述します |
| 引用記法 | ＞＞ ～～ ＜＜ | 引用ブロック（blockquote）を簡単に記述します |
| pre記法 | ＞｜ ～～ ｜＜ | 整形したテキストをそのまま表示します（pre） |
| スーパーpre記法 | ＞｜｜ ～～ ｜｜＜ | 整形したHTMLなどのソースをそのまま表示します（pre） |
| スーパーpre記法（シンタックス・ハイライト） | ＞｜ファイルタイプ｜ ～～ ｜｜＜ ＞｜??｜ ～～ ｜｜＜ | 整形したプログラムのソースコードを色付けして表示します（pre） |
| aa記法 | ＞｜aa｜ ～～ ｜｜＜ | アスキーアートを簡単にきれいに表示します |
| 脚注記法 | (( ～～ )) | 日記に脚注を設定します |
| 続きを読む記法 | ==== | 次の見出しまでその後の日記を「続きを読む」にします |
| スーパー続きを読む記法 | ===== | 見出しも含めてその後の内容を「続きを読む」にします |
| 改行記法 | (連続した空白の行2つ) | 改行（br）を挿入します |
| pタグ停止記法 | ＞＜ ～～ ＞＜ | 自動挿入される p タグを停止します |
| tex記法 | ［tex:～～］ | mimeTeX を使って数式を表示します |
| ウクレレ記法 | [uke:～～] | ウクレレのコード譜を表示します |
| 記法名 | 書式 | 機能 |
|---|---|---|
| http記法 | http://～～、[http://～～:title]、[http://～～:barcode]、[http://～～:image] | URLへの始まるリンクを簡単に記述します |
| mailto記法 | mailto:～～ | メールアドレスへのリンクを簡単に記述します |
| niconico記法 | [niconico:sm*******] | ニコニコ動画の再生プレーヤーを表示します |
| google記法 | google:～～、google:image:～～、google:news:～～ | Google の検索結果にリンクします |
| map記法 | map:x～～y～～(:map)、map:～～、map:t:～～ | Googleマップを表示し、リンクします |
| amazon記法 | [amazon:～～] | Amazon の検索結果にリンクします |
| wikipedia記法 | [wikipedia:～～] | Wikipediaの記事にリンクします |
| 自動リンク停止記法 | はてな記法 | はてな記法による自動リンクを停止します |
| ヘルプ | 書式 | 機能 |
|---|---|---|
| 「*」や「-」をそのまま行頭に表示する | （行頭に半角の空白をつける） | 行頭で「*」や「-」などをそのまま表示します |
| 下書き記法 | ＜!-- ～～ --＞ | HTMLソースにも表示されない下書き日記を記述します |
http://kenokabe-techwriting.blogspot.jp/2016/05/frp_18.html
残りは全部、使ってるライブラリのソースコードからfrequencyやリフレッシュレートやら、timerの解像度っぽいことをアピールしてるみたいですが、
タイマーの解像度設定しながらマウスイベントを同時にとってなんかやることと、
状態f(0),f(1),f(2),…を得る、という本来のFRPの基本原理
ってまったく違うでしょ？
誤魔化すなと。
状態f(0),f(1),f(2),…を得る
というのはどこだ？とけなされているのだけど、
イベントごとに写像されているのだから、状態f(t)だ、とかいうのなら、
岡部氏の言う時間軸をストリームにする、という話と関係ないのに、
ただ「実際のシステム時刻t=0,1,2,…」って言いたかっただけちゃうんか？ってのは見るものすべてにバレてる誤魔化しだ、って意味でしょ？
http://kenokabe-techwriting.blogspot.jp/2016/05/frp_18.html
残りは全部、使ってるライブラリのソースコードからfrequencyやリフレッシュレートやら、timerの解像度っぽいことをアピールしてるみたいですが、
タイマーの解像度設定しながらマウスイベントを同時にとってなんかやることと、
状態f(0),f(1),f(2),…を得る、という本来のFRPの基本原理
ってまったく違うでしょ？
誤魔化すなと。
状態f(0),f(1),f(2),…を得る
というのはどこだ？とけなされているのだけど、
イベントごとに写像されているのだから、状態f(t)だ、とかいうのなら、
岡部氏の言う時間軸をストリームにする、という話と関係ないのに、
ただ「実際のシステム時刻t=0,1,2,…」って言いたかっただけちゃうんか？ってのは見るものすべてにバレてる誤魔化しだ、って意味でしょ？
### はじめに
私はエンジニアです。お仕事でエンジンを制御するソフトウェアを作るからです。
えっ、おまえらエンジン制御してないのにエンジニア名乗ってんの？？？ なんで？？？
エンジンって聞いて多くの人が一番に思い浮かべるのは、車のエンジンだよね。ガソリンエンジンかディーゼルエンジンかの違いはあるかもしれないけれど、車のエンジンだよね。Googleで「エンジン」って画像検索したら、たくさんの車のエンジンの画像が上位に上がったから、この認識に間違いはないはず。
### つぎに
でも、時々思うんだ。もしかして間違っているのは私の方なんじゃないかって。だって、エンジンを扱っていない自称エンジニアの人から仕事の話を聞くと、私がしている仕事と全然違うんだ。
え？ なんで？ ソースコードの確からしさを検証するために、蛍光ペンで詳細設計書とソースコードを塗りつぶす作業やらないの？ 塗りつぶしで品質を上げるんだよ！！！
え？ なんで？ モジュールテストとかやってるの？ モジュールテストは外注するものでしょ？ テストは外注するから、仕事でモジュールテストなんて一回もやったことないよ。モジュールテストやったことないけどソースコード書くよ。品質は大丈夫。蛍光ペンでチェックしてるから。
え？ なんで？ 仕事が楽しい？ 達成感を得てやりがいをかんじる？ 変なの。仕事は仕事でしょ。仕事が楽しいなんておかしいよ。仕事をいくらしてもつらいことばかり、楽しいことがそれを上回ることなんてないと思うんだ。私より仕事ができないくせに高給貰ってる人や、CIAのスパイのように仕事を全力で妨害する人がいる。楽しいわけないじゃん。まあ、仕方ないとは思うけれど。年功序列って制度があるからね。
え？ なんで？ それならお前のスキルを評価してくれる会社に転職したらいいじゃないかって？ そんなに自信ががあるなら、あるいは誇れるようなスキルを持っているなら、とっくのとうに転職してるっつうの。鬱になんかならないっつうの。
### そのつぎに
え？ なんで？ なんでそんな目で私の事を見るの？ 別に、そんなことないよ。ちょっと私のメンタルが他の人より弱いだけだよ。普通だよ。最近のニンゲンはストレスに弱いんだよ。暴飲暴食で体重が増えたり、会社のことを考えると憂鬱になって涙が出てきたり、会社で上司や同僚の前で5、6回泣きわめいたり、苛々して髪の毛抜いちゃって禿げたり、首をつろうとしてストッキングで締めてみたはいいもののやっぱり怖くなってやめたり、鬱で2回休職したり、ね。それくらい、みんなもやってるでしょ。私は普通だよ。ふつうふつう。ちょうふつう。おかしいのは貴方でわたしはなにもおかしくないまちがってないｋら・
### おわりに
本当のところ私は、エンジン制御しているいないのに関わらず胸を張ってエンジニア名乗れる人が羨ましい。妬ましい。そういう人たちのようになりたいと思っている。
自分の持つ技術に誇りを持っている人。常に学び続ける人。劣等感に苛まれない人。仕事に楽しさを見出している人。将来に希望を感じている人。明確な生きる理由もなく生きられる人。そういう人たちのようになりたい。
さらに言うなら、そう考えられているうちに死んでしまいたいと思う。私より仕事ができない高給取りの奴のマネをしよう、なんて考えるようになってしまう自分の未来が怖いんだ。
そろいもそろってクズ
能力が低いくせに自信だけは一人前で自分の言い分が通るまでは喧嘩腰。
たとえば「私はプログラムのソースコードは読まないよ！だから全行にコメントいれて！コメント入れるのは当たり前の事だよ。私はソースコードを読むときにコメントを英文よ読むように読んで理解から全行にコメントいれて！」
みたいなよくわからん要求を押し通してくる。(ソース読めない人がプログラマか？あほかと)
これやらないとそれを言い訳に文句をいってそもそも仕事してくれない。
SingletonもしらないMVCもしらないJenkinsもしらないコマンドラインもろくに使えない、そんな状態で私はソフトウェア工学を学んだプロみたいな言い方をしてくる。
その自信のせいか人の意見は聞かない。
仕事は終わらせないで帰る、昼飯は二時間戻ってこない、そもそも会社でYoutubeばっかり、ミーティングはずっとスマホいじってて話を聞けと言っても「きいてるよー。私はマルチタスクだから両方できる」などといってミーティングが終わったらさっきは何の話だったの？と聞いてくる始末。
そして浮気！仕事には関係ないからどうでもいいけど、結婚してるのに出会い系サイトで出会った女の子に片っ端からあって遊んでる。そして写真にとってそれをいつも自慢してくる
私はチームにいる誰よりも女の子を抱いた事あるよ！なんて自慢してくる
しるか、しね
二人目、
企画者がもってきた仕事にめっちゃ切れて文句いって仕事しない。
ミーティングしても「いつまでこんなミーティングつづけるんですか！！！！」みたいに
ソースコードの問題をみんなで指摘しても「これはこうじゃないとダメなんです！！！」みたいに
基本自分が正義で自分の意見に反論してくる奴はみとめないのがフランス人
しね
三人目、
四人目、
社員旅行にいったのに飽きたのか途中で誰も言わずに一人で帰ってくる
みんないなくなって大慌て
旅行が終わっていきなり新幹線の切符もってきて開口一番「先に帰ってきたからこれ清算して！」
しね
五人目、
昼頃会社に出社してくる、PCをたちあげるなりおもむろにゲームを開く
夕方までそのまま
そして帰る
あとのフランス人はしらない
ただでさえ働かないのに本当赤ちゃんをあやすかのごとく機嫌を取ってあげないとダメ
フランスはこんな奴らばかりでどうやって経済なりたたせてるんだ？
クズすぎだろ
まぁそんなやつらを見抜けず採用してるうちの会社がダメなだけか。フランス人以外は外れ少ないんだけどなー
言いたい事はやまほどあるが面倒になってきたのでこれくらいで
http://anond.hatelabo.jp/20160413023627 を見て触発されたので書く。
タイトルのようなことについて、実態というか現実というか、そういうのを当たり障りない範囲で書こうと思う。全ての企業や学生に当てはまるはずはない（むしろかなり偏見や単純化を混ぜてる）けど、参考になれば幸い。
ちなみにトラバ先は研究を志望したという話だけど、本エントリは研究志望というよりは一エンジニア志望向けかも。
あえて定義はしないけど、Github で公開されてるような OSS を使ってます/いじってますとか、LL 使って Web アプリ作ってますとか、アジャイルやらテストコードやら最近主流の手法使ってますとか、そんな感じで捉えていただければ幸い。あるいはメインフレームで COBOL とか周辺機能を全部車輪の再発明してるC言語製アプリとかそういう古い仕事ではない仕事、と捉えてもいいかも。
トラバ先のトラバの言葉を借りると「日本的な旧来型のIT大企業」という感じ。
ITという言葉には色々な意味がある。大手IT企業だとこれが特に広い。もちろん「モダンな開発」も含まれているけれど、そんなの全体のごく一部でしかない。（主観だけど数 % とかじゃないだろうか）
話は少しそれるが、大手IT企業は元々メインフレームなど「化石」で発展してきた経緯がある。何十年以上も昔、コンピュータといえば化石しかなくて（それでも当時は最先端）、それを個人やそこいらの企業では相手にできないような大組織に対して導入してきた。プログラミングの手法やノウハウが十分存在しない時代だったけど、それでもやるしかなくて、幸いにも昔は今ほど不景気ではなかったし人材も豊富だったから人海戦術で何とかなった。
そうやってつくられた化石コードと化石システムは今なお動いているし、時代に合わせてそれなりに機能追加もある。大手IT企業は化石から離れることができない。現代が化石で食べていけるほど甘くない時代だとしても。
そもそも化石に詳しい化石人が現役引退や昇進などによりいなくなったということもあって、実は現状維持ですら大変である。たとえばレガシーで汚い膨大なソースコードを知る者は誰もいない。もちろんネットで調べても答えなど出ないし、IT界隈のコミュニティに頼ったところで知る者はやはりいない。どんなに時間がかかっても読んで、理解するしかない。どんなに時間がかかっても。
以上のような現実があるので、化石のお仕事に新人を割り当てることも普通にあるし、むしろそうなる確率が圧倒的に高い。
大手IT企業にとって新人とは「専門的な技能や経験は無いが、地力(頭の良さ、伸びしろ、根気など)はあるため近い将来使える戦力になる卵」である。
対人コミュニケーションには自信ありますという遊んでばっかのリア充も、OSS に Contribute してました大学はほとんどパソコンと向き合ってましたという趣味グラマも、同じ「新人」でしかない。
「新人」は技能も経験もないので、いきなり一人前の仕事を任されることはない。電話応対、飲み会の企画運営など雑用全般を任されつつ、簡単な仕事がアサインされる。
この簡単な仕事というのが曲者で、手順書にしたがって環境を整えるとかテストをするとか、そういう仕事だ。手順書を読める程度のIT知識があれば誰でもできる。でもボリュームは多いし、手順書は不完全で不正確だからわからないところが多々あって、忙しい先輩や上司に何度も相談しにいくことになる。言うなれば「属人性の高い単調な手作業仕事」とでも言えようか。
ITを知らない素人新人ならこれが仕事だと抵抗なく受け入れられるが、ITを知る新人だったら、これはとてつもない苦痛だろう。配属先が「モダンな開発」を行う部署であれば苦痛具合も軽減されるし、なんなら「君結構詳しいんだね。じゃあ早速本格的な仕事任せてみようかな」なんてこともありえる。化石部署だとそんなことはない。だって、仕事で扱ってるシステムは化石だからモダンなIT知識なんて役に立たないもの。
この「新人」に、早くて数ヶ月、遅くて数年耐えると、次第に仕事を任せてもらえるようになる。設計やコーディングといった、エンジニアらしい仕事だ。といっても、配属先が化石部署であれば、当然扱うのも化石なわけで、いつまでたっても化石で苦しみ続けることになる。
一方で化石部署から異動し、「モダンな開発」を行う部署で働く者も存在する。これには色んなパターンがあるが、おおよそ以下のような状況が重なって異動するパターンが多い気がする。
大手IT企業では エンジニア→中間管理職(部長以下)→偉い人(部長より上) というキャリアパスがつくられている。特徴は
こんな感じ。
いつまでもエンジニアとして働いて、でも給料はそれなりにもらって、ということはありえない。成果を出せば昇進するし、昇進すればエンジニアから離れていく。成果を出さなければエンジニアとしていれるけど、いつまでたっても給料は増えない。大手だけあって新人時点での給料はそこそこ良いけれど、30代以上になってくるとそれでも苦しい(物欲無き健康的一人暮らしなら問題無いが、家族を養うつもりなら相当苦しい)し、そもそも無能な管理職に振り回されることに対して苛立つだろう。つまりエンジニアとして何十年も働き続けにくい。
「昇進するつもりだから問題無し」と考えている人も要注意である。というのも、大手IT企業は管理職で溢れかえっているからだ。新人が昇進するのは非常に難しい。昔は割と誰でもなれていたし、実際「こんな奴がなんで管理職になれてんだ？」っておっさんもたくさんいるけれど、今は違う。一握りの社畜（必死に仕事に食らいついてきた＆先輩や上司からのウケも良い）だけが昇進できる。たとえエンジニアとして優秀な仕事をし、正当な意見を主張してきたとしても、空気を読んでウケの良い社畜にならなければ昇進はできないのである。
大手IT企業の研究所は非常に狭き門である。トラバ先でも言及されているが、博士課程を終えたようなガチさに加え、当然のことながら学歴も必要になってくる。実際、研究所の人間は英語を当たり前に読み書きできたり、分厚い技術書を躊躇なく読み込んだりするような変態であり、裏を返せばそれほどの実力と熱意がなければやっていけない世界というわけで。とにかく多少ITに覚えのある凡人が入れる場所ではない。
また、入社後に研究所に異動するケースもほとんど無い。一般部署の凡人をわざわざ引き入れる理由が無いからだ。
ここまで色々書いたが、そもそもなぜ大手IT企業を目指すのか。それは以下のような理由や期待があるからではないか。
確かに上記のメリットはある。あるけれど、ここまで書いたように
といったこともあるわけで。
「モダンな仕事をバリバリしたいならベンチャー行け」という話もあるけれど、ベンチャーで通用するほどの人材ならそもそも大企業を選ぶことに悩みなどしないだろう。大企業を選ぶということは、実力なり待遇なり何かを求めているわけで、そうなってくると大企業以上に適切な選択肢は無い。でも、その大企業にも上記のデメリットがあるわけで。
世の中は甘くないですね。
perlだからソースコードを保守できる年齢層が絞られる。なので若い人の意見など聞き入れられる現場ではないだろう。
ログイン履歴とか1997年ごろの携帯の出会い系サイトで使われていた機能なんだよね。
ああQiitaに出没してるスパゲッティコードと気炎吐くだけの駱駝さんね・・・
timeengineのソースコードはそのサイトにあるように200行以下にまとめられている簡潔なコードだけど、どこがどうスパゲッティになってるのか「おまえが理解できない」という以外のきちんとした理由でどうぞ？まあリファクタリングしろっつってもOCamlしか書けないんだろうし土台無理だろうけど。「お絵かきロジック」にするためには、マウスイベントとTimeengineそのまま接続したら良い、超簡単のはライブラリの特性として見りゃわかるが、それすら理解できないやつが何いってんだよｗ
バージョン管理について確認したら定期的にバックアップ（※日付フォルダにコピーすること）は行っているとの回答を得た。
SIerってだけで色々噂は聞くから覚悟はしてたけど予想以上だぞこれマジどういう事だよ怖すぎ。
案の定衝突するわデグレするわ修正した箇所上書きされて消し飛ぶわ……
この前なんか編集したファイルだけ納品したいから編集したファイル全部教えろって言われたんだけど。
俺の感覚だとギャグだとしか思えないんだけど大マジっぽいし。こういうもんなの？
さっさと次探すか、環境を良くするために頑張るか、給与は悪くないので何もかも諦めて受け入れるかどれにしようかな……。
