  |
はてなキーワード: jenkinsとは
テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。
GでもCでもUIはまた別
結論としては書かないほうがいいと思った。
そういうこともある
全然小さいというか書くためと変更のコストがクソデカなら何か間違ってる
結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。
まあそれはないだろう
それはデバッグの一環のような
一番よくあるやつ
そこのバランス考えないと
バックエンドのビジネスロジックを担当するがっちり仕様が決まっていて勝手に変更されてはいけないものなんかをやる
悪いね
テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。
例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると
メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。
DIはSOLIDに入ってるくらいで基本だし今時のフレームワークなら普通に使うよね
上にも書いたけどパーツがでかいのでは？って「直感的でない長くて複雑なプログラムになっている」とのことなのでやっぱりでかいんだろう
テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。
要件が固まらない、毎週変わるようなのとか、システムが絡むテストでコストが凄く高いもの、UIのマイナーな変更なんかは書かない方がいいけど
バックエンドのビジネスロジックなど書いた方が絶対にいいものもある
ネット上ではテストコードを書かないのは低レベルな開発者という風潮だ。
10年以上、テストコードを書く開発と書かない開発の両方を経験してきた。
■前提
・テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。
結論としては書かないほうがいいと思った。
・テストを書くためのコストが小さいなんて妄想もいいところだ。クソデカである。
結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。
・100人以上かかわる巨大プロジェクトでも「テストコードを書かなかったので破綻した」、とかはなかった。
・テストコードを書くと実装の見落としが見つかってありがたいことはあった。
・git pushするたびに毎回走っても全くの無意味だった。
・テスト対象が変わるとテストを書き直さないといけないのがサイアクだった。非効率化の極みだ。人生の無駄。
・その次にサイアクだったのは、テストコードの実行が失敗したときテストコードのバグであることが大半であったことだ。
・GUIソフトとテストコードは相性が悪いが、そもそも世の中のソフトウェア開発の大半はGUI開発である。
・テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。
例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると
メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。
テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。
最近は最前線から離れててあんまり追えてないけど、現役のときの2008年くらいから10年くらいの間で、仕事のやり方や設計の考え方が大きく変わったIT技術要素で、いまぱっと思い浮かぶのはこんな感じかな。
分野にもよるし、調査して試作した結果自分の業務には採用しなかった技術とかもある。流行ると思って使えるようになったけど流行らなかった技術を入れるとたぶんもっとある。
あと、新機種が出てOSが新しくなったり、ミドルウェアの新バージョン対応、テスト手法の進化もけっこうカロリー高いけどここには書いてない。
「自分はフロントエンド専門でReactしかやらない」みたいに分野を絞れば大分減るけど、その技術が何年持つかわからないから普通はリスクヘッジのために他の技術も齧らざるを得ないし、バックエンドとかの人と議論するのに結局他分野の知識もそれなりに必要。
NoSQL(memcached, Redis, Cassandra)
クラウドアーキテクチャ、XaaS(AWS, Google Cloud, MicrosoftAzure)
CI/CD(Travis CI, CircleCI, Jenkins)
トランスパイラ(Browserify, webpack, CoffeeScript, TypeScript)
型システム(Rust, TypeScript, Haskell)
オーケストレーション(Ansible, Kubernetes, Terraform)
機械学習(Python, MATLAB, 線形代数等数学知識)
SPA(React, AngularJS, Ember.js, Vue.js)
3Dゲームエンジン(Unreal Engine無償化、Unity5)の他分野への普及
GraphQL
機械学習ライブラリ(Tensorflow, PyTorch, Chainer)
Jupyter Notebook
NFT
・色んなこと満遍なくやりたい
・やべー案件に何年も磔にされたくない
これが多様なサービス、アプリを作ってみたいという話なら高単価SESに行くしかない。
かなりの経験を積んだベテランじゃないと入れない世界で出身学部も見られるから相当に厳しいと思う。
フロントやバックエンド、インフラなどもやってみたいという話なら自社でウェブサービスを運用している上場企業に正社員で入るのがいいだろう。
ただし正社員ということはリリース日には何が何でもサービスインさせる立場になるということでもある。定時退社の社風であっても進捗上がってないなら稼動上げて対応ということは普通にある。
派遣で入ればそういうことは無い。上場企業ならコンプラ厳しいからね。でも数ヶ月程度、長くて数年のスポットになることがほとんどなので長期的にはどうなんだろうな。
ここでは俺の経験を踏まえて「自社でウェブサービスを運用している上場企業に正社員で入る」という前提で話す。
アピールすると良いのは使える言語、インフラの知見、構築と運用の経験。
全部が強い必要は無い。どれか一つが強くて他はまあなんとか程度でいい。逆に言うと全くダメですが一つでもあると厳しい。
使える言語では、C#,Javaを大きめな規模のバックエンドとして使ってるとこが多い反面、対応できる人はフリーにも派遣にもたくさんいるのでちょっと弱い。SIer出身でコード書いてたなら当然できるよね、というレベル。
今ならtypescript(javascript), pythonあたりができてgo あるいは Rust勉強してます、というのがけっこう強い。
分かってると思うが言語が使えるというのは、まっさらなPCを与えられて主要なウェブフレームワークをセットアップしてローカルホストを立てるとこまでを含む。
JavaならSpringboot+gradle+JUnit、PHPならLaravel、pythonならdjango、typescriptならNode+React+knex、あとJestかDreddも入るかな。
インフラ知識では、クラウド、オンプレ両方のメリットデメリットを把握しているとよい。
AWS,Azure,GCP,Oracle Cloudのどれでもいいけど実際に使った経験があるとよい。俺は個人でGCPを契約してkubernetesとVM、LBを使っている。
ネットワークの知識は薄くでも持っていた方がよい。HTTPとかcookieとかセッションとか知りませんCORSって何ですか？レベルでは無理。まあここら辺はウェブサービスを作れば必ずやるので大丈夫だろう。
LetsでSSL証明書を作ってopensslで検証してnginxに適用してHTTPS化ができるならアピールになる。
dockerはもうそろそろ使えて当然のレベルになってきているので必須。実際ウチではdockerが分からない使えない人は面接へ進めないようになっている。
構築と運用では、予算内に収まるような構築と運用、サービスインした後のトラブルシューティングの経験があるとよい。
常にコスト意識を持っていることが必要。クラウドは油断すると100万程度すぐ飛ぶ。コスト意識が無い人を運用担当として採用することは絶対にない。
トラブルシューティングで重視されるのはベンダー対応よりもエンドユーザー対応の方。
サービスを早急に復旧させること、そのためにどういう仕組みが必要なのか、構築するところから語れる知見があるとよい。もちろんそこにもコスト意識は必要。
CI/CD、PrometheusやDatadogによる監視とアラートについて語れるとよい。
CI/CDを扱うということは当然gradle,maven,yarn,シェルスクリプトは書けて使えてwebpack,minify,Jenkinsのコンフィグもできるということである。
どうだろう、かなり雑に書いたが雰囲気は伝わると思う。
あ、git使えないは論外。もし使えないなら今すぐ使えるようになるか諦めるかのどちらかで。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
315あとで/2672users 零細企業買収して売却した話｜reisaikigyou_ma｜note
294あとで/2057users テクニカルライティングの基本 | Naohiro Nakata | SpeakerDeck
277あとで/2169users プログラマの心の健康 | 結城浩
257あとで/1306users GitHubの使い方を学ぶ「GitHub Skills」が無料公開。GitHubを実際に操作してMarkdown、Pages、Pull Requests、マージのコンフリクト解消などを体験 | Publickey
210あとで/1421users 総務省、きょうから「社会人のためのデータサイエンス入門」を無料開講 | Ledge.ai
206あとで/1271users 商用利用OKの音素材、600種以上無料公開 バトルの攻撃音も……「Springin’ Sound Stock」 | ITMedia
204あとで/1565users 「自分を愛するってどうしたらいいの？」──宇多田ヒカルの思考を辿るインタビュー、全文公開。 | VOGUE
189あとで/1536users 商用利用無料、国内のフリーイラスト素材の総まとめ | coliss
165あとで/1222users 著作権フリー素材がスゴすぎ…広重や夢二も全部無料 国立国会図書館の試みに「工作心がムズムズ」「活用しない手はない」｜まいどなニュース
163あとで/1070users わずか数年で400億円も売り上げを伸ばしたカインズ ホームセンターのDXで、まず「顧客戦略」に着手した理由 | 株式会社メンバーズ | logmi
161あとで/1092users わかりやすいシステム構成図の書き方 - Qiita
158あとで/952users 大人の学びパターン・ランゲージ（略称まなパタ）：IPA 独立行政法人 情報処理推進機構
152あとで/974users Webデザインの有料学習サイトが無料化 IllustratorやPhotoshop入門などが見放題 | ITMedia
145あとで/1638users 最近Amazonプライムで観た面白かったけど胸糞悪くて二度と観たくない邦画5選 - kansou
144あとで/704users 書籍「達人が教えるWebパフォーマンスチューニング」はチューニングの考え方を教えてくれる良本 - Gマイナー志向
144あとで/1072users ジョナサン・ハイトが解き明かす「アメリカ社会がこの10年で桁外れにバカになった理由」 | 「現代のバベルの塔」はいかにして建設され、崩されたのか | COURRiER
138あとで/1513users 【ウマすぎ注意報】料理研究家・リュウジさん考案「無限冷やしそうめん」がガチでラーメンより美味かった! | マイナビニュース
133あとで/673users 東京大学深層学習（Deep Learning基礎講座2022）深層学習と自然言語処理 | Hitomi Yanaka | SpeakerDeck
129あとで/980users ドキュメントに固執せよ - gfnweb
128あとで/846users 世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（前編）。DevOps Days Tokyo 2022 | Publickey
127あとで/1632users 結城浩 on Twitter: "質問（簡単に教えてもらおうとする相手にイライラするようになった） あなたのおっしゃる「質問されるとイライラする感じ」はよく理解できますし、同じように感じる人はたいへん多いと思います。（続く） #結城浩に聞いてみよう… https://t.co/CKZMzVzHPN"
126あとで/622users コードを書いていてマネジメントもやるようになっちゃった人へ 背中で語っていた僕が、プロダクトとピープルに向き合うまで | 海老原昂輔 | logmi
124あとで/1032users 「女性同士のマウンティング」に関する研究論文が興味深くView数が少ないのがもったいないレベル 具体的なエピソードもなかなかすごい | Togetter
123あとで/1046users 戦略系コンサルタントがオススメする本(不定期更新）｜とあるコンサルタント｜note
122あとで/885users たった256文字のJavaScriptコードで描かれた街の風景アニメがスゴ過ぎて訳がわからない／解説ページを見てもわからないorz【やじうまの杜】 | 窓の杜
117あとで/924users 私は数学がなぜ苦手なのか？高校生が分析してあみ出した勉強法が効果抜群だった｜高校生新聞オンライン｜高校生活と進路選択を応援するお役立ちメディア
115あとで/701users 「ゲーム制作するなら、これだけは覚えておいたほうがいい」 プログラミングする上で重要な「対数」の考え方 | 安原祐二 | logmi
112あとで/879users 【初心者向け】iPhone3Dスキャンパーフェクトガイド｜iwama｜note
111あとで/524users 次世代Web通信プロトコル「HTTP/3」がついに標準化 ～有志による無償解説本が話題に／PDF形式の電子書籍がGitHubで公開中！ 今後も更新される模様【やじうまの杜】 | 窓の杜
この程度でも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使えば問題無いでしょ？」
プログラマ（他人が再発明した車輪のバグを修正するのって本当に不毛だな…）
原因
