「ライブラリ」を含む日記 RSS

はてなキーワード: ライブラリとは

2016-11-28

金融SIer仕事について書きたい

今日SIerについての話題が目について、実情について書いてみたくなったので書いてみる。初めて増田投稿するので少し緊張している。

自分は誰かというと、金融ユーザー子会社に勤めているSEだ。いわゆる1次受け。社員は数千人おり、2chのユー子ランキングではやや上の方に属している。

SIerとひとくくりにして主語を広げたくないので、あくまで私の目で見える範囲の話で、サンプルの1つにすぎないものとして読んでほしいと思う。

【私の仕事について】

まず初めに、自分仕事はなんだと言われると、それは「システムに関わるプロジェクトマネジメントをする人」ということしか出来ない。エンジニアとしてプログラミングをしたり、ハードの専門的な知識を持っているわけでもない。一日出社から退社まで何をしているかというと、


1.ユーザーベンダー宛てにひたすらメールを返信する

2.エクセルで作ったスケジュールWBS(タスクリストみたいなもの)を広げて眺めている

3.問題が発生したら関係者を集めて対策を話し合う。あるいは進捗会議を開く

4.上司ユーザー宛へ説明する資料作成する。そして実際に説明する


これくらいだ。コーディングという作業が入る余地は一切ない。ひたすら溜まっていくユーザーからの問い合わせや開発側からの問い合わせへのメールを返信する作業を続けている。この仕事専門性をつけることができるとすれば、プロジェクトマネジメントしかない。プロジェクトマネジメントに関する体系的な考え方、大小に合わせたルール作成ユーザーと開発側の折衝ごと。これを突き詰めていくしかない。



エンジニアとしての知識について】

同期や周りの先輩、後輩を見る限り、新卒で入ってきたうちの3割が情報系、3割が情報系以外の理系、残りが文系といった印象を受ける。

はてなを見ていてWeb業界アプリ業界さらーっとIT系用語を知ることができたが、おそらく同期の半分以上の人はWordpressという存在を知らないだろう。

会社の中のほとんどの人がGitGitHubを知らないだろうし、DockerJavaScript系のライブラリ名を知っている人など皆無だと思う。それだけ、技術貪欲でないし、それを使える環境はないし、ユーザー投資しない。

新しい技術基本的に入れることができない。ユーザー側の経営層がまず理解していないというのと、もしも万一障害が起きたら?という問いに回答できないケースばかりだからだ。だから、今動いているシステムスパゲッティーをどばどば追加して、秘伝のソースで味付けし、もはや誰にも全容はわかりませーんと言ったことを10年、20年というスパンで行う。

誰も、どうしていいかからない、どこから手をつけたらいいかからないのだ。



要件定義について】

じゃあ、1次請けだし、ユーザー要件定義が出来るかというとそうでもない。ユーザー業務精通できないで、ユーザーテスト工程で決めきれていなかったものがバラバラ出てくるなんてザラだ。

ユーザーユーザーで融通がきかない。個人的に、パッケージシステムを使うと決めたのであれば、どうやってもユーザー業務を変えていく必要があって、それができないのであればフルスクラッチもっと金かけてやれよと思うのだが、ユーザーパッケージ入れて安くしたい(金融系のパッケージなんてどれもべらぼうに高価だが)、かつ、業務は変えたくないのでがっつりカスタマイズしてと言ってくる。

また、業務内容によってはミスった時のリスクがでかい特に法律に絡む案件は、ミスったら数百億の罰金をくらう可能性が常につきまとう。失敗が許されない。金融系のシステムはそういったリスクと常に向き合っていくので、楽しむことは難しい。うまくいくのが当たり前でなければならない。




やりがいについて】

毎日メールエクセルパワポとにらめっこして、ユーザーベンダーとおしゃべりして、何かやりがいはありますか?と問われると、少しだけあるにはある。

案件規模が億越え、10億とか普通な世界なので、官公庁連携したりと大きな仕事が多い。勝手ゼネコンの人も同じ気分を味わっているんじゃないのかなーという気になっている(ごめんなさい)のだけど、

例えば「スカイツリー建設プロジェクトマネジメントをしてました」と言えたら、自分少しは世のためになったかな?と思えると思う。そんな気分に少しだけなれる。自分が作ったわけじゃないけど、大きな仕事に少しだけ関わっているから。




からエンジニアとして技術で飯を食べていこうとしてSIerに入ってしまった人には酷な会社である。そうやって間違えた同期は早々に転職していった。FBで多くの同期とつながっているが、技術よりのカンファレンスに行きましたとか、勉強会に行きましたといった話は、転職していった人からしか聞かない。会社に残っている同期から流れてくるのはリア充っぽい、旅行飲み会写真ばかりだ。

一方で、プロジェクトマネジメントに楽しみや喜びを得られる人には向いていると思う。多くの案件を見てきて、プロジェクトマネージャーが変わった瞬間に物事がうまく行きだしたとか、逆にうまくいかなくなったといった状況をたくさん見てきたので、スキル必要仕事であることは間違い無いと思う。それはエンジニアが求めるスキルと異なるだけで、割と専門性を突き詰めることが出来る職業だと思う。その会社特有のやり方に慣れずに、案件をこなしていく中で普遍的スキルを身に付けることができれば、どこでも通用する可能性もある。(多くの人は会社特有スキルを身につけてしまって、他社に転職できない状態になるのだが。)


私のやっているSE業と、世間のいわゆるエンジニア業というのは、かけ離れた職業であって、それぞれやりたい方をやればいいと思う。

ただ、私にはミスの許されない超絶大規模プロジェクト精神をヒリヒリさせながら、数百人月プロジェクトマネジメントを楽しむなんてことは全く出来ないので、どこか遠くに消え去りたいと日々思っている。

2016-11-23

[] 再開発された車輪は小回りが利く

