「プログラマ」を含む日記 RSS

はてなキーワード: プログラマとは

2016-06-26

才能がないと自嘲するひまがあるなら、退職願を書いた方がいいよ。

というか、書け。

才能のないプログラマは周囲にとって害悪しかならないから。

あなた一人がへばりつきたいというだけで、いつまでマウスキーボードと、テスターさんを消費し続けるつもり?



確かに、ソフトウェア業界宝くじみたいなもので、

満を持して仕掛けたタイトルコケる一方、

「何でこんなひどい作品、……バグだらけだよね?」というソフトが、

妙なきっかから売れ続けたりする。

プログラマとして、ヒット作を出せないまま数年が経過、というのも、よくある話だ。

でも、そのくじを引き続けていいのは、勘違いかもしれなくても、

自分にはプログラマとしての才能があり、いつか間違いなく当たる」

という確信を持つ人間だけなんだ。




あなたに強みはないの?




会社に対して、

「他のプログラマよりも自分はこの点で優れている」

「だから自分と一緒に頑張っていこう」

と誇れる点はないの?



それがないなら、「つぶしがきかない」とか「転職が厳しい」なんて自分のためではなく、

社会のために、職を辞さなくてはいけない。それはプログラミング仕事に選んだ人間の責務なんだ。

2016-06-25

http://anond.hatelabo.jp/20160625195112

面接で「含コーディングインタビュー」ってプログラマ

どんなとこ受けてるのか知らないけど、同じITベンチャー系なら起業経験してるエンジニアなんて欲しがるとこ腐るほどありそうな気がする。

ただでさえ小さいとこなんてエンジニア不足で悩んでるような話ばっか聞くし。

大企業ばっか受けてる感じだったりするの??

2016-06-22

http://anond.hatelabo.jp/20160622120630

真偽値って概念だけの話なのにアセンブラまで話が飛ぶとか、増田はマジただの老害おじさんだな。webプログラマより組み込み系の方が強いとか盲信しちゃうタイプ

うそはうそであると見抜ける人でないと難しい

うそうそであると見抜ける人でないと(掲示板を使うのは)難しい」とは2chの開設者、ひろゆき言葉である

掲示板を使うのは」という部分を「インターネットを使うのは」に置き換えても通用する名言だ。

だが、溢れる情報を目にして、「これは嘘かも」と思う瞬間はあっても1日数回である

私は今、Web系の会社プログラマをしており、ネットヘビーユーザーであるのは間違いないのに、そんなもんである

みなさんはどうだろうか。様々な情報鵜呑みにしてしまってはいないだろうか。

2016-06-21

マイクロソフト牛尾氏の思い描く姿が日本で出来たら

まず、喋りに難があるプログラマエンジニアIT業界の正常系コミュニティから全員退場させられる。

牛尾氏は今年になって何かに取りつかれたように「アジャイルが浸透してない日本ヤバイ」「DevOpsが導入されない日本ヤバイ」という旨のブログエントリや講演を繰り返しており、その姿は一時期の某武雄市長の姿を彷彿とさせる。

彼が繰り返し言ってることの一つとして、日本人は成果を上げるのに資料を作りすぎだ、というのがある。アメリカでは資料作成は最小限にしてあとは口頭で表現しているが、日本はそうじゃなく資料に頼るから生産性が低い、という論法。手を動かす工数は最小限、いや動かさなくても良い、とにかく目的だけ明確にして会議なりプレゼンなりに臨むべきという考えだ。

それ自体一見間違いではないと思う。最小の工数で最大の効果を得られればそれで良い。

でも、口でカバーすることが得意じゃない、いわゆる「口下手」人はアメリカではどう扱われるのだろうか?



答えは簡単アメリカではそのような人は「障碍者」扱いされるので、IT業界でまともな職にありつけなくなるだけだ。何しろあの国はいわゆる「口下手」な人はおしなべて吃音者扱いされ、かつ吃音症が障害認定される制度であるので、障碍者カテゴリにぶちこまれおしまいさらに言うとアメリカ障害者雇用の面では日本よりも劣っているのが実態で、ここ10年ほど障害者雇用人数は右肩下がり。毎年確実に雇用者数と雇用率が増えている日本とは正反対の動向だ。

