  |
はてなキーワード: Jenkinsとは
この程度でも600万は稼げるという夢を持つか、こんなのでもちょっと何かが違うだけで600万稼げるか否かが分かれてしまう業界に闇を感じるか、600万程度で何ドヤってるの？と思うかはご自由にどうぞ（外資系ってもっと稼げるの？）。
歳は30台前半。学部卒。BtoB向けのパッケージ製品の開発プロジェクトで、設計、コーディング、テストあたりを担当している。仕様について発注元との折衝もやっている。
業務で使う技術のうち、自分自身がそれなりに習得しているものだけを書く。プライベートでしか習得・使用していない技術は別。
以上。
PythonもgitもDockerもkubernetesもAnsibleもCIツールもAWSもGCPもRuby on Railsも知らなくてもなんとかなってしまっている。業務でこれらのスキルを要求されることは（今のところは）ないから。
楽でいいと思う一方、このままだと将来ヤバいとも思っている。いざ転職となったときに詰みそう。
でもいざとなったらググっていくらでも独学できるだろうとたかをくくっているので焦ってはいない。
というか「その他」のところに書いた能力が高ければ世の中大体はなんとかなるんじゃないの。知らんけど。
ちなみに自分は構築できないというだけで、プロジェクトではJenkinsとかgradleとかbabelだかwebpackだかでビルド環境は整えられている。
あとプライベートで、単純な仕様の独自言語のコンパイラフロントエンドをC++とLLVMで作っている（これで金が稼げるとは微塵も思っておらず、完全にただの趣味）。
世界中の現場をまわっているエンジニアが、ある案件の一本道を歩いていると、一人の男が道の脇で難しい顔をしてJenkinsの設定をしていた。エンジニアはその男のそばに立ち止まって、
「ここでいったい何をしているのですか？」
と尋ねた。
「何って、見ればわかるだろう。Jenkinsの設定に決まっているだろ。朝から晩まで、俺はここでJenkinsの設定をしなきゃいけないのさ。あんた達にはわからないだろうけど、暑い日も寒い日も、風の強い日も、日がな一日Jenkinsの設定さ。腰は痛くなるし、手はこのとおり」
「なんで、こんなことばかりしなければならないのか、まったくついてないね。何が悲しくて自分たちの仕事を奪うようなことを進んでやらないといけないのか・・・」
もう少し歩くと、一生懸命Jenkinsを積んでいる別の男に出会った。先ほどの男のように、辛そうには見えなかった。エンジニアは尋ねた。
「ここでいったい何をしているのですか？」
「俺はね、ここで大きなサービスを作っているんだよ。これが俺の仕事でね。」
「大変ですね」
「なんてことはないよ。この仕事のおかげでサービスは、一日に5回でも10回でもリリースできるんだ。大変だなんていっていたら、バチがあたるよ」
また、もう少し歩くと、別の男が活き活きと楽しそうにJenkinsの設定をしているのに出くわした。
「ここでいったい何をしているのですか？」
エンジニアは興味深く尋ねた。
「ああ、俺達のことかい？俺たちは、歴史に残る偉大なサービスを造っているんだ！」
「大変ですね」
「とんでもない。このサービスは作って終わりじゃない。みんなに使われながらどんどん良くなっていくんだぜ！素晴らしいだろう！」
サーバーを何台も使える環境ではなく、SharePointをファイルサーバーとしてしか利用できない環境。
エクセルでプロジェクトのスケジュール管理し、オシロのデータからグラフを描いて、パワポで打ち合わせ用の資料作成。
自由にパソコンにソフトもインストールできない。クラウドの利用も出来ない。
RPA（Robotic Process Automation）やBIツールなんて単語も知れ渡っていない。
サーバーを自由に立てられないので、Jenkinsも実行できない。
サーバー関係はどんどん自動化が進んでいるが、自分の仕事の効率がよくならない。
事あるごとにだんまりするパソコンを使い続けている人って本当にすごい。
USB接続はセキュリティ的にどうのこうのって言うけど、多少手間が掛かっても好きなの使わせてよ。買ってくれとはいわないから。
自分は最低でも３つは欲しい。こういう仕事してればウィンドウだらけになるじゃん。
机が広いってだけで効率と気分が良くなる気がする。というかディスプレイが置けない。
後ろを誰かが通るとき、逐一すみませんって通路を開けなくちゃいけないのつらい。
腰がつらい。
アクティベートしないまま使わせるのは百歩譲るとしても、ヤフオクとか怪しいところからマイクロソフトやアドビのライセンス仕入れて使わせるのってどうなんだ。
そういう思考回路の人間は、バレないからとか、まわりもやってるとかいう免罪符を盾に、法律や倫理も破っていいとか考えていそう。特に労働基準法的なやつ。
JetBrainsのIDEを使うのに骨折って交渉するところからはじめたくない。
めんどい。上掲した項目を実現するのに、対費用効果がどうのこうの・・・って。誰が得するんだよ。
ベンダーの資格とか高いけどさ、業務に関係するのなら、資格手当が出ないのなら、せめて合格したときは受験料払ってよ。
一般的な感覚で会社負担の費用を個人負担にさせるような会社は嫌い。好きになれない。
高い意識を持って働いてほしいだとか、会社を好きになってほしいとか、そういうこと全く思っていないのだろうか。
あるいはそれが労働者として当然のことで、自然にそうなるとでも思っているのだろうか。
少なくとも自分は苛立ってると普段より頭の回りがそれなりに悪くなる。
残業だってそう、連日遅くまで残って仕事して、それで効率よく質の良いものを作れるとは到底思えない。
240万にも満たない年収で雇ってるんだから、ちゃんとその程度のゴミを雇ってるって自覚持ってほしい。
お金を貰ってるんだからとか、社会人なんだからとか、そんなん言われただけでやる気になるわけねーだろ。むしろやる気なくなる。
この年収の自分が幾らか熱意を持って仕事したり勉強するのは、あくまで自分の個人的な興味や矜恃の問題だから。
というか発注する客側もそう。然るべき時間と費用があってこその質なのだから、短い時間と割安な費用で納品されるのはゴミだと自覚してほしい。
短い時間と割安な費用でも、企業として質の高い製品を納品するのが当然だと思っているのだろうか。まあゴミが納品されるんですけどね。
そういう会社は等しく今すぐ潰れろ
ほどほどが良い。Slackみたいなコミュニケーションツールがあって、気軽に話せるけど、物理的には近すぎないのがいい。
壁を自由に使えると手軽で良いな。
複雑なものをある側面から、誤解なく簡素に表せる、素晴らしい言語なのになぜ使わないのか。
draw.ioみたいな便利なのがあるのに、Excel方眼紙でアクティビティ図に似て非なる謎の図を書き続けるのはなぜなのか。
画面を動かしてみて、できました、このテストおわりです、それで済ませて質が高くなるわけないだろ。
そもそもjenkinsとかcircle ciとか誰も知らない。seleniumとか聞いたこともない。
前もって仕様が確定することなんてどうせないじゃん。いつまでたっても客側にいいように言われて、しっちゃかめっちゃかされるんでしょ。
なら保守されないExcel方眼紙を量産したって仕方がないじゃん。せめてじゃあその辺は最低限にして動くものを作ろうよ。
だからってアジャイルにしようとは絶対にならないだろうけど。。。そういう参加を客側と交渉すること自体ありえないって思ってそうだし。
でもさあ、とりあえず動くものを早い段階から見てもらうくらい良いじゃん。どうせこそこそやると後になって見たいって言われて叩かれるんだから。
話の論点がズレて、何を話したかったのか、何を聞きたかったのかわからなくなる。そして後から言った言わないになる。
あらかじめ資料を用意しとくなり、どこか広いところに書きながら話そうよ。で、できれば書いた人がデータとしてどこかに投げてほしい。そして消しておいてほしい。
訳のわからない造語を使い出したり、意味を分かってないのにその言葉を不用意に使うの止めてほしい。
きっとそういう人って、まずその言葉の意味を理解しようという意志が致命的に欠けているから、会話していて不毛感が凄い。
短い文章で齟齬なく十全な文章を書けることは確かに素晴らしいことだけど、だいたいそんなことは出来ない。
だから多少冗長であるように思えても、細かすぎるように思えても、長く書いてほしい。
つーか、毎度毎度短い謎の書き残しがあって、それの話を聞きに行くのつらいんだよ。わかってくれ。絶対わかってくれないけど。
読んで意味のわからないことって、読んだつもりにだけなってしまって、後で指摘されると読む側が一方的に悪いことにされたりするのつらい。
正直自分の気づかないところなら好きなだけ寝ていてもいいけど、まあ気づくし。
眠い頭でこういう仕事なんて効率よくできるわけないのに。つまり目障り。
興味ないから。前の会社とか、そこでなにしてたとか。知りたきゃこっちから聞くよ。
http://anond.hatelabo.jp/20170126221358
F系子会社。ちょっと前まではF本体にも常駐してた。雑にコメントしてく。
↑これはある。会社や人によってはちゃんとやろうと取り組んでるトコもあるけど、グダグダなのが殆ど。法令違反って認識すら無いやつも結構いたりするから反吐がでるよね。
↑これは現場による。
↑メモリ4GBノートPCがデフォなのは同じ。でも、OSは普通に64bitも指定できるし、デュアルディスプレイがデフォ。
↑普通にGitlab
↑そんな変な規約ない
環境が良いとはお世辞にもいえないが
スーツは堅苦しいが、
判子押すのは面倒だが、
SpringもJenkinsもChefもAWSも使ってるが客には導入してないぜ、
お前と俺じゃ見ている景色が違うな。
ここにはやるべきことが山ほどあるんだよ。
paizaかテメーらは。
エンジニアから見たSIerがクソな理由 - 負け犬プログラマーの歩み
SEという名前を変えて欲しい。それで日本のITの遅れは色々解決する。
http://anond.hatelabo.jp/20161128174152
まったく伝わらんかった。
判子とか、面倒な申請とか、導入障壁は客の都合であって、SIerが始めたことじゃないの。
現場では枯れた技術を好んで導入しているけれど、こっちは研究部門作ってひたすら研究して技術のキャッチアップを続けている。
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超えたら書く。
そろいもそろってクズ
能力が低いくせに自信だけは一人前で自分の言い分が通るまでは喧嘩腰。
たとえば「私はプログラムのソースコードは読まないよ！だから全行にコメントいれて！コメント入れるのは当たり前の事だよ。私はソースコードを読むときにコメントを英文よ読むように読んで理解から全行にコメントいれて！」
みたいなよくわからん要求を押し通してくる。(ソース読めない人がプログラマか？あほかと)
これやらないとそれを言い訳に文句をいってそもそも仕事してくれない。
SingletonもしらないMVCもしらないJenkinsもしらないコマンドラインもろくに使えない、そんな状態で私はソフトウェア工学を学んだプロみたいな言い方をしてくる。
その自信のせいか人の意見は聞かない。
仕事は終わらせないで帰る、昼飯は二時間戻ってこない、そもそも会社でYoutubeばっかり、ミーティングはずっとスマホいじってて話を聞けと言っても「きいてるよー。私はマルチタスクだから両方できる」などといってミーティングが終わったらさっきは何の話だったの？と聞いてくる始末。
そして浮気！仕事には関係ないからどうでもいいけど、結婚してるのに出会い系サイトで出会った女の子に片っ端からあって遊んでる。そして写真にとってそれをいつも自慢してくる
私はチームにいる誰よりも女の子を抱いた事あるよ！なんて自慢してくる
しるか、しね
二人目、
企画者がもってきた仕事にめっちゃ切れて文句いって仕事しない。
ミーティングしても「いつまでこんなミーティングつづけるんですか！！！！」みたいに
ソースコードの問題をみんなで指摘しても「これはこうじゃないとダメなんです！！！」みたいに
基本自分が正義で自分の意見に反論してくる奴はみとめないのがフランス人
しね
三人目、
四人目、
社員旅行にいったのに飽きたのか途中で誰も言わずに一人で帰ってくる
みんないなくなって大慌て
旅行が終わっていきなり新幹線の切符もってきて開口一番「先に帰ってきたからこれ清算して！」
しね
五人目、
昼頃会社に出社してくる、PCをたちあげるなりおもむろにゲームを開く
夕方までそのまま
そして帰る
あとのフランス人はしらない
ただでさえ働かないのに本当赤ちゃんをあやすかのごとく機嫌を取ってあげないとダメ
フランスはこんな奴らばかりでどうやって経済なりたたせてるんだ？
クズすぎだろ
まぁそんなやつらを見抜けず採用してるうちの会社がダメなだけか。フランス人以外は外れ少ないんだけどなー
言いたい事はやまほどあるが面倒になってきたのでこれくらいで
原文：https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread
原題：Apache Commons statement to widespread Java object de-serialisation vulnerability
翻訳日：2015年11月12日（午後にタイトルを日本語にしました）
－－－－
Apache CommonsのJavaオブジェクトのデシリアライゼーション脆弱性に関するステートメント
著者：Bernd Eckenfels（コミッター）, Gary Gregory（Apache Commons副責任者）
AppSecCali2015 でGabriel Lawrence (@gebl) と Chris Frohoff (@frohoff) によって発表された "Marshalling Pickles - how deserializing objects will ruin your day" は、信頼されないソースからシリアル化されたオブジェクトを受け取るときのセキュリティ問題をいくつか明らかにしました。主な発見は、Java オブジェクト・シリアライゼーション（訳注：seriarization／シリアル化／直列化＝ネットワークで送受信できるようにメモリ上のオブジェクトデータをバイト列で吐き出すこと。シリアル化されたJava オブジェクトはRMIなどのリモート通信プロトコルで使用される。）を使用する際に任意のJava関数の実行や操作されたバイトコードの挿入さえもを行う方法の説明です。
Frohoff氏のツールである ysoserial を使って、Foxglove Security社のStephen Breen (@breenmachine) 氏はWebSphereやJBoss、Jenkins、WebLogic、OpenNMSといった様々な製品を調査し、(http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/) に各々の様々な攻撃シナリオを記述しています。
両者の調査活動は、開発者がJavaのオブジェクト・シリアライゼーションに信頼を置きすぎていることを示しています。認証前のシリアル化されていないオブジェクトにも。
Javaにおけるオブジェクトのデシリアライゼーション（訳注：de-serialization／非直列化＝ソフトウェアで扱うことができるように、送受信されたデータを元に戻すこと）が行われるとき、大抵は想定された型にキャストされ、それによって、Javaの厳しい型のシステムが、得られた有効なオブジェクトツリーだけを保証しています。
不幸にも、型のチェックが起こるまでの間に既にプラットホームのコードが生成されて、重要なロジックは実行されてしまっています。そのため、最終的な型がチェックされる前に、開発者のコントロールを離れた多くのコードが様々なオブジェクトの readObject() メソッドを通じて実行されてしまいます。脆弱性のあるアプリケーションのクラスパスから得られるクラスの readObject() メソッドを組み合わせることで、攻撃者は（ローカルのOSのコマンドを実行するRuntime.exec()の呼び出しを含めて）機能を実行することができます。
これに対する最も良い防御は、信頼されていないピア（通信相手）とは複雑なシリアル化プロトコルを使うことを避けることです。ホワイトリストのアプローチ http://www.ibm.com/developerworks/library/se-lookahead/ を実装するように resolveClass をオーバーライドするカスタム版の ObjectInputStream を使うと、影響を制限することができます。しかしながら、これは常にできることではなく、フレームワークやアプリケーションサーバがエンドポイントを提供しているような時にはできません。簡単な修正方法がなく、アプリケーションはクライアント・サーバプロトコルとアーキテクチャを再検討する必要があるため、これはかなり悪いニュースです。
これらのかなり不幸な状況において、エクスプロイトのサンプルが見つかっています。Frohoff氏は、 Groovy ランタイムや Springフレームワーク、 Apache Commons コレクションからのクラスを組み合わせるサンプルのペイロードに gadget chains (ガジェット・チェーン）を見つけています(訳注：provided)。これはこの脆弱性のエクスプロイトのためにより多くのクラスを組み合わせられることは完全に確実なことで、しかし、これらは今日、攻撃者が簡単に得られるチェーンです。
(Twitter画像)https://blogs.apache.org/foundation/mediaresource/ce15e57e-94a4-4d7b-914c-8eb8f026659c
この脆弱性のために利用される(訳注：blamed)ことができない確かな機能を実装するクラスができ、安全性が信用できないコンテキストにおけるシリアル化を利用されないようにするような既知のケースの修正ができたとしても、少なくとも分かったケースだけでも継続的に修正していくことが要求されます。モグラ叩きゲームを始めるだけであるかも知れませんが。実際にはこれは、オリジナルチームが Apache Commons チームに警告が必要だと考えていない理由で、それゆえに比較的、活動開始が遅れました。
Apache Commons チームは InvokerTransformer クラスのでデシリアライゼーションを無効化することによって commons-collection の 3.2 と 4.0 のブランチにおける問題に対処するために、チケット COLLECTION-580(http://svn.apache.org/viewvc/commons/proper/collections/branches/COLLECTIONS_3_2_X/src/java/org/apache/commons/collections/functors/InvokerTransformer.java?r1=1713136&r2=1713307&pathrev=1713307&diff_format=h) を使っています。議論されているやるべきことのアイテムは、変化させる仕組み毎(per-transformer basis)に、プログラマティックに有効にするような機能を提供するかどうかです。
これには前例があります。Oracle と OpenJDK JRE の一部であったり、バイトコードを挿入して実行することを許したりする com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl クラスで、セキュリティマネージャーが定義されているとデシリアライゼーションを拒否します。
これはシステムプロパティ jdk.xml.enableTemplatesImplDeserialization=true とすることで無効にできます。Apache Commons Collection は、本来よりもこの実行モデルは一般化していないため、セキュリティマネージャーの存在と独立したこの機能を無効化することを計画しています。
しかしながら、明確化のために述べておくと、この便利な"ガジェット"は、唯一知られている方法でもなければ、特に未知のものでもありません。そのため、インストールされたものを強化されたバージョンの Apache Commons Collection に置き換えることが、アプリケーションをこの脆弱性に対抗できるようにするわけではありません。
このブログポストのレビューのために Gabriel Lawrence に感謝したいと思います。
Apache Commons Collection は、Java コレクションフレームワークに加えて追加のコレクションクラスを提供する Java ライブラリです。InvokerTransformer はコレクションにあるオブジェクトを（特にリフレクション呼び出しを通じてメソッドを呼び出すことで）変換するために使うことができる Transformer ファンクションインターフェースの実装の一つです。
一般のSallyによる2015年11月10日午前10字15分にポスト | コメント[1]
コメント：
Oracle は Weblogic にセキュリティアラートを発行しています：
※マネージャを多少悪者気味に書いていますが、マネジメントの大変さはわかっているつもりです。
マネージャ「たぶん2週間ぐらいでできますよ！wordpressなら学生のころバイトとかでもよくインストールしてたから楽勝です！」
デザイナ「完全オリジナルのwordpressデザイン2週間か、なんとかなるかな?」
.... 略 ....
上司「あれから2週間だけど、こんなにバグ多すぎじゃリリース無理じゃない？」
マネージャ「違うんですよ！デザイナーが全然テンプレートの使い方覚えてくれないし、あのプログラマ人PHPわからないとか言って仕事中にPHPの本とか読んでるから遅れたんです！たぶん自分だけだったらこんなに時間かなりませんよ。」
デザイナ(「XHTMLになってない！」とか余計な所に口突っ込んできやがって！）
プログラマ(PHPなんて簡単だよとか言ってJavaプロジェクトからコンバートさせたのテメーだろうが！)
原因
マネージャ「このスケジュールなんだけど、テスト期間長過ぎじゃない？」
プログラマ「え、でも機能もこれだけありますし10日程度は妥当かと」
マネージャ「いやいや、画面たったこれだけじゃない、通しのテストなんてみんなでやれば1日ぐらいで終わるでしょ？」
マネージャ「俺がレビューしてるんだからそんなでかいバグ出るわけねえだろ。ナメてんのか」
.... 略 ....
プログラマ「セキュリティ周りのバグもあるので、修正には3日程かかると思いますが」
マネージャ「ふざけんな！テストは今日で終わるスケジュールだろ！」
原因
プログラマ「前のプロジェクトでgitを使って便利だったので、今回のプロジェクトでも使いたいのですが…」
マネージャ「バージョン管理とか使ってるの?あんなの効率悪くなるからやめたほうが良いよ」
マネージャ「前に俺がやってたプロジェクトではフォルダで日付ごとに管理してた。同じ風にすれば大丈夫だろ」
マネージャ「古いフォルダからファイルをコピーすればいいだけだろ。馬鹿か」
.... 略 ....
デザイナ（間違ってファイル上書きしたのは黙っておこう）
プログラマ（ローカルにgitリポジトリあるのは黙っておこう）
原因
マネージャ「何このCodeIgniterっていうの？」
プログラマ「あ、それ最近流行ってるPHPのフレームワークで、URLのルーティングが…」
マネージャ「はぁ！？フレームワークとか使わないと開発できないわけ？これだから最近のゆとりはダメなんだよ。」
プログラマ「でも、便利ですよ？」
マネージャ「俺のプロジェクトではそういう怪しいやつは使わないから。バグがあったらお前責任取れるの？」
.... 略 ....
マネージャ「どう、俺の書いたURLルーティングライブラリすごく便利じゃない?」
マネージャ「あー、それは仕様だからしょうがないよ。mod_rewrite使えば問題無いでしょ？」
プログラマ（他人が再発明した車輪のバグを修正するのって本当に不毛だな…）
原因
とあるプロジェクトをフロントエンジニアとして手伝っていて、2500行程度のそびえ立つクソなJavaScriptの改修を頼まれていた。
git blame しただけで最低でも10人このJSファイルにコードを追加していることがわかった。最初のコミットは2010年の2月ごろだから。最初からいるエンジニアの人に話を聞いてみたらこのJSは20人近い人がいじっているらしい。
別に関わっている人数とかはどうでもいいんだけど、変数名が謎すぎたり、関数の名前と中身の挙動が合っていなかったり、まぁひどいコードで、それを半月ぐらいかけて、個人的な安心感を高めるためにも、最初はheadless testとかcapybaraでテストをもりもり書いて、カバレッジを高めて（期間的に100%にはできなかったけど、C0で70%ぐらい）からリファクタリングしていたら最終的にCoofeeScriptに変換して700行ぐらい（JSで1000行ぐらいかな）になる予定（追加開発があればまだ増えるかも）。消えた部分は使われていない関数とか無駄な処理とかコメントだったかな。
だいたいなんでこんなことになったかっていうと、経営者がアホな要求ばっかり今までドキュメントを用意していなかったりするからそびえ立つクソコードが生まれたという感じ。CoofeeScriptにしたのもある程度書式を固定したかったから。
同時にGithubのPRベースの開発も導入した。俺が入った時には他に3人のフロントエンジニアがいてその人達のコードを見ながらもやってた。その人たちはあんまりプログラマとしての能力が高くなかったのでPRベースでJSの基礎なんかを教えながらやってた。プロジェクトに入ってからは俺はずっとテストの環境を整備していて、今いるプロジェクトメンバーはまだテストをかける状態じゃないから、PR送られてきたらそのブランチに対してテストを追加したコミットをぶん投げるという感じで進めていた。
もちろん、PRだからJenkinsと連携してテストを走らせるようにしたらフロントエンドチーム、3人ともかなり安心感をもって開発をすることができましたとさ。俺はこのプロジェクトとは今月末でさよならだから、俺の仕事はドキュメント書いたりレビューをする文化を根付かせて終わりって感じかなー。
あと、JSのテストとかViewのテストの仕方3年前にくらべるとだいぶ情報が増えてきたし、フロントエンジニア〜な人達もテストに身を委ねてみるといいと思った。
Eclipseがemacsやvimより優れている点を挙げてみよう。
・CVSリポジトリの構成を直接覗ける →redmineとかを使ったほうがいいんじゃないのか
・設定できる警告メッセージの種類が豊富。→警告そんなにいるのか
・復元機能が非常に充実している。 →バージョン管理ソフトがあれば普通だし
CVSのように以前の状態に復元すること、以前の状態の →diffじゃダメか、というかなんでいまどきCVSなの
ソースコードとの比較も容易。CVS(Eclipse標準装備)/Subversionプラグインにもこの機能は存在する。
・プラグインの数が豊富、膨大。 → 数があってもつかえるのは少ない
・プラグイン開発環境もEclipse自体に用意されている。 →開発環境を使って作る程のものでもなく、バッチファイルとかスクリプトでよくね
・ライセンス形態がCPLであり商用利用もしやすい。 →eclipse組み込んで出荷するの？
・上位版にWSADが存在する。 →WSDADってなに、WebSpereの残骸？
・Smalltalkで有名なVisualworksの影響を受けているため、
JUnitプラグイン(Eclipse標準装備)によるテストファースト、リファクタリングの他、eXtreme Programming環境が充実している。→Jenkinsのほうがよくね
・SubclipseプラグインによりSubversionにも対応できる。これはCVSよりも強力！→コマンドラインから実行するsvnコマンドを覚えておくとはターゲットでも動いて便利だよ
・Call Hierarchyプラグイン(Eclipse3.0から標準装備)によりメソッドの呼び出し階層を調べることができる。この機能は強力だ！→スタック見るだけのことじゃないの
・プラグインによってはURLを指定するだけでプラグインの自動ダウンロード、自動インストール、
自動アップデートができるためプラグインのインストールが非常に容易。→勝手に変わったら怖くない
・Eclipse上から直接Tomcat, JBossなどを再起動できるSysdeoプラグイン、JBoss-IDEプラグイン
という強力なプラグインが充実している。→えー、今頃Tomcat
・EclipseUML Omondoプラグインによりクラス図などを書いたり、
UMLによるModel Driven Architecture, リバースエンジニアリング
・RSSリーダープラグイン、MP3プラグイン、All The Newsプラグイン、
など様々なプラグインが充実している。→それ開発ツールじゃなくて携帯でやったほうがよくね
・PHP開発が可能なTruStudioプラグイン、Perl開発が可能なPerl E.P.I.C. プラグイン、
C/C++開発が可能なCDTプラグイン、AspectJ開発が可能なAJDTプラグインなど
他言語プラグインが充実している。→Java以外は所詮おまけだけどね
・そのほかにD言語プラグイン、C#プラグイン、Pythonプラグイン、JavaScriptEditorプラグイン、
CSSプラグイン, HTMLプラグイン, XMLプラグイン、(Jakarta)Velocity UIプラグイン、
Apache Antプラグイン(Eclipse標準装備)、非常に強力なApache Mavenを使うことができるプラグイン、
ゲームができるプラグイン、メーラとしてつかえるプラグイン、Wikiプラグイン、Hibernateプラグイン、
FindBugsプラグイン、CheckStyleプラグイン、Jalopyプラグイン、Sobalipseプラグイン、ソロプログラマープラグイン、
など様々なプラグインが充実している。→それぞれ単機能のソフトのほうが充実してるんじゃないの
どうしてもeclipseというなら止めないけど