ある機能が欲しい時、既存プログラムを拾ってくると一瞬で終わることも多いのだが、

他人が組んだプログラム依存ライブラリやら受け付けない値やら自分では許せない範囲の誤差がある近似が含まれていたりするから

自分で一から組み直すのも悪かないよねという意味

引継ぎをした人間がどうなるかは知らない。

2016-11-20

大多数のプログラマは…

IT業界に努めてもうそろそろ二桁年。

そこそこの企業特にWeb系で渡り歩いた経験から真実を書こう。

一般的プログラマと呼ばれる人たちは

はっきり言う、ほとんどのプログラマ自称する人間の 9 割はコーダーである

言われたものを作る事はできるが、それ以外何も出来ないと言って過言ではなく、何もしない。

そんな驚きの生体をここに晒していく。

一般的コーダー自称プログラマ)は、アプリケーションの基盤が作れない

標準化と呼ばれるプロセスで、プログラマ環境設計、組み合わせ、開発プラットフォームセットアップ、開発環境の構築手順作成、開発手順の作成必要技術考察を行う。

なぜそうなったのかは知らないが、一般的にそうなっている。

その環境に浸っているせいか、彼らはゼロベースものを作ることが出来ない。

彼らにできるのは HelloWorldコマンドプロンプトで表示するプログラム程度の事しか出来ない。

複数ソースの連結、ライブラリの読み込み、サーバへのデプロイ、どれも手動で出来ないのだ。

一般的コーダー自称プログラマ)は、保守性を考えない

彼らは自分に任されたものを動かせればタスクが終了する。

逆にそれ以外のこと、コードの読みやすさや、クローン率の低減、メソッドコメント記載などの保守に関わることをしない。

それは彼らにとって「必要ない無駄作業」としか考えないのだ。

早く仕上げるためなら、似たような動いてる箇所から、よく読みもせずにコピペを行う。

そして彼らは、作るより運用する期間の方が遥かに長くて、その間に修正地獄を見るという簡単論理に気づかない。

…何度味わっても気づかない。

一般的コーダー自称プログラマ)は、勉強しない。

一般的プログラマコーダー)は勉強をしない。

たとえするとしても、業務時間中に業務で使ってる技術ピンポイント学習するだけだ。

勉強会は確かに多い。「.dits」何かがいい例だ。

だが、プログラマと呼ばれる人間の母数に比べれば微々たるものだ。

彼らは言う「土日にまで仕事してられるか」「勉強会行ってるの?馬鹿か?」

あえて言おう、馬鹿は彼らだ。

一般的コーダー自称プログラマ)は、自分の使う道具がわからない

Web仕事をするならIDE統合開発環境エディタコンパイルテストデバッグ実行などを画面から行えるツール)はほとんど必須エディタで済ませる事も出来なくはない)が、彼らは状況に応じたセットアップができない。

たとえば「Mavenプロジェクト管理ツール)、checkstyleコーディング規約チェック)、editorconfig(改行、インデント文字コード設定)」が入っていたとする。

するとEclipseなどを使うとして

  1. どのプラグインを入れればいいか調べられない
  2. どうやってプロジェクトを取り込めばいいかからない
  3. プラグインを入れても設定方法がわからない(IDEデフォルト設定と、プロジェクト内の設定の違いを認識できない)
  4. IDE の設定画面がわからない

マニュアルチュートリアルを用意しないと、道具の使用もままならない。

一般的コーダー自称プログラマ)は、テストコードで書かない

テストをなるべく機械やらせようということの利点が理解できない。

コンパイルして動かして確かめればいいと本気で考えている。

そのために、何十回もコンパイルデプロイアクセスログインの手順を何度も繰り返す。

関連する他の修正を行うたびに繰り返す…。

そしてやっと動くとひと仕事終えたと満足感に浸る。

一般的コーダー自称プログラマ)は、プライドが無いか、変なプライドを持っている

ラリー・ウォールというとある有名な人物Perl開発者にしてC言語ハッカー)がいる。

彼の言う三大美徳に「傲慢」がある。

これは、自分の作るもの完璧なのだ、だから完璧であるように出来る限りのことをするという美徳である

一般的コーダー自称プログラマ)は、このプライドはない。

彼らは金のために嫌々動くだけのものを作るのだ、動きさえすれば報酬は変わらない、よって当然完璧かどうかなどどうでもいい。

同じ金でより良いものを作るのではない、要件だけ満たせばよいのだ。

変なプライドを持つコーダーは、それで運良く成功すると、自分知識は正しい、自分技術は十分なのだと考えている。

こういう人間は、プライドの無いコーダーよりたちが悪く、うまくいかないと他人環境のせいにする。

そして調べず周囲を苛立たせるのだ。

おわりに

土日に自ら勉強会に行くプログラマや、それこそ 50 人以下などという会社であればこうした事はあまりない(んじゃないかと思う。)彼らは自分でなんでもやらないといけないからだ。

だが、大企業に飼われる子飼い企業派遣(そもそも人手のみを求められる企業)、100人以上の企業では、役割分担に伴いこうした状況が多々発生する。

だが役10年、エンジニアを見てきた結果は変わらない。現実問題こうなのだ、こんな人間が大多数なのだ

人の多い企業ほど考えたほうがいい、それでより良いものが生まれるのかと。

必要とされる技術だけを叩き込んで金にしたいと言うのは分からなくないが、基本姿勢思想はどうなんだと。

経営者マネージャーよ、あなた方の言う「最適化」とは現場が日々考え行っている最適化か?人員最適化だけを行って、生産性が伸び悩んでいないか

そのあたりは考えた方がいい。

エンジニア立ち居振舞い: 技術的な暴力を振るわない - futoase

http://futoase.hatenablog.com/entry/2016/11/19/155427



例示されている暴力はだいたい頭の悪い暴力なので反論できます