仕事出会アメリカ人が皆口達者であるのは何故か考えたことはあるだろうか?コミュニケーションプレゼン教育を幼少期から叩き込まれ教育制度の影響もあるが、このように口下手な人を障碍者カテゴリに追いやる仕組みが備わっていることは見逃せない。

牛尾氏はそのようなアメリカ社会理想形として考えているようだ。つまり口下手な日本人プログラマエンジニア障碍者として、特例子会社テスターとしてせいぜい頑張るか、アマゾン倉庫で汗水たらしてください、と。本人はさすがにそこまでダイレクトに言わないが、理想としているのはそういう社会だろう。

2016-06-19

「もしRubyが普及したら」と10年くらい前に思ったこと

Ruby勢がPHPとかJavaとかをバカにしてたけど、もしRubyが普及して裾野が広がったら、ヘボいプログラマも増えてPHPみたいにバカにされる言語になるんだろうなと思ってた。

それで現在、大して普及もしてないのに、なぜか妙に攻撃されてるな。

プログラマ能力を決める要素

  1. 瞑想運動睡眠野菜
  2. PCの性能
  3. 回線速度
  4. 開発ツールにかけられる金
  5. メンター指導
  6. 地頭の良さ

数日前の絵なんか簡単そうに見える

と言ってる奴がいて検索かけたら2007年からいるんだなこいつ。

発言内容は大体下手な絵で売れてる奴もいるか簡単だという対象を絞ったおかし理屈

ピンきりのカード絵師界の天井知らずを見ていない、井の中の蛙もいいところ。世界レベル供給があるからうまさに際限がない。

習い事には入り口簡単で最終到達地点が険しいタイプと、入り口は難しいが最終到達地点が似たように見えるものがあるらしい。

もしそうなら絵は前者だ。こいつプログラマらしいんだけど、後者の科目だってことに気づいてるのかな?

限定した条件を全体として判断するほどコードが見渡せないとか。ま、門外漢が口出しちゃ同じ穴の狢だけど。

2016-06-17

1.0から学ぶJava

タイトルを見て釣られクマーな皆さんこんにちは

ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。

今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。

「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。

タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー

面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。

Java 1.0 1996年1月23日

Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。

かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日リリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。

今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。

Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日オラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」(The Network is the Computer)というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。

当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。

1996年の時点にこんな言語が登場したのですから革新的でした。

いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。

プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロードテンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。

Java 1.1 1997年2月19日

Wikipediaからピックアップすると1.1での大きな機能追加は

といったところです。当初よりJavaの内部文字コードUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ!というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。

なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。

当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。

JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。

Microsoft Visual J++ もこの時代ですよ。

Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。

当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。

  • java.applet
  • java.awt
  • java.awt.datatransfer
  • java.awt.event
  • java.awt.image
  • java.beans
  • java.io
  • java.lang
  • java.lang.reflect
  • java.math
  • java.net
  • java.rmi
  • java.rmi.dgc
  • java.rmi.registry
  • java.rmi.server
  • java.security
  • java.security.acl
  • java.security.interfaces
  • java.sql
  • java.text
  • java.util
  • java.util.zip

この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。

Java 1.2 1998年12月8日

strictfpキーワード浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。

リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。

1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。

初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。

JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。

あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。

Microsoft 離反

Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつMicrosoftだったわけですね。

Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの!と喧嘩になったわけです。当時のMicrosoftブラウザまわりでも独自拡張がやりたい放題、標準規格?なにそれ美味しいの?みたいなスタンスをあちこちで見せていたものです。

結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。

JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。

Java EE

Java SE とは別にこの時代に Java EEリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。

2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的ユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。

企業で用いられる社内システムにもServletは多く採用されました。

理由はいろいろ挙げれると思うのですが

というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャある意味では便利で簡単でした。

もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。

iアプリ Javaアプリ EZアプリ

2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。

そこにdocomoiアプリJフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ!というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。

iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。

docomoiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。

この賭場が、将来にAppleiPhone, GoogleAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。

RIA時代

話を2001年に戻しましょう。

Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。

Java Appletブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。

Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。

端的に言えば入力値が数字かどうか?みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。

また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。

こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい!という要望があったわけです。Webシステム使いにくい!という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。

Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。

RIAの代表とされるのは

あたりです。三つ巴の戦い、どこに軍配が上がるのか!?と注目されましたが、勝利したのはHTML / JavaScriptでした。

Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。

RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。

しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。

Java 5 (2004年9月30日)

1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。

Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。

言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。

その後

Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。

Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日オラクル吸収合併されました。

Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。

やや戻って2007年Androidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。

Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。

このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語次世代へと移りつつあります。業界動向には注視していきましょう。

2016-06-16

歴史的仮名遣への熱い差別

http://b.hatena.ne.jp/entry/qiita.com/tadsan/items/fb496e450fc27c8c4494

歴史的仮名遣へのヘイトスピーチが人気コメントの2位・3位。これはひどい。そして悲しい。

多分、著者のtadsanは一々コメントを返したりしないので、この場で勝手ツッコミを入れてみる。

bottomzlife なぜ意味不明歴史的仮名遣いがまじってるんだ。気持ちいからやめてほしい。プログラマなら日本語コーディングガイドラインも守れ

「まじって」なんかない。全文が単なる歴史的仮名遣しかない。(これは逆に、「現代仮名遣い」との差が少ない証拠になってる)

あと「日本語コーディングガイドライン」が「現代仮名遣い」を指すなら、そのガイドラインの方が意味不明でクソ。まだ歴史的仮名遣の方が論理的で、プログラマ的にも腑に落ちる。その辺は http://web.archive.org/web/20020612101011/http://hb9.seikyou.ne.jp/home/kyuri/nihongo/kana-hikaku.html でも見れば、小学生でも解る。

megazalrock ネット歴史的仮名遣い風を使う人は無条件に信用しないことにしている。

歴史的仮名遣い風」ではなく、正真正銘の歴史的仮名遣。(字音仮名遣? 知らない子ですね…)

それでも信用しないのなら、個人の勝手だが、そんな差別をする奴は信用ならない。

snobbishinsomniac 「ヘッダ」「メソッド」ではなくて「ヘツダ」「メソツド」だろうし、「レガシー」「モジュール」じゃなくて「レガシイ」「モジユウル」ではないのかな。

外来語の長音記号とか大書き・小書きとかはどっちでもええんやで。

ちなみに「モジュール」は「module」でダ行だから「モヂュール」と書く人も居る。

ghostbass 現代口語と正仮名遣いの相性の悪さ。良い事書いているのに。

慣れの問題。いや本当に。

時間を掛けてまで歴史的仮名遣の読み書きを習得する価値は、個人的にはある。似た感覚としては、全然論理的でないHTML3.2を捨てて4.01とか5.0に移行するのと同じ程度に有用

2016-06-14

プログラマになった君へこれだけは約束して欲しい

上から目線プログラマ論を語るのは最低でもGithubの累計星数1000以上溜まってから

http://anond.hatelabo.jp/20160613210503

それを言ったら、最初話題プログラム関係ないじゃん。

プログラマは、プログラムを書く人であって、OSを整備する人でも古いPCメンテする人でもない。

医者法律の方も、良く知らないけど違うこと言ってない?

2016-06-10

http://anond.hatelabo.jp/20160610182620

足場がプログラマで、あとはざっくり「IT業界全体」になっちゃうのね。

もっとわかってる人が言ってるのかと思ってたわ。

2016-06-06

プログラマにとって最も屈辱的な瞬間

小飼弾ライブラリを使っている時

2016-06-05

全員が専用「金の卵を産むガチョウ」を作れる時代

いろいろディープラーニングラッパーやらAPIをたたける時代になった。データさえ整えれば東京市場の騰落予想も相当の的中率で実現できそうに思えた。

もう金融商品取引ほとんどがロボットになって久しい。金融商品市場の動向が実体経済を示すのだとしたら、人はもうコンピュータプログラム支配されているといっていいい時代だ。そして前述のとおり、もし誰もが人工知能による予想を利用して金融取引、それもこれまでの人間それこそ有名ファンドマネージャが実現できなかった運用実績を得られるのも現在だろう。誰もが程度の差はあれ金の卵を産むガチョウを持てる時代になったと認識したとき株式市場やら原油債券投資対象価値をどのように理解すればいいのだろうか。値動きに価値があるのか、そして市場は成立するのだろうか。