CGIには今の時代PHPを利用するのに、なぜ未だにPerlを使っているのか。処理速度も遅く、表現も難解だ。

では今あるシステム全部PHPリプレイスするとして、○人月工数必要ですがそのような予算はありません。



Go言語のもの表現力が低い。そんなものを利用するならJavaScalaで書くべきだ。ライブラリ豊富にあるだろう。Googleに縛られた環境での開発は恐ろしい。

ところでどうしてWindowsPCを開いてExcel文書作ってるのか教えてください。



Serverlessそのものサーバがなくなるわけではない。自身チューニングなど細かなリソース管理ができないPaaSを使って自身サービスの命運を預けるなんて馬鹿げている。

理屈の上ではオンプレミスIaaSの方が細かな管理できるかもしれませんが、サーバ管理にそこまでコストかけるつもりが無いのに適当なこと言わないでください。

みんな忙しいから結局何もやってないじゃないですか



iOSアプリのものプラットフォームがいつまであるかもわからないし、今後広がるかわからない。Objective Cを覚えたり、そんなもの技術をかけてどうするのか。

Nintendo Switchが大流行するかわからない。コントローラー使いづらいし。あんものはチンケなものだ。そもそもUnityインフラエンジニアが覚えて意味があるのか。

流行前は流行らないと言い、流行った後は将来性が無いと言う、じゃあ一生何も始めないつもりですか?

でも安心してください。すべてはUnity解決してくれます。そう、Unityならね。






とは言っても結局は私も暴力をふるう側の人間

例示された人たちに暴力ふるいたい。

windowsmacフロントエンドインフラ組み込みいう線引きからはみ出してはいけないと思うな。むしろ全部やれ全部だ!誰もお前がカバーしてない部分をサポートなんぞしねえからな!


ECサイト作りたい人 → ヤフオクでやれ(CMSを使うことの大切さ)