そして、その世界ではよりよいプログラムアルゴリズムデータモデルパラメータを開発した人間がより収入を得られるとしたときに、スキルのある人間とない人間の差はどうしようもなく開いていくのではないだろうか。士郎正宗が腕のいいプログラマ海外渡航制限される、と未来を描いたのだけれど、これが現実になるのかもしれない。

今はまだプログラムを書ける人間と書けない人間の差は生まれていない。いや、目に見えないだけで、生まれているのかもしれない。得ている人間は黙っているだろうし。私程度のちょっとしたプログラマでのスキルの有無による現実への格差影響を恐れているのに、まったくスキルのない人間たちがそれをまったく想像していないのも恐ろしい。金の卵を産むガチョウを作れない人たちが、なぜ、平気でいられるのだろうか。その不満が顕出したときプログラマ攻撃を始めるのだろうか。

2016-06-03

プログラマだけどゲームを作ろうと思ったことがない

俺はゲームをやるのが好きだ。

小さい頃は何度ゲーム機を親に隠されたか覚えていない。

でも作ろうという気にはなったことがない。



プログラミング趣味ではじめた。

今は給料をもらってプログラムを作っているが、趣味としてもまだしっかり続けている。

それでも無い。

ゲーム系と便利系(?)では使う技術が違う(正直あまり知らない)から、まず入門の敷居の高さというものがあるんだが、

そもそもやってみたいなあ(願望)みたいなことすら思ったことが無い。

作りたいものが無くなってしまったとしてもゲームは多分作らないんじゃないだろうか。

俺は趣味プログラマとしては変なんだろうか。

2016-05-28

仕事である案件に関わっているのだが、癖の強いプログラムを書く人間があまり仕事をしないので困っている。そういった人間案件を動かすことにうまくいった事例、もしくは失敗談などあればご教授いただきたいです。

プログラマ中年と呼べるぐらいの年齢

・この案件を一人で丸抱えすることでプライドを保っているようだ

バグ修正指示書を出しても、やるやると言ってやらないことが多々ある

・現状、サービスが不便なので、もっとユーザーの使いやすものにして喜ばれるもの提供したい

・売り上げをもっと上げることももちろん目標

・社内のプログラマ(実力も実績もある)が修正するよう幾度か進言しても聞く耳を持たない

おだてつつ改修に向かってもらうよう試みてみたが、元々調子に乗っていると言っていいような状態だったため、特に良い方には動かず。

社の意向としても改修したいのだが、わかりづらいプログラムなのでおいそれと手出しできない状況。

他にやることもないのにバグ修正もあまりせず、ユーザーへの配慮もできないのならば、別の部署に異動するなりして欲しいが、今のところそれは難しい。

せめて仕様書を書き、別の人間も触れるようにして欲しい。

仕事である案件に関わっているのだが、癖の強いプログラムを書く人間があまり仕事をしないので困っている。そういった人間案件を動かすことにうまくいった事例、もしくは失敗談などあればご教授いただきたいです。

プログラマ中年と呼べるぐらいの年齢

・この案件を一人で丸抱えすることでプライドを保っているようだ

バグ修正指示書を出しても、やるやると言ってやらないことが多々ある

・現状、サービスが不便なので、もっとユーザーの使いやすものにして喜ばれるもの提供したい

・売り上げをもっと上げることももちろん目標

・社内のプログラマ(実力も実績もある)が修正するよう幾度か進言しても聞く耳を持たない

おだてつつ改修に向かってもらうよう試みてみたが、元々調子に乗っていると言っていいような状態だったため、特に良い方には動かず。

社の意向としても改修したいのだが、わかりづらいプログラムなのでおいそれと手出しできない状況。

他にやることもないのにバグ修正もあまりせず、ユーザーへの配慮もできないのならば、別の部署に異動するなりして欲しいが、今のところそれは難しい。

せめて仕様書を書き、別の人間も触れるようにして欲しい。

2016-05-21

パナマ文書 恵比寿西関連

3者のシェアフォルダー

パナマ文書データにある日本関連と思われる情報のうち

所在地が「恵比寿西」の情報報道目的で整理しておく。

 

パナマ文書震源地となったモサック・フォンセカにつながる

オフショアひとつに、GLOBAL TRADING OF ASIA LTD.がある。

https://offshoreleaks.icij.org/nodes/10088362

そこには判明しているだけで

3者のシェアフォルダーいたことがわかっている。

そのうち次の2者は、マレーシア所在地としている。

 

GENJI HASHIMOTO ゲンジ ハシモト

NO. 8-2, JALAN 1/76C DESA PANDA JALAN KAMPONG PANDAN KUALA LUMPUR 55100 MALAYSIAマレーシア 郵便番号55100 クアラルンプール ジャランデサパンダン、1/76C NO.8-2

https://offshoreleaks.icij.org/nodes/12170494

 

上記の場所実在する。

カフェ食品店、カラオケ屋などが密集している商業地域のようだ。

ゲンジハシモトは日本名に見える。同姓同名の人物は実在するが、

偽名の可能性は高いだろう。

 

HONG HENG SOON

NO. 45 JALAN SS2/74 47300 PETALING JAYA SELANGOR MALAYSIA

 

この名を持つ人も複数いるようだが、偽名の可能性も高い。

所在地実在する。

SS2/74は二階建て低層住宅が多い通りだが

セキュリティがしっかりした家が多く、自家用車が2台以上ある家が普通にある。

マレーシアの中では富裕層向け住宅地だろう。

その地域には華人も多く住んでいるようだ。

 

日本シェアホルダー

GLOBAL TRADINGのシェアホルダー最後の一者は

日本渋谷区恵比寿西所在地がある。実在住所だ。

 

TRANSPORTS CORPORATION トランスポーコーポレーション

COM-BOX 3/F; 1-32-16 EBISU-NISHI SHIBUYA-KU; TOKYO JAPAN

日本東京都渋谷区恵比寿西1丁目32番地16号COMーBOX(コムボックス)3階

https://offshoreleaks.icij.org/nodes/14036402

 

このCOMーBOXという名前ビルには

グーグルストリートビューインドアビューがあり、

入口エレベーター前の全方向画像を見ることができる。

(撮影対象になってる貸ブティックは3階の企業ではなく別会社)

1階ホール入り口前にテナントプレートがあり、

次の二社がビルの三階に入っている様子を目視できる。

地下1階から7階までがテナント

8階は空きテナント居住空間だろうが現時点では不明

 

緯度 35°38'50.79"N

経度 139°42'19.24"E 

渋谷区恵比寿西1丁目32番地16号COMーBOX

https://goo.gl/maps/een3qetbXMk

https://goo.gl/maps/rEVmqUeUW2v

 

3階

トーヨービバレッジ株式会社

株式会社フェリス

 

もちろんこの二社以外に、

過去にCOMーBOX3階に別な企業があった可能性もある。

国税庁法人番号公表サイトで「東京都渋谷区恵比寿西1丁目32-16」を

過去データを含めて検索すると、22団体法人がヒットする。

が「TRANSPORTS CORPORATION」という法人は予想通り見あたらない。

 

国税庁法人番号公表サイト

http://www.houjin-bangou.nta.go.jp/

東京都渋谷区恵比寿西1丁目32番16号 を所在地とする法人一覧

1011001060345 ルシエシード (1階?)

1011002012262 (地下1階)

4011001000208 アイズ

4011001004836 桜武

4011001055433 TUI Solutions

5010001151514 フェリス

5011001050417 アステラ

5011003000535 (地下1階)

8010701023745 トーヨービバレッジ

8011001008057 コスモ

8011001020879 ベリーグットマン

8011001090591 DI.テクノロジー

8011001096993 プログラマティカ (4階?)

9011001070270 (4階)

9011001102759 ベストインクラスプロデューサーズ(5階?)

8011001049712 プロデューサーズハブ

1011001049990 (7階)

9011001046031 (4階)

2011002022913 (6階)

2011001044669 (5階)

3010401101673 (5階)

9011001109580 日本デー取引所 (4階? 平成285月2日所在地変更)

 