iosアプリ作りたいwindows開発者 → くだらないことにこだわってないでmaciphone買え(ios開発は何もかもmacxcode大前提

フロントエンドプログラマgo → goだけ使われても微妙。当然DBとの連携もあるんだよな?ん?(サーバサイドスクリプトDB連携のためにあるようなもの

サーバレスに興味あり組み込みエンジニア → どうでもいいからさっさと作れ。そこ悩むとこじゃねーから!(悩むなら一度サーバ立ち上げから自分でやってみてイメージをつかんだ方がいいかも)

NintendoUnityインフラエンジニア → やればいいと思うがハードルが高すぎて頓挫する可能性が高い。まずはUnityエディタ上で動くくらいを目標にすべきだ。

2016-11-18

JavaScriptが嫌いだ

今行ってる現場ではJavaScriptがいっぱい使われている。

使用しているライブラリjQueryをはじめ、EJS、Knockout 、jsTreeなどなどなど10近くに上る。

 

ライブラリに何ができて何ができないのかよくわからないし、

ライブラリはどうやって使えばいいのか英文サイト見ながら勉強したり、

サンプル通りに実装しているはずなのに期待通り動かなかったり……

ちなみにJavaScriptライブラリだけで1メガバイト以上のサイズがあった。

もういや。JavaScriptなんてなくなってしまえばいいんだ(´;ω;`)ウッ…

2016-11-06

なんのために必要書類なのかっていうのが重要だと思う

詳細設計つっても、実装するのに必要なのか、ライブラリとして利用するために必要なのか

どっちにしろ詳細である必要はなさそうな気もするけど

現場レベル会社が別で何度もコミュニケーションが発生するコスト

下請けに一回ドキュメントに落としてもらえばあとはまきとれるかの違いじゃないか

2016-11-01

業務系にWebアプリケーションが人気である理由がわからない

特に最近JavaScriptごりごり使ってるやつとか

一昔前なら軽量とか工数が少なく済むとか理由があったんだろうけど

今はJavaScriptごりごりでRichどころかFatになってるじゃん

マシンスペックも上がってるんだからもうクライアントサイドもサーバサイドもJavaでいいじゃん

 

JavaScriptただでさえ読みにくいのにライブラリが大量に使われててもうわけわからん

JavaScript使いたくないよ~( ノД`)シクシク…

2016-10-23

http://anond.hatelabo.jp/20161023044837

NVIDIAと組んだことが裏目に出る気がして仕方がないのだがどうだろうか。

NVIDIAGPUでは唯一の成功者になっていてGPGPUDeep Learningだと元気がいいが、

モバイルでの施策は悉く潰えている。

Android 3.x HoneycombはNVIDIAが driverを公開しないためにAOSPの黒歴史扱いでなかったことになっているし、

SHIELD TABLETは全機回収騒ぎを起こした。

TEGRA K1はすぐに後継のTEGRA X1が出てSDKが禄に更新されなくなり、

TEGRA X1車載メインだが自動運転などさせようと思ったら非力だ。

OSライブラリなどソフトウェアを全部任天堂部隊担当して

アプリケーションを作りやすい開発環境を用意できても、

NVIDIAハードウェア陳腐化するのが早すぎる。

2016-10-17

http://anond.hatelabo.jp/20161016224105

わかる。

俺はWebプログラマだけど、プログラミング界隈なんて、超絶優秀な人が馬鹿みたいに働く世界からな。(別に仕事のものではないが、自分仕事で使うためのツール/ライブラリだったりとかね)

家族かいても、なんか面白いこと見つけたら深夜まで調べたり実装しちゃったりする。

確かに、年齢による体力の衰えについては、今定年を迎えたWebプログラマっていうのは存在しないわけで、今後どうなっていくのかは気になるところだ。

2016-10-13

主語デカ系】ITに対する教育コストが高くなりすぎている

なんか「プログラミングはそんな簡単じゃない」みたいな話題があったじゃないですか。

なんかうまく言えないんだけど、プログラミングに限らず、今の世の中は若者ITスキルを得るのにかかるコストデカくなりすぎてないですか?

俺ら40絡まりのオッサンどもはマイコンパソコン黎明期あたりから趣味としてITに触れていて、

できることも限られていたから、その辺のパソコン少年的凡人だってH/W S/Wの根本から触れてた人が多いと思う

でもって元々大したことができなくっても、動くだけで楽しかったしね

それが今では、フロントエンドアプリを作るってならリッチ統合環境とかライブラリが揃ってて、

別にH/Wのハの字も知らないでも結構見栄えするすごいものが作れちゃったりするわけじゃないですか

日常生活だってものすごい能力をもったものが当たり前のように手のひらに収まってる

こんな環境では、よっぽど高い意識能力を持った奴でないと、H/Wの基礎からそれを動かすS/Wをキッチリ学ぼうなんて思わないでしょ

手のひらですんごいものが動いてるのに、Hello world!やったって面白くもなんともないよね

よしんば興味をもったところで、今度は突然40年前に逆戻りだ

しかも目の前で起こっている出来事からイメージリンクしにくいから凡人には理解し辛い

オッサンどもはテクノロジの進化とともに自分たちも年を重ねてるから、頭が凡人でもなんとかかんとか「流れ」で理解していけるし、理解するための時間たっぷりあった

から別にそれほど高い意識とか能力が無くても、ちょっとしたゲーム好きから始まった奴とかでもそれなりに基礎を体で理解していて、みっちり鍛えられてはいないけど

全方位まぁまぁ戦える在野の武士っぽい奴らがいて、そいつらがこれまでのITをそこそこ支えてきたように思う

ところが今の若い連中は下手すりゃそれを数年で詰め込まなきゃいけないし、とっかかりが現実とロングディスタンから明確な目標とか意思がないとモチベが保てない

そりゃフロントエンドアプリはいいかもだけど、ITを支えるのはそこだけじゃなくて、今だってH/Wからすべて理解したうえでの領域人材はたくさん必要な筈

どっこい、昔は沢山いたはずのソコソコかもしれないけどまぁ戦える在野の武士絶滅寸前で、武士といえば兵法も知らない農民バイトか、

逆に超一握りの生粋武将だけになっちまったような気がしてるんだが、これからITはそれでやっていけるんかいね?

教えて!エロい人!

2016-09-18

Apple様、プレイリストを虐げないでください

iOS 10ミュージックアプリ無駄リニューアルされてクソ使いづらくなってるんだけど、まぁそれはいものことだからしょうがない。

でも一つだけ許せないことがある。下のメニューに「プレイリスト」がなくなっている。

過去にも確かApple Musicが始まった時期にデフォルトで表示されなくなったが、Apple Musicオフにしたりすると表示されていた。でもiOS 10ではもう表示されないみたいだ。

今、ミュージックアプリメニューはこうなっている。

ライブラリ(全部ここから辿るしかない)・Connect(使わない)・Radio(使わない)・検索(使わない)」

使わないボタンが4分の3もある。今ではここにプレイリストがあったからあまり気にしてなかったけど、プレイリストを消してまでこんな意味ないショートカットを残すのはなんなの?iPhoneDAPとして使わせたくないの?

というか下のショートカット編集させてください。

2016-09-03

http://anond.hatelabo.jp/20160902031012

http://anond.hatelabo.jp/20160902031012

はてブ批判してる人たちよりよほど志のある学生さんだと思うので、いろいろ書いてみますおっさんのたわ言ではありますが、元記事の人にすこしでもヒントになればと思って。


大学に行っても実用的なソフトウェアを書けるようにはならない

実務の話!! 実際に「IT系のおしごと」というのがやってるような話で、特にコーディングに直接絡んでくるようなもの

技術実態みたいなやつ。そういうのは学校で教わらないんですよね。

まず、日本大学勉強しても実用的なソフトウェアが書けるようにはなりません。どういうことかというと、「情報系の大学に行けば○○が作れるようになる!」という世間一般の期待と、実際に大学で教えている内容には大きなギャップがあるということです。


これは大学が悪いのではなく、大学はそもそもそういうものであって、それが世間認知されてないというだけです。


具体的に挙げてみましょう。

大学で教えてる内容ってこんな感じなので、ゲームアプリサービスを作ることが目的の人から見ると、役に立たない内容にしか見えませんし、実際たいして役に立ちません。その証拠に、大学情報学科を出ていないのにゲームiOSアプリWebサービスを作っている人はゴマンといるし、逆に日本大学先生ゲームiOSアプリWebサービスを作れる人はほとんどいません。


日本大学先生実用的なアプリサービスを作った経験がない

これは重要ことなのでもう一度書きますが、日本大学先生ゲームアプリサービスを作れる人はほとんどいません。大学先生が得意なのはプログラムを書くことではなく論文を書くことです。論文のためにプログラムを書くことはありますが、あくまでおまけです。


そのため、大学勉強してもゲームアプリサービスが作れるようにはなりません。だって教えている側の先生が、ゲームアプリサービスを作ったこともなければ、作り方も知らないんだから

そういう経験のない人たちばかりですよ、日本大学先生って。そんな人たちの授業を受けて、アプリサービスが作れるようになると思うほうがおかしいでしょう。


ためしに、先生方のTwitterアカウント名でGithub検索してみてください。いまどきGithubアカウントがないとか、あったとしてもTestCaseすらないコードとか、そんなものばかりです。「研究内容をライバルに知られるわけにはいかないかGithubは使わない」という言い訳する人がいそう。けど、本当はGitが使えないだけでしょ?


あるいは、先生方の個人ページや研究室の紹介ページを開いて、HTMLソースを見てみてください。doctype宣言がないとか、viewportの指定がないとか、Pタグの中にULタグを使ってるとか、そんなのばかりです。HTMLすらろくに書けない人が、Webアプリを作れると思いますか?きっとXSSCSRFも知らないですよ。


ですので、そういうことを勉強したいなら、ベンチャーIT系企業に入るべきです。大学でそういうことを勉強しようとしても、教えられる人がいないから無理。
(「大学はそんなことを教える場所ではない!」と怒る人いると思うけど、教えられる先生がいないという事実ごまかすために怒ってるだけだから。)


ジャンルが違う

はいっても、大学先生プログラムがいっさい書けないというわけではないです。彼らが得意なのはコンパイラインタプリタOSやソルバを作ることです。これらも実用的なソフトウェアと言えなくはありませんが、ゲームアプリサービスとはジャンルが大きく違います


そのため、大学情報学科に進めばコンパイラOS機械学習ライブラリを書けるようにはなるかもしれませんが、それはゲームアプリサービスではないので、繰り返しになりますがそれらを作りたい人には大学は向きません。


大学で教えている内容ってムダなのか

じゃあ大学で授業を受けるのってムダなのかというと、必ずしもそうではないです。

大学で教えている内容って、ゲームiOSアプリWebサービスが一通り作れるようになってから、その先を目指すときになって初めて必要になることが多いです。たとえば、

こういうときになって、初めて大学で教わった内容が生きてきます。逆にいうと、そういう状況にならないと、大学で教わった内容は生きてこないと言えます。(情報系の学科で学んでいるなら、ライブラリ言語OSを「使う人」ではなく「作る人」にぜひともなってほしいですね。)


元増田に進めたい進路

元増田は、社会に役立つ実用的なソフトウェアを作りたいようです。しかし残念なことに、大学が教えている内容はその目的には合致していないことを説明しました。


こういう事情なので、元増田には大学ドロップアウトしてIT系会社入社することをお勧めします。ドロップアウトが難しいなら、インターンバイトでなんとしても入り込むことです。


入るべき会社は、教育に力を入れている会社です。20人未満の小さな会社では教育に力を入れている余裕はないので、小さな会社はやめたほうがいいです。簡単にぐぐってみたところ、はてなPixivクックパッドDeNAドワンゴ教育制度確立しているようです(違ってたらごめん)。そういった会社に入ったほうが、大学の授業を受けるよりも、元増田目的にかなうのは間違いありません。


そして何年か働いて、iOSアプリWebサービスが一通り作れるようになったら、大学に入り直すことです。これはとても効果的なので、元増田には強くお勧めします。


上で説明したように、大学というところは、ゲームアプリサービスの作り方は教えてくれず、それらが作れるようになって初めて役に立つことを教えてくれます。そのため、元増田IT系会社に入ってアプリサービスの作り方を勉強し、それらが作れるようになってから再度大学の門をたたくのが、いちばん効率的です。


なお繰り返しますが、入るべき会社は「教育に力を入れている会社」です。今のIT系企業では、インターン生を「格安で使えるバイト君」としか見なしていない会社が多すぎます。そういう会社は、コストが掛かることはいやがるので、教育もろくにはしてくれません。逆に教育に力を入れている会社では、インターン制度を「将来の戦力を選別する期間」と見なしています


残念ながら、そういう会社東京に集中しているようです。例外京都はてなくらいでしょうか。地方大学生にとってはつらい現実なので、はてなPixivドワンゴ地方でのインターン開催をお願いします。あとレベル5は九大と九工大学生を鍛えてあげてください。


余談ですが、学生さんにひとこと:

インターンバイトで潜り込む先の会社を選ぶときは、就活と同じような時間をかけて選んでください。バイトからとかインターンからという軽い気持ち会社を選ぶ大学生が多いから、それを食い物にしている悪質経営者があとを立ちません。インターン生が「格安学生バイト」として使われている現状を是正するために、学生のほうでも注意してください。


大学で授業を受けなくても独学で効率的勉強する方法

ドロップアウトを進めた手前、書こうと思ったけど、長すぎるのでやめた。

リツイートが100超えたら書く。

なぜITはこんなにも不完全なんだ

もう50年も60年も経つじゃないか

なぜ未だにトランジスタについて学ぶ必要があるんだ

なぜ未だにCPUの内部構造について知っているのが当たり前という風潮なんだ

なぜ未だにC++が書けるプログラマが本物のプログラマ呼ばわりされているんだ

なぜ未だにコーダーという単純労働者必要とされているんだ

なぜ未だにホームページ屋さんという職種が成り立つん

なぜ未だにCiscoの設定書くだけの資格がもてはやされるんだ

なぜ未だにアルゴリズムを書く能力絶対必要だとされるんだ

なぜ未だにプログラムを書いているのではなくAPIを叩いているだけだという罵倒が成り立つん

なぜ未だにマルチスレッドプログラミングなんて手で書いているんだ

なぜ未だにUMLマウスポチポチ書かなきゃいけないんだ

なぜ未だにライブラリが増え続けるんだ

なぜ未だにコンピューターサイエンスなんて学問必要とされるんdな

もうプログラムを書きたくない

方法論を考えたくない

そんなのを作りたいものを作るだけの人間が考えるのは間違ってる

簡単に良いものが誰にでも出来ることが理想に決まっているだろう

人間なんて働かないほうが良いに決まっている

なぜこんなにも不完全なんだ

なんでまだこんなにも人間の手を煩わせるんだ

こんなのは現代手工業

SOHOが成立するのは時代が進んでいるんじゃないぞ

フレックスタイム産業革命以前への退化だぞ

早く産業革命が来てくれ

人間に何も考えさせないでくれ

もう休ませてくれ

助けてくれ

2016-08-12

amazon unlimited 使いづらい

コンテンツ管理から本の利用を停止したいのに、iPhoneからだとアカウント管理のページを開いても出てこない。

やっとたどり着いて、本を削除しようにも、オーナーライブラリ使用中だからできません。と出て、じゃあどうやってオーナーライブラリの利用を停止するのか調べでるけどまだ分からない。

すごく使いづらくて利用やめたくなってきてる。

2016-08-07

ディープラーニングAV女優類似画像検索サイトをつくった

Babelink

http://www.babelink.net/

作った動機は、そっくりNAVIをつくった人と似ていて技術勉強のためと今ある類似検索サイトへの不満からです。

そっくりNAVI - 気になる子顔写真で、似てるAV検索できるサイトを作った

http://anond.hatelabo.jp/20160719033025#tb

... 素人からも探せるのは素晴らしいと思います

ディープラーニング最近流行りの技術で、一般的物体認識では人間匹敵するか

もしくは超えるぐらい画像認識の精度がいい手法です。

今回は自分が持っている画像有名人に似ているAV女優を探すという

極めて実用的な問題にその手法を試したいと思い、サイトをつくってみました。

使った主要なライブラリを紹介しておきます

■使ったライブラリなど

python (プログラミング言語)

PostgreSQL (データベース)

・flask (Web構築)

opencv (画像認識)

・dlib (顔検出)

chainer (ディープラーニング)

・FlexSlider (画像スライダー)

・Awesomplete (入力補完)

ぼくは一応エンジニアのはしくれですが、pythonとか仕事でちゃんと使ったことなレベルです。

それでも3~4ヶ月程度である程度のサイトはつくれるので、みなさんも是非つくってみてください。

課題

ディープラーニングでは非常に多くの画像機械学習させる必要があるのですが、

現状では学習のための画像がまだまだ足りていないので、あまりいい精度はでていません。

あとはディープラーニングで精度を高めるには、ハイスペックGPUマシン必要になるのですが、

そんなもの持っていないので精度をこれ以上あげるのは難しかったです。

そんなかんじで、まだまだ改良の余地はたくさんあるので、楽しみにしていてください。

■参考にしたサイト

完全に一致

http://anond.hatelabo.jp/20101203150748

京大画像処理を学んだ僕が本気でエロWEBサービス作ったった

http://anond.hatelabo.jp/20130122180847

UIは一応Netflixを参考にしてます


画像収集サーバー容量の問題もあり、していないので画像検索を気軽に試してみてください。

Babelink

http://www.babelink.net/

2016-07-31

webサイト作成したいだけなのに何でファイルを沢山作らないといけないのか

webpackの設定ファイル

gulpの設定ファイル

sass設定ファイル

ライブラリを使うとどんどんファイルが増えていく

設定に関する仕様策定して統一できないものかね

設定ファイルを1つにまとめられたら良いんだけどね

↓こんな感じで1ファイルカテゴリ毎に設定したほうがディレクトリがきれい

[webpack]

[gulp]

[composer]

[phpmd]

2016-07-28

http://anond.hatelabo.jp/20160728113532

バージョン確認は当たり前と言うけど、逆にマイナーバージョンまで一致してることなんてほぼないわけじゃん。どの程度違ってても動くのかなんてわからいから、確認した所であまり意味はない。

またライブラリよりも依存する環境の設定(バージョンではなく)で動かないケースが経験上多いからそこまでは記事から確認できなくてお手上げなんだよな。

解決策としては公式を読み込むしか結局ないんだけど野良エンジニアブログが役に立ってた時代より開発に時間がかかるようになったのは確か。

http://anond.hatelabo.jp/20160727175406

ライブラリバージョンが一致しているかどうか確認するのは当たり前のことだよ。

つーかNodeでもライブラリドキュメント読めば互換性があるかどうかはきちんと書いてある。

Javaは安定してるっていうけど、この前Android開発でJDKバージョンアップした時にjarsignerのデフォルト引数が変わっていてひどい目にあったかJavaでも同じ。

アピールできるスキルが無くて辛い

これまで10年近くプログラマやって来たんだが、コアになるスキルを身に付けずにここまでやってきたことに後悔を感じている。というのも転職活動をしていて、経歴はそこそこあるので書類は落ちたこと無いんだが、リーダークラスの人との面接で、経歴を交えつつ自己アピールすると全然ダメだ。というかそれがダメだとどうしようも無いんだが。



動画処理とか音声処理、データベースネットワークまわりのアプリを点々とやってきた。とはいっても、それらを実現するための、コアなライブラリ別に有って、外部から色々なたたき方をして、アプリケーションにすることをやってきた。



動画だったらコーデックとか、データベースだったらチューニングとか、そういったものに詳しいと思われてしまうようなんだが、そこらへんはライブラリ任せだったので、そこにコアなスキルがあるわけではない。コア技術をくっつけてアプリにするような、接着剤みたいなコードをずっと書いてきてしまった。ただ○○って言語使ってバリバリ書いてました、じゃ全然ダメだ。



今まで漫然と過ごし過ぎていた。もっと深堀したスキルを身につければ良かったな。もし似たような境遇の人が居たら、どうやってアピールするか教えてほしい。

2016-07-22

https://twitter.com/yuku_t/status/753177071468224512

それできるVimプラグイン作ってるよ

scipyとnumpyを自力挫折せずに導入できる人しか使えないし出来ない人のサポートしたくないしVim 8.0に合わせるから今は公開する予定はないよ

http://anond.hatelabo.jp/20160107202352

プラグイン自体はだいたい完成してて今は辞書を膨らませている

Vim界隈でPython機械学習に詳しい人なら作れるよ

いくつかPythonライブラリを覚える必要があるけど君達もPython覚えてチャレンジしてみなよ

良いエンジニアの条件ってさ・・・

以下の記事を読んでの考察

https://nanapi.com/ja/122917



上記内の記事でもそうだし、

散々いろんな優秀な方々が言ってることだから

良いエンジニアになるのに一番大事なことって


技術が単純に好きなこと」


なのだろう。。。多分。



そこでふと思ったんだけど

この技術が「好き」という想いには

レベル存在しているのではなかろうか。


自分はまだ駆け出しのPGだが、

以下は自分想像した

アプリケーションエンジニアの「好き」レベルである




Level1】:

ネット本屋で新しい技術を目にすると、ざっと確認してしまう習慣がある。

ありがちな言動:「ふむふむ(ほむほむ)」



Level2】:

Level1に加え、自宅でWebサーバを公開したり、アプリ作成している。

またこのレベルからデザインUI/UXDBセキュリティインフラ技術など、興味関心が多分野へ渡りコミットし始める。

ありがちな言動:「今日アクセスが10増えたぞい。ぐふっ」



Level3】:

Level2に加え、休日はしっかりと時間を確保し、技術習得や、OSSへのコミットを楽しんでいる。

ありがちな言動:「今日×コミット×コンプ♪」



Level4】:

Level3に加え、技術面白すぎて、いろんなアイデアが一日中頭の中に浮かび、

気づいたら毎日手を動かして何らかの実装をしている。

ありがちな言動:「フォオオオオオオオオー」



Level5】:

Level4に加え、FWライブラリソース読破し、茶々を入れることに喜びを覚える。

また実際にコミットも行えるLevelに到達。

ありがちな言動:「これはアカン。。」



Level6】:

Level5に加え、言語設計にまで手を伸ばし始める。

現在第2のMatzになるため、世間から隠れたところで日々ハッピーエンジニアリングに勤しむ。

ありがちな言動:「俺が最高の言語、作っちゃる!!!





↑これあってる?

2016-07-10

memo

書籍より

Web + DB vol.92

データ分析の基本アーキテクチャ
フレームワーク比較評価

10年戦えるデータ分析入門

SQL中心アーキテクチャの3つの
SQL中心アーキテクチャの3つの条件
tips
  • DWH層を標準ライブラリのように考えて構築するとよい.
    • 「購入の可能性があるユーザ一覧を表すビュー」をDWH層に持たせるなど.

2016-07-06

コンピュータ言語言語ごとの特徴を俺が教えてやる(異論は認める

コンピュータ言語って世の中に山ほどあるけれど、それぞれの言語ごとに特徴がある(特徴のない言語は廃れていく)。

まり言語に詳しくない人相手に、俺の考えるそれぞれの言語の特徴を書いてみようと思う。

なお、取り上げるのはある程度広く使われている言語に限りたいと思う。

TL;DR

言語 概要
C言語 高速動作するバイナリ生成を目的としたコンパイル言語。だいたいどんな環境でも使えるがバグやす
C++ マニアック言語、高速、習得大変
Java サーバで高速かつ安定に動作するコンパイル言語、大規模でよく使われる
C# 主にWindowsクライアント用のバイナリ生成に使われるコンパイル言語
Perl 広く使われていたが今は若干時代遅れのスプリクト言語。汚い
Python Perlにかわって主流になりつつあるスクリプト言語。綺麗
PHP Web開発にフォーカスされたスクリプト言語一世を風靡した。
Ruby とても綺麗なスクリプト言語
JavaScript ブラウザで実行出来る唯一の言語言語自体はいまいちだが、ブラウザ事情需要あり
Go サーバサイドで安全かつ高速動作するバイナリ生成を目的としたコンパイル言語

詳細

C言語

メモリに直接アクセスして書き換えるといったコンピュータ機械語に近い言語構文を持つため、高速な処理が可能言語

コンパイラ歴史も古く環境も整っており、組み込み系などを含むほぼ全ての環境で利用可能な万能言語

一方で、メモリの確保や解放といった基本的なことも自前で処理する必要があるため、コーディング効率が良くなく、多種多様バグを生みやすい側面も持つ。

ある程度以上のエンジニアであれば常識として知っておきたい言語だが、初めて覚える言語としてはあまり適当ではない。

C++

C言語オブジェクト指向を導入した言語C++言語とはあまり呼ばれず、しーぷらすぷらす、もしくは略してしーぷらぷら、しーたすたす、などと呼ばれる。

C言語の速度を維持したままオブジェクト指向テンプレートなどの効率的記述可能にしようとした意気は真っ当だったのだが、

当時最先端だった色々な技術思想を叩き込んだおかげで、あり得ないほど複雑化した言語としても有名。

C++理解しています」という人はほぼ初級者で、本当に理解していくほど「C++には自信がありません」となっていく。

速度を追求する分野では良く使われている。完全に理解するのは難しいとしても、テンプレートくらいまでは理解しておくと仕事上なんとかなる…かもしれない。

Java

サーバサイドで安全コードを実行する目的でよく使われる言語。長い歴史を持っており、比較的高速に動作する。

当時は画期的だった「バーチャルマシン」や「ガベージコレクション」という機構を備え、CやC++でよく問題になるメモリ解放忘れというバグを生まず、

サーバサイドなどで何千時間動作するソフトウェアに適した言語として受け入れられた。

必然的エンタープライズ用途で利用されることが多く、各種ツールなども豊富人海戦術がしやす言語という側面も出てきた。

一方でブラウザHello Worldを出すだけでも大変な労力を必要とするので、スタートアップなどではあまり使われない。

ガラケーアプリや(ちょっと違うが)Androidなど、クライアントサイドでも使われることがある。

プログラミング言語最初Javaを覚えるという人は結構多いが、仕事としてJavaを使うのは大抵SI系の業務になり、なかなか辛い労働を強いられる可能性が高い。

C#

クライアントサイドで安全コードを実行する目的でよく使われる言語。こちらも比較的高速に動作する。

元々はWindowsクライアント用の言語であり、Javaとは違ってクライアント向きのAPIが多数ある。

マイクロソフトが開発した言語ということもあり、マイクロソフトの優れた開発環境が利用出来るので開発効率は非常に高い。

Unityなどでも利用可能であるが、基本的にはクライアントの実行形式ファイルを生成する目的が大きく、サーバサイドではあまり使われない。

自作ゲーム開発をしたいのであればうってつけの言語。初めて覚える言語としても十分に良いだろうが、C#を使う仕事は近年無くなりつつある。

Perl

ほぼ全てのLinuxディストリビューションに含まれており、ツールや様々な用途で使われていた。

上に紹介したC、C++JavaC#のようなコンパイル言語とは違い、(少し語弊はあるが)1行ずつ実行してエラーがあれば止まるスクリプト言語である

ちょっと開発してすぐに実行ということが出来るのと、コマンドラインでワンラインコードを読み込ませてちょっとした処理が出来るなど応用範囲の広い言語である

20年近く前にWebCGIが普及した時には、ほぼどのようなサーバ環境でも実行可能だったこともあり、Perlを使うことが極めて多かった。

しかし、主に読みづらい言語仕様のせいで、近年新規ではほとんど使われなくなった。既存コードもどんどん別の言語に置き換えられていることが多い。

日本大手Web企業の一部が使っているので、そこに就職するために覚えるのもアリっちゃアリだけど、今からPerlをわざわざ覚えるのは強くオススメしない。

Python

後発のスプリクト言語。こちらもほぼ全てのLinuxディストリビューションに含まれており、それゆえに広く使われている。

インデントまで言語仕様規定することで、誰が書いても読みやすコードになるように考えられている言語である

Perlの代わりに使われることが増えていて、周辺ツールなども充実しており、小規模から大規模までカバーする勢いがある。

ただ、Python2とPython3のバージョン間での非互換性があまり綺麗に設計されていなかったため、そこで混乱を招いていたこともあった。

最近だとマシンラーニング系のライブラリPythonが使われていたり、海外ではPerlに代わる言語として受け入れられつつある。

最初に覚える言語としては良い選択肢だろう。

PHP

Web開発に特化したスクリプト言語CGIの代わりに使われ始め、一世を風靡した。

以前CGIWebに何かを表示するには比較的大変な労力を割かなければいけなかったのが、PHPを使うと誰でも即座にWeb開発が出来たので爆発的に普及した。

またphp.net豊富ドキュメントスニペットのおかげもあり、開発初期の効率が大変に良い言語である

残念なことに、言語API設計がいけていない点が多く、一部の人から蛇蝎の如く嫌われている。

今でも根強い人気があり、海外でも小規模プロジェクト最初の開発にPHPを選ぶのは比較的よくある選択肢であるようだ。

Webアプリを開発をしたいという明確な目的を持つ人が、最初に学ぶ言語としてPHPを選ぶのは理にかなっていると思う。

なおこの言語を本気でディスってる人は大体視野の狭いエンジニアであることが多いので、地雷エンジニアを見分けるのにも役立つ。

Ruby

綺麗なスクリプト言語日本発で世界的に普及している数少ないIT技術の一つ。

言語仕様が美しく、それゆえにファンが多い。Ruby on RailsというWebフレームワークの登場で、Webアプリでの採用例も一気に増えている。

基本的には他のスクリプト言語と同じくサーバサイドでのプログラミングに用いられることがほとんどである

スクリプト言語で何かを作成するのであれば、Rubyを選んでおけばそう失敗することはない万能言語

サーバサイドで何かすることに興味を持っているならば、最初に覚える言語としてはとてもオススメ出来る。

一方で、なぜかRuby採用するWeb側のフレームワーク(具体的にはprototype.jsCoffeeScriptはいつもクソなので、そちらは深入りしないのが吉。

JavaScript

ブラウザで動くスプリクト言語ブラウザ戦争が勃発していた18年前、奇跡のようなめぐり合わせでベンダー間の合意が取れ実装された言語

言語としてはプロトタイプベースオブジェクト指向という少しめずらしい形式を取っているが、実際にはあまりその特徴は利用されていない。

言語仕様イマイチで、大変バグを生みやす言語であり、また関数スタックが深くなる特性もあり、あまり積極的に使うべき言語ではないが

ブラウザで動く言語現在これしかないので、大きなシェアを持っている。

一部の物好きがサーバサイドでこの言語を使おうと(主にnode.jsで)四苦八苦している(とはいえ、1つの言語Webサーバが完結するのは大きなメリットだ)。

ブラウザで動く唯一の言語のくせにとにかく書くのが面倒ということもあり、多数のAltJSと呼ばれるJavaScriptに変換される別言語を生み出されている。

まあJavaScript本体人が手で書く言語ではない…というのがECMAScript5までの印象だったが、新しい規格が順次導入されており、今後に期待。

Web業界で生きていくならば、好むと好まざるとにかかわらず覚えなければいけない言語である

最初に覚える言語としては、ブラウザ上でゲームなども作れるし、node.jsサーバサイドもできるしで、意外とオススメだったりする。

GO

C、C++Javaと同じでコンパイル言語サーバサイドで高速かつ安定なバイナリを出力することを目的とされ設計されたGoogle発の言語

その目的においてはかなり高性能を誇るので、特に速度を要求されるサーバサイドでのプロジェクトでは導入が進んでいる。

それ以外の目的ではあまりこの言語採用するメリットはないが、ニッチ用途ピンポイントで抑えており、これから広く利用されることも期待される。

コミュニティも活発であり、初めて言語を覚える人が参入すれば喜ばれるだろう。言語としても美しい言語なので、サーバ系のプログラムに興味があればオススメである

まとめ

繰り返しだけれど、それぞれの言語ごとに特徴があり、特徴のない言語は廃れていく。

ここに挙げた言語は何らかの特徴があり、何らかの用途必要なので生き残っている。

その背景を知った上で、ここにある言語は全部ある程度読み書きが出来るようになると素晴らしいと思う。