(法人登録パナマ文書情報整合しない会社法人番号と階数のみ表示。

ビル看板で階数が異なることを確認できるものは番号とテナント名と階数を表示。

ウェブ上のデータから階数が異なることを推定できるものは階数?を表示。)

 

これらの企業モサック・フォンセカとの契約者や関係者である

可能性があるという点で、どれも疑わしい。

だが、シェアフォルダー所在地であるCOMーBOX3階に

入っている法人は以下の二社であり、

とりわけマスコミなどから注目され急成長しているのは

トーヨービバレッジ株式会社だ。

 

http://www.houjin-bangou.nta.go.jp/henkorireki-johoto.html?selHouzinNo=8010701023745

http://www.houjin-bangou.nta.go.jp/henkorireki-johoto.html?selHouzinNo=5010001151514

 

パナマ文書(GLOBAL TRADING OF ASIA LTD関連)まとめ

 

MOSSACK FONSECA & CO. (SINGAPORE) PTE LTD.
          (パナマ法律事務所課税回避の元締め)
            ↓↑              ↑
            ↓↑              ↑
  GLOBAL TRADING OF ASIA LTD.(バージン諸島登記)   ↑
        ↓   ↓   ↓           ↑
        ↓   ↓   ↓           ↑
 GENJI HASHIMOTO   ↓   ↓           ↑
(在マレーシア架空名)  ↓   ↓           ↑契約?
      HONG HENG SOON   ↓           ↑
  (在マレーシア架空名)    ↓           ↑
        TRANSPORTS CORPORATION        ↑
        (在渋谷区恵比寿架空名)         ↑
            ↓               ↑
      所在地が同じ↓現住所            ↑
        トーヨービバレッジ株式会社      ↑
                   (実在企業代表熊谷聡)

トーヨービバレッジとはどんな会社なのか

トーヨービバレッジ株式会社は、デイリーヤマザキ

ファミリーマートサークルKサンクスローソンミニストップ

などのCVS向けに、カフェラテなどのカップ入り飲料を卸しているSCM企業

 

この会社過去にさまざまなタイアップ商品を開発している。たとえば

デュラララ!!ゴールデンエッグス、藤井リナ神楽坂茶寮、作山若子、

DHC、とある魔術の禁書目録マイメロディボノボチョコレート

Mrs. New Yorkショコラティエマサール、フェルクリン、よしもと、

ジャルジャルヒルトン小田原リゾートスパ総料理長水口雅司、

阪神タイガース、めしとも、とくダネの御瀧政子などとタイアップしていた。

この他にも、朝ズバッ!洞爺湖サミット、町村農場など、政治色のある

タイアップ製品もある。

(町村農場北海道衆議院小選挙区5区で長く衆議院議員をやり衆議院議長

も務めた故・町村信孝実家。先月この選挙区で町村一族地盤を継いだ

親族候補者補選当選したのが記憶に新しい)

 

http://www.toyobeverage.co.jp/contents/hp0012/list.php?CNo=12

 

トーヨービバレッジがパナマ文書の示す契約者と関係があることを示す物証

現時点では見つかっていない。

が、急成長したトーヨービバレッジが採用している

サプライ・チェーン・マネジメントという経営手法が、

最新流行の高収益事業であるのは事実だ。

 

社名 トーヨービバレッジ株式会社

代表者 代表取締役社長 熊谷

所在地 〒150-0021 東京都渋谷区恵比寿西1丁目32番16号 

TEL 03-5459-7066 FAX 03-5459-7067

設立 2006/6/2

資本金 3,000万円

顧問 横山千尋<バリスタ日本初代チャンピオン

取引銀行 三井住友銀行 りそな銀行 三菱東京UFJ銀行

販売日本アクセス三菱食品

http://www.toyobeverage.co.jp/contents/hp0005/index.php?No=6&CNo=5

React.js界隈の人に聞きたい

**誰かみんなの主張のまとめを作ってくれないですか?** (まあそれこそお前がやれよって話かもしれないので、誰もやってくれなかったら私がしますが。。)

最近JQueryはもはや不要でReactさえあればOK,みたいな記事をよく見ますね。

論旨としては、どうせトランスパイラ使ってるんだからもっと便利な書き方しようぜ!ってことなんだと思います。(virtual DOMがメインだ!という話もあったけど、じゃあ何でReactなの?というのは聞きたいかな。メジャーから?)

ただちょっと個人的違和感が拭えないので聞きたいです。

ちなみに私は昔coffeeとbackbone.jsか何かで業務用のページ(SPAではなかったような気がする)を作るお仕事をしたことがありますが、フロントエンドエンジニアというわけではないです。どちらかというとサーバー管理とかのほうがよく知っていると思いますが、Javascriptもそれなりには書くくらいの感じの人です。Reactは不幸にして一度も触ったことがないので、以下の文章はすべてコードサンプルをみたうえでの感想です。

そもそも世の中にそんなにSPAがあるのか

まずこれ。正直そんなにたくさん動的にがりがり書き換えているページをあんまり見ない気がするんですよね。その上正直そういうウェブページ、あったとしても大体使いづらいです。

世の中のページが全部FBならいいのかもしれませんが、具体的にはどんなところで使ってるんでしょう。業務ページとかですか?あと、なぜSPAにしなければいけないのかもよくわからないです。画面遷移するのだめなの?という感じで。

JSXを使うことに抵抗ないんですか?

トランスコンパイラを使うのって、結局「将来的には全部ES6になるのだから、今のうちからES6で書いておけば将来のメンテナンスコストとかも減ってうれしいよね!」っていうことなんだと思います

こういう例、JS以外にもいろいろあって、例えばboostAndroidのsupport library, Pythonのfrom __future__ importなどなどあると思うんですが、どれもやっぱり将来的なコストを見据えて、非標準のライブラリ記法を使いましょう、ってことですよね。

でもJSXってそういうのじゃないじゃないですか。いわばsupport libraryを使うのとmonoで全部書くのと、位の違いがあるように見えます(そこまでは違わないかw)。そういう考察を一切入れずに、「どうせトランスパイラ使ってるんだから拡張記法使っちゃおうぜ!!」っていうのはかなり危ういように見えます

そもそも、JSって結構独特な言語ですよね。もちろん今はnode.jsとかあるわけですけど、まあやっぱりスクリプト言語の標準の座ってPythonRubyですよ。世の大多数の人はそっちのが使いやすいとおもってるんでしょう。ということでそもそもトランスパイラ通すんだったらもっと普通言語から変えるようなソフトウェア流行ってもいいんじゃないかなあとか思いますけど、そういうのがないのも謎です。dartとかどうなってるんですかね。(まtypescriptとか一種それだという話もあるか)

五年後のビジョンがありますか?

五年、十年あとにReact.jsって流行ってるんでしょうか。例えば五年前はcoffee script結構流行ってましたけど、たしかもうサポート打ち切りとかになっちゃったんですよね。もちろん営利企業がバックなので、そこまで急になくなるかはわからないですけど、五年したらみんなまた別のライブラリがすごい!!みたいに言ってるんじゃないでしょうか。

まあだからこれはフロントエンドエンジニア業界全体の問題なのかもしれませんが、そういう将来的な保守コストをどう考えているのかが気になります特にもし業務ページであるなら、せいぜいがなるべく枯れたライブラリ(≒JQuery)と、テンプレートエンジンあるいはフォーマットストリングでも使ってpure ES6で書いたほうがいいんじゃないでしょうか。そうすると結局SPAにはしないですよね。

まあこれを突き詰めるとじゃあetaxもactivexで、銀行システムcobolで、マシンはpc98で、、、とかなっちゃうかもしれないんで、難しいところではあるとは思いますが、、、



とりあえずこんなところで、有識者の皆さんよろしくお願いします。



追記

React.jsでした。angularと混ざりました。。あと特に喧嘩売ってるつもりとかは全くないですがそう見えたらごめんね。

id:murishinai 主張は単純で、せいぜいES6+トランスコンパイラ(+JQuery)とかでいいんじゃね、遷移はサーバー側でやったほうが楽じゃない?という感じです。

id:wordi virtual domが最大のメリット、ってのはよく見る意見ですね。例えば実際どんな場面で(どのくらいの規模のプログラムで)domの改変コストが効いてくるのか、みたいな実例を教えてくださると助かります。(もちろんFBとかはそうでしょうけど、もっとなんだろう、身近な例でお願いしたいです。)なんかReactががりがり(かつユーザー目線から見て有効的に)使われている例がイメージ出来ないのが問題な気がしてきました。

id:logic ええっと、それはそうなんですけど、なんだろう。標準のもので、少なくとも今後10年はあるだろうと言うもの(たとえばES6+フォーマットストリング)があるのにも関わらず、今後5年持つかもわからないライブラリを全面に押し出すの、ちょっと怖く見えるなあという気持ちです。

id:erukiti 具体的に頭の悪い点をご教授くださるとたいへんありがたいです。小規模だとそもそもvirtual domメリットもなさそうですし、ES6標準でええんちゃうのんという気がしてならないのですが。

id:manaten もちろんFBGMailJQueryだけで作るのは不可能だと思います。だからFBはReactを、GはAngularを作ったのでしょうが、逆にそんなに気軽に使うようなものにも思えないのですよね。それこそ何百ブクマも付くのやべえなあ、と。(ところで私にはReactよりAngularJSのほうがずっと気持ちよく見えます

トランスパイラですねごめんなさいw

SPAが使いづらいってのは言いすぎかな。正確には、「ページ遷移型のUIに比べて、SPAであることのメリットが明らかに生きているページって少なくないですか?」ということです。もちろんFBとかGとかtwとかは例外だと思いますけど、DOM1000個とか10000個とかいじくり回しているページばっかあるようには思えない。もちろんどーーしてもSPAじゃなきゃダメなんだっていうならこの手のライブラリを使うといいとは思うんですが、どっちかというとニッチ需要じゃないでしょうか。

あとなんか保守点検に関する意識ちょっと違うのかなっていうコメント散見されたんですけど、うーん、一発書いて書きっぱなしっていう案件そんなにあるんですかね?ちょっとそこがよくわかんないです。一度書いてもやっぱりn年先、さらもっと言えば自分がその職場からいなくなった後のことまで考えてプログラム書くべきだと思うんです。そうすると、例えば数年後のプログラマにとってのReactは今のprototype.jsになってるかもしれない。そういうリスクが怖いです。勉強すればいいじゃんっていう意見もそうなんですが、なんでしょう、どちらかと言うと保守を気にしているので、そっちじゃないです。まあ幸いにして私は人の書いたJSをいじくり回した経験はないので、ただの推測なんですが。

それともしかしたら「枯れた技術」あるは「標準化」という意識あんまりないのかなとも思いました。まあ確かに「Web世界日進月歩!」ってことなのかもしれないんですが…。別のページのブコメとか見ても、「枯れた技術を使う」=「不勉強」みたいなのがあって、不思議です。。

あとcoffeeのころ、っていうコメントありましたが、あの頃はみんな夢がありましたよね。AltJS世界を救う!みたいな。翻って今はどうか。それを思うと、やっぱり何でもかんでもReactじゃ、という意見には違和感を感じるんですよ。

増田に書いたのは単にみんなが見てくれるというだけの理由です。そもそも今諸般の事情お仕事としてのエンジニアはしていないですし。ほんとに純粋質問だと思ってもらえればうれしいです。

まあ長くなってきたので私のブログにまとめ直してもいいのですけど。

そういえばモバイルという話も出ていましたが、先日のandroid instant appsって、アレ「HTMLモバイル向けに軽快なリッチUI作るの無理だからやめような」ってことかと思ったんですが、どうでしょうか。もちろん今現在必要ですけど~。

2016-05-20

http://anond.hatelabo.jp/20160520151221

俺は書いた本人じゃないから違うかもしれないけど「限度」ってのはプログラマ能力的に、ってことじゃないの?

必要情報引数で全部渡して、中で書き換える(副作用)じゃなくて、結果は新たな状態として受け取るって、理屈ではすっきりしてるじゃん。

原理的に書けない処理があるとは思えないけど。

http://anond.hatelabo.jp/20160520122114

岡部健

元・FX商材販売者にして

人類史上最悪の勘違いプログラマ

らしい。

自分思い込みが正しいと信じて、その珍説ネット書籍に書きまくってるせいで

プログラミングクラスタ係争中。

一般プログラマ増田の俺から見ると「岡部氏、よそでやってくんねーかな」です