「コンポーネント」を含む日記 RSS

はてなキーワード: コンポーネントとは

2017-09-06

最近リア充の間でボードゲーム流行っているようで、

元々ボートゲームが好きだった自分の家に遊びに行っていい?と言われたので遊びに来てもらった

んでもってうちに来て重いコンポーネントゲームを見て「うわきも」って言うのな

ほんとなんなんだよこいつら

2017-07-25

やっぱ大手SIerって馬鹿だわ

大手SIer下請けベンダーに出向してる。

HTMLCSSjQueryでシコシコモックアップを作る。

百歩譲ってこれはまだいい(コンポーネント志向皆無とか後々Smarty移植することをまったく考えてないとか言いたいことはいっぱいあるが)。

その後、レビューにあたって説明資料なるものを作る。

Excelキャプチャを貼り付けて動作記載するのだが……。

なんで動くものが目の前にあるのにわざわざ文字に起こすんだよ。

動いているの見ればいいだろうがよ。

更新するボタンを押したら何が起こるのかわからいから動きを書け?

ボタンを押下したら対象データ更新する」

それでいいのかよ! 見ればわかるだろうがよ!

ちなみにこの後、この説明資料を基に画面設計書を作成する。

そしてまたレビューを行う。

この工程が分かれている理由不明

やっぱ大手SIerって馬鹿だわ。

2017-05-28

きのうはグラブルを再開しようと思ったが

増田でなぜかそんなことよりゲームでも作れと言われUnityダウンロードした

プログラミング等の知識は何もない

とりあえず画面にオブジェクトを配置して

配置したオブジェクトに色んなコンポーネントを付け足していくことでゲームが出来ていくということはわかったので

人型のキャラクターを配置しC#コピペつぎはぎスクリプトコンポーネントを作り

何もない世界の中をキーボード操作で動くキャラクターを作ることが出来た

C#スクリプトの中身はコピペつぎはぎで理解度ゼロなのでここは課題だが

作業してて楽しかった

続くかもしれない

2017-05-15

Microsoft の Fluent Design System って

既存のUWPのUI周りにいくつか新しいコンポーネント足してリネームしただけっぽいんだけど、違うかな?

最近MSによくある「ドキュメントがいろいろ用意されてるのになんか分かりづらい」っていう典型な気がする。

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-05-22

「Reactは大規模SPA用途以外はコスパ悪い」っていう先入観意味不明

しろweb制作入門用に最適だと思う。

個人的な考えは以下の通り。


UI構造がおおよそのコード構造と一致する

そもそもコンポーネント指向ライブラリからチュートリアルからして構造化を基本において書かれてるのが入門用にこそ適していると思う。

だって初心者の頃jQueryで場当たり的にコード追加していって九龍城みたいになったこと、あるでしょ?

もちろん自分で間違いを犯してその痛みを知るってのも方法論としてはありかもしれんけど、

DOM操作抽象化したライブラリから入って、徐々に具体的なところに落とし込んでいくのが効率的じゃない?


しろ小規模案件にこそ導入して「構造化とコード再利用」を意識づける

ライブラリ自体構造化を念頭に置いてるから自然とパーツごとに作るようになって、

その次の段階として自分の作ったパーツの再利用を考えられると思う。

jQueryで場当たり的に(以下略


抽象化の高いレイヤーから入って抽象化の低いレイヤー学習範囲を伸ばすべき

jQueryってホントに何でも出来るからキチンと扱える技術を既に持ってる人には良いだろうけど

やっぱ初心者には逆に指針がぶれやすいと思うんだよね。

チュートリアル書く人にもそれぞれ別の方法論があって、

しかもその振れ幅が広くて、どの方法論もそれなりに意味がある場合が多い。

正解が沢山ある問題をいきなり解かせるんじゃなくて、

まずは答えがある程度決まってる問題から入って、徐々に馴らしていくべき。


jQueryWebフロントエンド界隈のアセンブラだと思う

最初に手を出すには抽象化の度合いが低すぎるというか、

ある程度経験を積んだプログラマーこそが手を出すべきと言うか。

だってアセンブラ機械語がなくなってないのと同じように

webからDOMの直接操作不要になることもないと思う。

どんなに抽象化が高度になっても、裏でやってるのはDOMの直接操作なんだから

でも、大事な基礎技術からといって、それだけで済ませて技術革新放棄するべきではないでしょ

しろ抽象化の高いところから入門して、基礎技術に触れる必要が出来てから触った方が理解が早いと思う。


から初心者や小規模案件にこそReactを!

と、私は考えます

2016-05-21

http://anond.hatelabo.jp/20160521163144

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

http://anond.hatelabo.jp/20160521163144

最近某所で、React使うとjQuery不要だ的なタイトル記事を書いちゃた気がするので一応反応しときます。長文ごめんね。

えーととりあえず、あのタイトルは実際のところ省略しすぎであり、もちろん本来は「場合によってはjQuery不要」「jQueryは要らないこともある」と長く書いた方が正確です(本文ではちゃんとReactが万能ではない説明をしてる)。でも多少釣りっぽいタイトルの方が読まれるようなので反省はしていない。

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

世の中の絶対数は知りませんが、自分脳内ではもう「ページ遷移しない方がずっと楽に開発できてユーザ体験も向上するのに、敢えてそうしない理由がない」という至極単純な話なので、そこは悩むところではないです。ページを複数作り、<input type="hidden">とかセッション変数とか駆使する面倒ごとは、書かないでいいなら二度と書きたくない。

というか、ちゃんと書かれたSPAは使っていてSPAであることにそもそも気づかないので、「SPAから使いづらい」という主張はよく分かりません。GitHubTwitterサイトSPA的なことをしている故に使いづらいでしょうか。偶然タブを開いてたので調べたらそうだったから紹介しますが、例えばWebpackのドキュメントサイトは(Reactではないけど)SPAで、ブラウザMarkdownレンダリングしていますhttp://webpack.github.io/docs/ )。サーバサイドで動くスクリプトタスクゼロ個人的にはこういう使い方で十分嬉しいです。

何にせよReactのメリットが真に活きるのはある程度の規模以上だと思うので、小規模で導入してjQueryより短くならないことは普通にあります自分中の閾値としてはJSコードが数百行超えるならもうReact使う。

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

んー、要するに「別物であるDartCoffeeScriptは許すけど、ES6で書く以上はES6外の独自構文を混ぜるのは許さん」という主張だと解釈したのですが、そういうことですか? 正直その主張を聞いたのは初めてです。歴史的JSXとES6は完全に独立して発明されました。最近になってBabelが両方同時に扱えるようになりましたし、Babelはまさにそういう拡張性を重視しているツールです。それは「ああ便利になったね」というだけの話であり、なぜ「ES6とJSXは混ぜるな危険」となるのかよく分かりません。現にこれが最も標準的で人気の組み合わせです。

JSXを使うことへの抵抗」ということなら、とにかく見た目にコレがキモいと感じる人が非常に多いのは事実です。現に、JSXより見た目がキモくないことを売りにしている仮想DOM実装一定の人気を博していたりします。でもそういうライブラリは「キモさ」軽減のために結局新たな構文やら独自コンパイラやらを編み出して柔軟性を犠牲にしていますJSXは「関数呼び出しのシンタックスシュガーJavaScriptに1個導入するだけで問題を概ね解決する」というシンプルかつ一番表現力の高い解決方法だと思います仮想DOM思想に逆らわない最も素直なやり方であり、将来長持ちする気がしています

はい所詮JSXシンタックスシュガーなので、使いたくないなら使わず本来関数スタイル仮想DOMを書いてReactを使ってもいいです。タイプ量が増えて若干見づらくなるだけなんで。

それと、JSXじゃなくてテンプレートでいいじゃん的に思っているようですが、テンプレート仮想DOMでもなければJavaScriptでもないので、速度や機能の面でReactがやっていることに遠く及ばないと思います

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

Reactはもう登場して3年経過して未だに勢いが増していますし、日常で困らないレベルコンポーネント集も揃っています。React-Bootstrapはいいぞ、心が豊かになる。そろそろ採用してもアーリーアダプターとも言えんでしょう。むしろ真に先端を見るのが好きな人に言わせりゃ、2015年なんて「Reactが淡々成熟していくのを見ているだけの、つまらない年だった」みたいな感じらしいですし。

Reactは現時点で既に3年に1回レベルのビッグウェーブであることは疑いようがなく、「これが10年に1回、つまりjQuery以来のビッグウェーブなのかどうか」については、そう信じている人と懐疑的な人がいる、という状況です。私はAngularもCoffeeScriptも「3年に1回」レベルに感じたのでスルーしましたが、Reactには「10年に1回」の方になりうる素質を感じています個人の感想です)。将来もっと凄いものが出るとしたって、それは「ベターjQuery」ではなくて「ベターReact」でしょう。通常は「3年に1回」レベルでも試したり仕事に使ったりして構わないと思いますが、10年に1回の技術でなければ使わない主義の方は、あと2~3年待てばよいと思います

保守性に関して言うと、Reactは典型的な「ひとつの事だけをとても上手くやる」系のライブラリです。考え方のコツさえ掴めば、記憶すべき要素はjQueryやAngularと比べても圧倒的に少なく、むしろそこらのテンプレートエンジンを覚える方が面倒なくらいです。10年後に見ても何をやっていたのか30分で思い出したいというのであれば、むしろAngularとかよりReactを採用すべきだと思います

jQueryからReactに移ろうとしてる自分個人的理由

http://anond.hatelabo.jp/20160521163144

内容から誰が書いてるかわかるかもしれんけど、まぁスルーよろしく。

jQueryもそんなにガッツリ使ってるわけでもないし、Reactはまだリリース前の調査下地作りの段階だけど

正直言ってjQueryに戻るつもりは毛頭ないぐらいReact便利だと思ってる。

でもjQueryを捨て去れるかというとそれも無理だと思ってる。

その辺のことを適当に書いてみる。


用途

社内サポート的なことやってて、サポートテンプレート対応を省力化するために

Webツール作って人が対応するコストを減らすために使ってる。

チーム組んでガッツリ大規模ツール開発ってわけでもない。

jQueryで一つツール作ってリリースしてそこそこ人的コスト削れたのはよかったと思ってる。


jQuery脳内DOMリーとの格闘に疲れ果てた

最大にして一番の理由がこれ。

そんなに大規模なアプリケーション作ってるわけでもないし、関係者も俺一人だけど正直DOMリー脳内でくみ上げるのに疲れた

500行もいかないようなショボいコードでも脳内DOMリーと格闘するのしんどい。

DOMリー触るほうが楽ってみんなどの程度のコードでそんなこと言ってんの?

そんなスーパーハカー揃いなの?信じられないんだけど。


React-Bootstrapかいう神コンポーネント出会った

オリジナルbootstrapはどうしても頭に入ってこなかったし、手を付ける気にもならなかったけど

React-Bootstrapマジで楽だし、スッと理解できる。マジ最高。

Bootstrapってこっちを本筋にすべきじゃね?と割とマジで思ってる。

まだ触って3日も経ってないけど。


ページのほぼすべてがjsに集約できる

これはちゃんとしたWeb界隈の人は利点と思わないのかもしれないけど

一人でいろいろ賄わざるを得ない俺みたいな人間にとってはマジで楽。

ベースHTMLにはベースのdiv一個載せとくだけで後は全部js

レイアウト大元コンポーネントでReact-Bootstrapで組んで、あとは各コンポーネント

個別に作っていけばいい。

HTML見て、CSS見て、JS見て、っていちいち記述方式の違うコードを見る必要がないのは

少なくとも俺にとっては一番楽。


でもjQueryも完全には捨てられない

やっぱまだReactはコンポーネントがそんなに揃ってないんだよね。

からjQueryも使わざるを得ないけど、それも一つのコンポーネントに閉じ込められるから

管理が楽。

極力なくす方向で行くつもりだけど、今はまだ両方使ってる。


JSXは汚くて気持ち悪いけど、コードで書くのはもっといから仕方なく使う

あの気持ち悪いコード考えた人はマジでいい意味でも悪い意味でも頭イカレてると思う。

気持ち悪くて仕方ない。いまだに大嫌い。

でも書くコード減らせて楽なんだよね。だから仕方ない。

どんなに気持ち悪くても、結果が伴う以上使う。


5年後なんて自分の姿すら思い描けないことは考えない

5年後も自分がこの仕事やってるかどうかもわからんからそんなこと気にしたことない。

今ある仕事をなるべく早く簡潔に実行するために最適だと思ってるツールを使ってるだけ。

それがかつてはjQueryだったし、今も一部jQueryだし、大半がReactになろうとしてるだけ。

将来まだこの仕事やってて、もっと有用ツールがあればそっち使う。

別にツールにこだわるつもりは毛頭ないから。

Web界隈の人はもっと真剣考慮すべきかもね。


ちゃんとしたWeb界隈の人のちゃんとした意見も見たい

俺みたいな一人前にすら届いてない奴の意見なんぞ必要ないだろうけど、

自分の今の考えを書いておくと後で見返せるかなと思って適当に書いてみた。

ちゃんとしたWeb界隈の人にとってこの辺の問題ってどんなもんなんだろうね?

みんなも増田ポエム、書こう!

2016-05-07

React.jsウェブフォーム

お問合せや購入のウェブフォームって別にGoogle検索結果に表示されて欲しい訳じゃないから

HTMLを毎回書くよりもReact.jsとかのコンポーネントベースで作れば使いまわせるから楽だよね、サーバーサイドに依存しないし。

サーバーサイドではバリデーションと問い合わせ完了の処理だけやれば良いし。

ウェブフォームを作るのに特化したjavascriptライブラリないのかな。

2016-04-26

OAuthのことを1ミリも知らない俺が

OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324

http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html

OAuth がうまくいかない理由と、既存サービスゼロデイ攻撃方法

OAuth とは

認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。

OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。

おことわり

前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。

言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたお気に入りOAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。

また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法OAuth を使っているサービス利用者であっても、また自ら OAuth ベースサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。

記事の構成

この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。

この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。

この前書きのあとは、まず OAuthセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。

その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。

最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。

責任ある情報公開

いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーOAuth ベースサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースシステムの主要なセキュリティ欠陥は非常に蔓延しています。

筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。

というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。

ここで言及されている情報やリンクされている情報は今のところ既存のサービス悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のもの破壊するのではなく改善することを目指してください。この記事は、自社サービス不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。

想定する利用形態

この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。

まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。

ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッショングループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。

ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。

ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的営業部門メンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。

問題点

セキュリティ関連
認証情報の盗難 / アクセス権の詐称

トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティアプリサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:

上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。

さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:

  1. ユーザサードパーティアプリ/サービス (たとえば AFCP) を訪ねて、特定のサービスと統合したいことを知らせる。
  2. AFCP は、EVS でホスティングされた特別なログインページを出してユーザに EVS の認証情報を入力させる。
  3. EVS は、その指定したアクセスレベルユーザが本当にサードパーティ (AFCP) へ与えたいのか確認する。
  4. EVS は AFCP に一種のトークン (複数の場合もある) を提供し、各種 API コールに使えるようにする。

このトークンユーザの認証情報ではありませんから、そしてひとりのユーザひとつアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。

この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。

(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)

(略: そうした詐欺を企業自体が後押ししているような風潮もある)

(略: スタンドアロンアプリなら、ログインを詐称する必要すらない)

この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザ組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は?

クライアントアプリユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザインストールするネイティブアプリすべての信頼性に自分で責任を負う。

さらに

クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。

基本的に言って、OAuthセキュリティガイドラインは、OAuth を利用する開発者ユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。

私の知る主要な OAuth ベースサービスはほぼすべて、ここに概説した手法で攻撃可能です。

OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください! 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者管理者に「OAuthもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。

OAuth サービスに偽装

OAuth ベースサービス設計でよく見かける間違いは、ブラウザ用に、パラメータひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリサービスユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローOAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。

「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。

EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に FacebookGMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebookユーザは全員 GMail に対して Facebookのもののふりをすることができてしまうということです。

この問題は、OAuth エンドポイントユーザウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。

ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。GoogleOAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローひとつあります:

client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)

Citrix もこんな間違いをしています:

(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)

Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースサービス開発者でさえも似たような状況で潜在的ヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。

サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービス一般的にいって独自の「SDK」を提供しており、サードパーティ開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。

この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアント機密情報を取得する脅威」に分類されています。しかしサーバウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームOAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレード参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。GoogleOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントウェブブラウザベースアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフロー標準的ブラウザ用のエンドポイントコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、 このエントリーをはてなブックマークに追加ツイートシェア

2016-04-16

ブルースクリーンを初めて見た若者お話

あこがれの英字キーボードを手に入れたから早速会社パソコン接続してみた。会社パソコンWindows 7解像度メモリCPU悲劇的な支給パソコンをなんとか使えるレベルで動かしてくれる頼もしいやつ。

「カシュカシュカシュ」

う〜ん、シングルクォーテーションとダブルクォーテーションがうちやすい! あとアットマークシフトを押しながら入力するのは新鮮かな。

「コトコトコト」

スペースキーが広い! 打ちやすい! ついつい連打しちゃうキー配列になれるのは時間がかかりそうだけどハッカーみたいでかっこいい。だけどちょっと、ううん、かなりストレスフルなことが一点あって、日本語入力しようとしたらキー配列JIS配列なっちゃうんだ。いちおう英字配列にはキーコンビネーションで切り替えられるんだけど、キートップの印字とちがうじゃない。ほら '*' が '(' だったりさ。


今思えば英語入力にわりきって使えば良かったって思うよ。でも往々にしてわりきるのって無理でしょ。


こまったときグーグル頼み。グーグルさんに日本語キーボードパソコンで外付け英字キーボードを上手く使う方法はないのって聞いてみた。そうしたらいろいろおすすめしてくれたから、まあ、このくらいの苦労はしないと英字キーボードを買った意味はないよねって、というかこっちから苦労を買ってやろうって、ふふんと思いながらいろんなページを確認したの。業務中だったけど。


それで、レジストリを書き換えてやればいいって書いてあるページを見つけた(http://blog.heiichi.com/?eid=792239)。書き換えるのは

パス : HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/i8042prt/Parameters
キー : LayerDriver JPN, OverrideKeyboardIdentifier, OverrideKeyboardSubtype

か。でもレジストリエディタってなんか使いづらいし、怖いなあ。おっとそういえば業務デファクトスタンダードアプリ Excel で、拡張コンテキストメニューから「読み込み専用で開く」ためにレジストリを書き換える PowerShell スクリプトを作ったんだっけ。マイクロソフトオフィスアップデートするたびにレジストリ書き換えられるもんだから、あたまにきて作ったんだっけ……。

New-ItemProperty -Force -Path 'Registry::HKEY_CLASSES_ROOT/Excel.Sheet.12/shell/OpenAsReadOnly' -Name ddeexec -PropertyType String -Value "[open("%1",,1,,,,,,,,,,,,1,,1)]"

よっし、エンジニアならコンポーネント再利用だな、ってスクリプトコピーしてぺたぺた(スクリプトは超危険なので割愛!)。パスをかえて、値はこれで、そうそ現在の設定を確認して英字配列日本語配列自動で切り替えるようにしたいな、むふふ、なんてつなげたばかりの英字キーボードですくりぷとすくりぷと書いていたの。


そんで実行。エラーか。ふむふむああええおお、パスまちがえちゃった。


こんどこそ実行。エラーなく終わって、ちゃんとキー名前と値が入っている。さてさてそれでは再起動しましょう。


「ブイーン」


これ面倒なんだよなー。ハードディスク暗号化解除っと。あれ、起動画面に移らないなあ。メモリチェックが走っているのか。ふーん。


……おわらないんだけど………………………………………………。おそるおそる画面をみたら、


Windowsが起動できませんでした。システム管理者に連絡してください。」


うっわーーー。ブルースクリーンだーーー。はじめて見たーーー。本当にブルースクリーンででるんだなあ。

正直このときラピュタをみつけたパズーの気分だったかも。ぼくの場合はこの先にはわくわくなんてなかったけどさ。だんだん、やべー、これやべー、これやべーや、これすごくやばいよね、って正気にもどった。そんで隣のお仲間にバレる前に強制終了。ふう。多分再起動だっておもってくれたよね。

だいじょうぶだ Windows軍用にも使われる堅牢性の高い OS だ。これくらいのエラー普通再起動したらいつもと同じように退屈な起動プロンプトがでるはず。そうやって自分をまず信じる。それが一番大事

まずは軽い深呼吸。そして電源オン。


「ブイーン」


ハードディスク暗号化解除は BIOS レベルから変わらないのか。Windows は予期されない終了をしたって? そのとおり! 気にせずに君はいものように平常心で起動してくれたまえ。


ブルースクリーン RETURNS!!!


あかんわ。これ完全にあかんわ。二回起動して二回だめって、これなんかいやってもダメパターンはいったよね。エンジニアのはしっくれだけどそれくらいはわかる。

とりあえず電源を落として、気持ちを落ち着かせるために散歩しよう。ああ、今日は雲がきれいだなあ。風もふいていてはるだなあ。どうしよ。ぼくも答えはわかっていたんだけどね。管理部にごめなさいしてリカバリ DVD をかりてくればいいんだよね。でもさ、ただの箱になったパソコンお客様のものっていう派遣立場だしさ、絶対に原因追求でレジストリいじったことを告白させられるしさ、ああなんか春と秋ってにてるよね。

あとさブルースクリーンになった原因もわかったの。ふいにあああれだなって思い浮かんだんだけどさ、スクリプトかいまわしちゃったせいで OverrideKeyboardSubtype キーの型を DWORD じゃなくて String にしてたのよ。ぜったいにこれで起動シーケンスで致命的エラーはいてんだろうなって。

そんな風に思いながら、自席に戻って、もう一回電源起動。もう一回よく画面を確認する。……むむ自動修復だと。よかろう最後の望みだ。かなえてやろうじゃないか。へー最後に記録した正常状態システム復元するのか。なんか説明書きに「最近インストールしたプログラムとか消えるかもね。ハハッ。」て書いてあるけど、しばらくインストールなんてしていないし、初期状態に戻んなかったらまあいいよって感じ。ポチッとな。


そんでもって三十分から時間経ったかなあ。あまりにも時間がかかるからトイレの個室で頭をかかえてたの。自席に戻るとパソコンの電源が落ちているわけ。さてとこれはラストチャンスだ。なんのチャンスかわかんないけどラストであることはあきらかだよね。そして電源をいれた。

この時ばかりは神様に祈ったね。だって計算機プログラムしたようにしか動かないから、お祈りなんてしても意味ないもんね。だから神様にお祈りしたの、どうかおねがいします、今後はこれにこりてレジストリなんてぜったいにいじりませんので、この計算機が正しく動くことを祈ってくださいって。


結局、無事復旧できた。なにひとつ異常なく Windows 7 は立ち上がって来て、みなれた壁紙がでてきた。おそるおそるレジストリ確認したら、ちゃんとぼくがいじくるまえにもどっていた。ありがとう Windows! ありがとう自動修復機能! いちおうありがとう神様


教訓



おまけ1

それでも外付け英字キーボード日本語入力したいんだーて人はここらへんを見たら幸せになれるよ。

USB英語キーボード付けた。(英語日本語キーボード共存、KeyboardTypeOverride) 202122 (http://202122.iku4.com/%E3%83%91%E3%82%BD%E3%82%B3%E3%83%B3/%EF%BD%95%EF%BD%93%EF%BD%82%E8%8B%B1%E8%AA%9E%E3%82%AD%E3%83%BC%E3%83%9C%E3%83%BC%E3%83%89%E4%BB%98%E3%81%91%E3%81%9F%E3%80%82%EF%BC%88%E8%8B%B1%E8%AA%9E%E3%80%81%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%82%AD%E3%83%BC%E3%83%9C%E3%83%BC%E3%83%89)

USBポートに対しての設定だからブートで失敗することはないと思うよ(ブルースクリーンを発生させたもののことば)。


おまけ2

いちおうこれを書くにあたって、自宅のパソコン Windows Vista再現できないかためしてみた。検証内容は以下の二つ。

  1. ちゃんと正しい設定をするとブルースクリーンが発生しないか。
  2. 原因と思われる DWORD と String の間違いを検証レジストリキーの型を DWORD から String に変更したらブルースクリーンが発生するか。

結論としては両方とも大成功! ちゃんとレジストリエディタから編集したら、英字キーボード日本語入力が快適にできるようになったし、 DWORD を String に変更したらブルースクリーンがでるようになったし! Vista だと会社Windows 7 ではできた自動修復ができないし! なんかブートセクションとデータセクションが分けられるようになったのって Windows 7 かららしいし!


だけどここは会社じゃなくて自宅だから、メイン OSUbuntuWindows 領域マウントして華麗に chntpw を叩いてレジストリを修復できる。そう Linux ならね。

2016-03-28

http://www.slideshare.net/KenyaKodaira/2016-59970832

なんかたくさんブクマされてますが、読む必要ないと思います

p.4
  • HTML Template Engin`d`ってなんですかね。誤字脱字チェックはしましょうね。
  • gulpのgは小文字なのでよろしくです。
p.5
p.6
p.8
  • EditorCodingってなに
p.9
  • コードブロックが見づらいっす。黒バックにblueて誰が読めるのだろうか。若者か。
  • npm install後に急にgulpって書いてあるけど、それは何をするタスクなのです?
    • まぁ、この後gulpタスクについて出てるんでしょう……
      • 出てこなかった
p.10
p.15
p.16
p.18

コード品質が維持される場合に限り、難読化、最小化、コンパイルするのは自由です

  • HTMLの話ですよね? コード品質が維持されない難読化や最小化やコンパイルってなんだろう。
  • あとに出てくるけど、CSSには容量削減を異常に求めすぎてるわりには、HTMLには無関心な感じがするんですよね。
p.19

a、span、imgなどの最小の位置にでは開業は適宜対応

  • その適宜が人によってブレるから、それを潰すのが「フォーマット」だと思うんすよね。
  • いっそ「新しい要素が出現したら必ず改行する」くらい言ってほしい。
  • あと日本語が変なんで、それも。
p.20
p.21、22
p.2324
  • .editorconfigにどう書けばいいかをだな……。
p.25
  • HTMLルールだとしたら、そういう開発の都合のコメントを残して納品するのはお行儀が良くないっすね。
  • Jadeを使う前提のようだし、Jadeコメントでの話をしてるなら別にいいんすけどね。
  • でもさっきからJadeのサンプルが全く出てこないからオッサン不安になってきちゃったっす。
p.26

正しいHTML

  • HTMLの正しさとは?
  • 参考リンクから察するに、invalidでなければいいと思ってるなんてことはないっすよね。
p.27、28
p.29、30
p.31
p.32
p.36、37
p.40

CSS教科書

p.42、43
p.44、45
p.49、50
p.57、58
  • HEXの短縮は規定しなくていいと思います
  • ビルドをかける前に勝手に置換されるような仕組みを入れるべきところかと。
  • gulpでできますし、ググれば出てきます
  • ちなみに、#f00よりもredの方が1バイト少ないんですよ。
  • 容量削減は人が思いつきでやるには不十分なのです。
  • そんなのはビルド時に機械がやればいい。
  • 容量の削減を理由に人の行為制限をかけるのが愚かな行為だと気付いてくれたらうれしいっす。
p.61、62
p.63、64
p.71
p.72、73
  • FLOCSSとMindBEMding共存させるなら、書くべきことが足りなすぎませんか。
p.73

block__element__elementは使用しない

p.78、79
p.80、81
p.87

GoogleChromeなら変換時に右側にマーク

p.96
p.98

svgにすることで1つの画像でまかなえる場合svg使用する

p.102
  • ここまで4回くらい読みなおしたんですけが、どうにも上澄みだけの理解しかしてないように感じるんですよね。
  • Jadeについては何かルールは設けないのでしょうか。
  • JavaScriptについては……?
  • そのほかにも、ライティング自体が下手すぎて、これを人に見せるのはどうなのっていう感じがしちゃいました。
  • 誤字脱字くらいはちゃんとチェックしたほうがいいでしょうね。
  • 結論:いろいろ惜しいけど、よくなる余地はたくさんあるので、がんばってください。

2015-09-18

MethodInvoker を使って、Invoke メソッドを1ラインで書く

ワーカースレッド(この場合Task)からUIスレッドコンポーネント(コントロールなど)へアクセスする。

class AppliForm {

void SomeCall(){

var itemName = "hoge";

System.Threading.Tasks.Task.Run(()=>

{

this.Invoke(new MethodInvoker(() => listViewMe.Items.Add(itemName)));

}

}

}

例によって、Goes To (=>) は、半角化してくらはい

2015-08-10

http://anond.hatelabo.jp/20150810121732

このメソッドを使用して、新しい Process コンポーネント配列作成し、ローカル コンピューター上で同じ実行可能ファイルを実行しているすべてのプロセス リソースに関連付けます。 GetProcessesByName はシステム リソース作成するのではなく、システム リソースアプリケーションで生成された Process コンポーネントリソースを関連付けるため、プロセス リソースがあらかじめコンピューター上に存在していることが必要です。 processName には、現在ローカル コンピューター上で実行されていない実行可能ファイル指定できるため、メソッドが返す配列は空のこともあります

プロセス名は、プロセスの表示名 (Outlook など) であり、拡張子 .exeパスも含みせん。 GetProcessesByName は、同じ実行可能ファイルに関連付けられたすべてのプロセスの取得および操作に役立ちます。 たとえば、実行可能ファイル名を processName パラメーターとして渡し、その実行可能ファイルのすべての実行中インスタンスシャットダウンできます

プロセス Idシステム上の単一プロセス リソースに対して一意ですが、processName パラメーターで指定したアプリケーションは、ローカル コンピューター上の複数プロセスで実行できます。 そのため、GetProcessById は最大 1 つのプロセスを返しますが、GetProcessesByName はすべての関連付けられたプロセスが格納された配列を返します。 標準 API 呼び出しを使用してプロセス操作する必要がある場合は、識別子でこれらの各プロセスを照会できますプロセス名だけではプロセス リソースアクセスできませんが、プロセス リソースに関連付けられた Process コンポーネント配列を取得することによって、システム リソースの起動、終了、および操作を実行できます

2015-05-25

ボードゲームネットゲーム

ボードゲームやりたいけどやる人がいない」と言うと

ネットで対戦したらいいじゃない」という人が必ずいる

だけど俺がやりたいのはあくまでも

【人と対峙して実際のコンポーネントを触りながらやるボードゲームカードゲーム含む)】なんだ

ボードゲームネット対戦ルールは同じでも【ネットゲーム】なんだ

原作と実写ぐらい違うんだ

2015-03-17

http://anond.hatelabo.jp/20150316195608

はてぶコメント見たらTEditorの名前があった。たしかにあのコンポーネントが多くのエディタを生み出していた。自分テキストエディタじゃないけどTEditorを使ったアプリ書いてたので良く覚えてる。

しかし開発環境低価格化/無償化する今、未だに一番廉価なStarterでも2万円超するDelphiを選んでしまった作者たちは今何を考えているのだろうか。

それとも未だDelphi8あたりの無償版を使い続けているのだろうか。

2015-02-15

初めてのロードバイク購入ガイド

このテキスト予算20~30万ぐらい出せる人を対象としてます

シマノコンポーネントの完成車をターゲットにしています理由は私がカンパ/sram使ったことなから

コンポーネント105が付いている

最近カーボンフレームにフル105で20万以下も多いので、この辺から考え始めると良いでしょう。このテキストはこのあたりを検討している人に向けられたものです。ボリュームゾーンなのでお得なモデルが多いし、後々ステップアップする場合でも不満が出にくいです。

注意が必要なのは、一部105ではないパーツが付いている完成車。

よくあるのが、ブレーキが某メーカーの低グレード品や、クランク/チェンリングが某メーカーの低グレード品など。これらの完成車はあまりおススメしません。特にブレーキ重要で、105以上のグレードを強く推奨します。安いブレーキは雨にぬれると全力でブレーキレバーを握っても止まりません。あなたが握力の少ない女性なら死にます基本的ロードバイクは雨の日に乗るものではありませんが、突然の雨に襲われる可能性は否定できません。

できればカーボンフレーム

あなたが若くて体力が有り余っているスポーツ経験者であればフレーム素材はなんでも良いでしょう。そうでなければ柔らか目のカーボンフレームターゲットしましょう。細かな振動に長時間突き上げられていると想像以上に消耗します。高額なレース向けカーボンフレームアルミ並に固いモノもあります。傾向として安いカーボンフレームは柔らかい味付けになっていることが多いです。

スチールは非常に魅力的なフレーム素材ですが、うるさ型のフリークが多いのでここでは触れません。

サイジン

ある程度自分で調べたうえで、ちゃんとしたショップ相談しましょう。20万円はロードバイクとしては安物の部類ですが、多くの人にとって安い金ではないはずです。1件のショップ見立てだけでは不安なら2件以上回りましょう。

2サイズ選択可能なら小さいほうを選ぶことをおすすめします。サイズの調整はサドル位置、シートポスト交換、ステム交換、ハンドル交換で行うことになります。大きいフレームを小さくしようとすると弊害が多いです。ポジショニング自由度が下がり、理想とされるペダリングが可能なポジションを取りにくくなります

また、クランク長がオーバーサイズだとペダリングスムーズに行えないうえに膝を痛める可能性もありますチェンリングコンパクトおすすめです。初心者向け完成車はほとんどコンパクトだと思いますが。クランク長とチェンリングについては十分に調べてから購入されることを推奨します。

冬も走る?

あなたが1年を通して走ろうと考えるなら、ウェア類に10万ぐらいかかります

ウインドブレーク系ウェアが不要なら5万ぐらいです。

なので、始めるのは春~夏が良いでしょう。必要なウェアが少ないからです。

レーパン/ジャージ/ヘルメット/シューズ/グローブ/サングラス

これでまあ5万円だとちょっと足りないかなという感じでしょうか。レーパンは安物を選ぶと後悔します。メジャーメーカーからちゃんと試着して選びましょう。めんどくさがって試着せずに購入すると後悔します。

冬用のウェア類はけちると死にます

ショップって。。

わかります。変わり者店主の個人ショップは多いです。大きなショップは知識/経験が少ないバイトが多く不安になります。大きいところ小さいところ、いくつか回ってみるしかありません。気長に波長があうショップを探すことです。信頼できる顔見知りショップが近くにあると、メンテナンスに関する不安が格段に減ります

自分で調整やパーツ交換をやるのは悪いことではないのですが、信頼できるプロに調整してもらうと乗り味が変わります。また、初心者(に限りませんが)は誤ったメンテナンスを行う可能性を否定できません。

はいえ、あまり神経質になる必要もありません。死なない程度にメンテナンスされていれば良しとするのであれば、行きつけのショップなどなくても困りません。ロードバイクを扱っている全国チェーン系ならロードバイクの調整はしてくれます

携帯

予備チューブ/携帯ポンプ/タイヤレバー/レンチキット

最低これらは必要です。夜走るならライトも。後は金です。前後輪外せば普通タクシーで家に帰ってこれます。まずは"トラブった時に家に帰ってこれるか?"という視点携帯品を選択しましょう。

パーツ交換

完成車購入後、サドルやステム、ハンドルは交換する可能性が高いです。スタイルが固まらないうちに気に入らないからと言って次々変えるのもどうかと思いますが、いろいろ試してみることも重要です。また、完成車はペダルが付いていないので、ペダルは買うことになります105完成車ならペダル105で良いでしょう。

ケツ痛に悩んでサドルを次々に購入する人がいますが、まずは自分スタイル/ポジションを疑いましょう。レーパンの中にパッド付パンツをはくという手もあります(パッドが厚くなれば痛みがなくなるとは限りませんが)。サドルは柔らかい/固いよりも幅の広さと盛り上がり方が重要になります

また、タイヤをけちると楽しくないことを付け加えておきます

メンテナンス

チェーンは頻繁にクリーニングすることになりますチェーンカッター必要です。またはチェーンにコネクスリンクをはさみます。車体につけたままのクリーニングは大して綺麗になりません。外してディグリーザーで洗います。チェーンルブはいろいろありますが、高いものではないので試してみて好みのものを見つけましょう。ワイヤー類は伸びるのでブレーキディレイラーは調整が必要になります。この辺は自分でできるようにならないと何かと面倒です。最初ショップで教えてもらうと良いでしょう。

そのうち、プーリーのグリスアップなんかも必要になりますが、それはだいぶ先なのでその時。

バイクは綺麗に保ちましょう。ロードバイクのかっこよさは、値段の高い安いではなく、クリーニングされているか否かで決まります

故障

自転車ではありません。あなたです。あなたが30歳以上のデスクワーカーであれば、膝の故障には十分気を付けてください。

具体的には、クランク長が適切か?サドルは高すぎ/低すぎないか?サドルは前/後すぎないか?ハンドルは遠/近すぎないか?

そして、走り出してしばらく(5-10分ぐらい)は重たいギアを踏まないように!

タイミング

春に走り出すことを考えると、春に検討したら遅いです。そろそろ考え始めましょう。そして取り扱いメーカーの多いショップにちょくちょく見に行きましょう。全メーカーが一斉に出そろうわけではなく、バラバラに店頭に並びます。そしてあっという間に売れて、やたら大きいかやたら小さいフレームが残ります。なんとなく気に入って、サイズ的に無理が無ければその場で決断することも重要です。そのバイク自分に合うか否かなんて初心者にはわかりません。2台目以降で考えましょう。

2014-12-08

「既定のインターフェイスは COM 参照可能ではありません」

warning : タイプ ライブラリ エクスポータで '%1' を処理中に警告が出されました。警告: 既定のインターフェイスは COM 参照可能ではありません。」

たぶん、Visual StudioでCOMコンポーネントを開発している諸君であろう。

interface が public になっていないので、公開できず参照可能でないということだ。public interface ... と宣言すれば警告は消える。

2014-11-26

C#VBA向けの.NETライブラリ(COMコンポーネント)を作成するには?[C#]」に追記

http://www.atmarkit.co.jp/fdotnet/dotnettips/1064combycs/combycs.html

足りないぞ。

クラス定義で、属性

[System.Runtime.InteropServices.ClassInterface(System.Runtime.InteropServices.ClassInterfaceType.AutoDual)]

をつけないと、メソッドが公開されない。

大御所でも、未検証コードを載せるんだな。。それとも俺がちゃんと従っていないのか?

もしくはバージョン環境設定によるのか?こちとら、Visual Studio 2013 で C# 使っているんだけどね。

2014-11-21

http://anond.hatelabo.jp/20141121100002

レビューって「指導」じゃないだろ。本人が見落としてるところを他人の目でチェックするとか、本人があまり詳しくないコンポーネント相互作用する可能性があるからそのコンポーネントの方が分かってる人にチェックしてもらうとか、そういうのじゃないの? そういう目的がはっきりしてるなら手段は何だっていいんじゃね? レビュー普通にやってた職場ではgitコミットweb上でコメントつけられるようになってたけど、便宜上紙と赤ペンでやっても本質は変わらんでしょ (仕事でやるなら効率悪いけど、その時だけの代替手段というなら)。

コードを読む力の判定にはある程度使えると思うな。実務では他人コード読んで手を入れないとならないことは多いわけだし。それに面接で使うなら、それは「レビューの正解」を求めてるんじゃなくて、コラボレートしてコードを書いてゆくことにどう臨むかってのを見るわけだから、悪くない方法だと俺は思った。

2014-09-25

昨今のPC向けWebブラウザの現状(主要ブラウザ編)

うPC向けWebブラウザは、進化する余地がないのか、停滞しているように思えてしょうがない。

IEはともかく、FirefoxデザインChromeにしちゃったし(あれのどこがいいのやら)、Chromeに至っては、停滞どころか悪化しているとさえ感じる。

主要Webブラウザは、どこへ行こうとしているのだろうか。

IE

IE8になってようやくWeb標準に従うようになって、IE9JavaScriptが劇的に速くなり、IE11でかなりWeb標準準拠度が改善された。

また、Windows XPサポート終了により、IE6というWebデザイナーの多数を地獄送りにしたブラウザから完全に脱走できるようになった。

しかも、サポートポリシーが変わって、2016年1月以降は各OSで最新のバージョンしかサポートしないと決まったため、思ったよりも早くWebデザイナー苦痛が取れるようだ。IE6で懲りたんだろうか。

しかし、IEコンポーネントブラウザ互換性を軽視する傾向にある。

IE10では、Windows7必須アップデートのせいで画面描画が乱れる場合があったり、特定WebサイトIEコンポーネントブラウザフリーズさせるという必殺技を披露した。

IE11では、一部環境DOMストレージが原因でブラウザコンポーネントを十数個開くとフリーズする新必殺技を披露した。(現在バグ修正済)

次のIEでは、どんな技を披露してくれるのだろうか。

Firefox

Chromeをパクってと同様、高速リリースサイクルになって3年目。

アドオン互換性に悩み、自ら失敗といいつつも、高速リリースサイクルを何とかやっていけてるようだ。

シングルプロセス/マルチスレッドながら省メモリJavaScriptの速度チューニングを着実に行っている。

つい先日、australisというChromeパクリに非常によく似たUI強制適用し、一部ユーザーから顰蹙を買う

※筆者はあまりFirefoxを使ってないので、ここまで。

Chrome (Chromium)

高速リリースサイクル強制アップデート流行らせた元凶。

Chromeは初期設計ポリシーがよく、HTML5準拠度とブラウジングスピードは今でもよい。

登場からあっという間にシェアを獲得し、主要ブラウザと呼べるほど有名に。

しかし、バージョンが上がるたびに肥大化し、メモリ消費量がますます増え続け、低スペックマシンでは重くなる一方である

レンダリングエンジンWebKitから独立してBlinkになったが、さらに迷走していく。

迷走その1: Aura

ユーザー阿鼻叫喚した、ウィンドウシステム共通化プロジェクト

理想は、各種コントロール(スクロールバーやボタン、エディットボックスといったもの)を全プラットフォームで共通化した上で、GPUによる描画で高速化する・・・ということだった。

Windows版ではバージョン32から適用された。しかし、安定版になってもスクロールバーの矢印が消えた、汎用マウスジェスチャが使えない、

縦/横スクロールがまともに動かない、Webフォントが描画されないなどなど、多数のバグが残存していた。

今でも、バージョンが上がるにつれて改善されたものもあれば、一度改善していたのに不具合が再発するなど、安定版といいつつ安定しない日々が続いている。

いったい、「安定版」とは何なのだろうか。

迷走その2: Google色が濃厚に

最近ChromeGoogleのものであることをユーザーにしらしめる努力ばかりやっているのではないか。

Google Nowなど、自社のサービスを便利に使うために機能追加するのは別にかまわないが、新しいタブページの異常にでかいGoogleロゴはどうだろう。

よく開くページのサムネイルを小さくし、下に追いやってまでGoogleロゴを目立たせる必要はあったのだろうか。

迷走その3: NPAPIプラグイン廃止

今年中にNPAPI廃止を目論んでいるが、それは現実的なのだろうか。

Chrome独自に持っているPPAPIは、セキュリティが厳格なゆえにNPAPIの代替手段には決してなりえない。少なくとも、PPAPI上で動くFlashがNPAPIのそれと同等の速度で動かない限り、廃止はありえないと思う。

高速リリースサイクルの弊害?

Firefox高速リリースサイクル採用した初期の時のように、高速リリースサイクルを優先するあまり品質犠牲にしているケースが目立っている。

最近出た37では、DirectWrite周りの実装がお粗末で、安定版が最初に出たころはズームイン/ズームアウトするだけで文字が表示されなかった(翌日に修正)。今でも、ビットマップフォントの表示品質GDIよりも悪い。

高速リリースサイクルの弊害が現れているのではないだろうか。このことに、Chromium中の人たちは、気づいているのだろうか。

ひどい。最近Chromeはほんとにひどい。

2014-04-08

システム」とは境界

なんか最近オブジェクト指向関係の記事や書籍紹介を目にするような気がするのは、新学期が始まったせいなのかな。

オブジェクト指向がよくわかんない、という人は、いったんオブジェクト指向を忘れて、「システム」とはなんぞやという基本の基本を確認することをおすすめする。

Wikipediaシステムの項(https://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0)の図(https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:System_boundary.svg)を見てほしい。

外部環境(Surroundings)において境界(Boundary)が定義されるその内部がシステム(System)なのである

境界こそがシステムを具現化するものであり、要するにシステムの内部はおいといて、境界を通じてシステムの内部と外部でどのような入出力(インターフェース)があるかのを定義するのがシステム定義なのである

これが決まってはじめて内部をどのように構築するのか、サブシステムコンポーネント)間の連携をどうするのか、という話になる。

英語版のページにはしっかりとこう記載されている。

We scope a system by defining its boundary; this means choosing which entities are inside the system and which are outside – part of the environment.

日本語版の項にはなぜか訳されてないが、これが本質的定義であり、システムときいたら即「境界」と思い浮かべるべきである

そんなの当たり前じゃんと思われるかもしれないが、たぶんシステム関係に携わっている多くの人が、「システムって何?」ときかれたら、

 「システムはいくつかの要素によって構成されるもので、その全ての要素は、他の要素に影響を与え・・」

と、いきなりシステム内部の機能的な説明を始めると思う。まず境界インターフェースの話から始める人はむしろ少数だろう。

そうでなければ、世の中に数多あるシステムの「要件定義」「システム設計」「機能仕様書」などトップレベルでの記述もっと明確かつトップダウンになってなければおかし・・・

話をオブジェクト指向に戻すと、

最近話題になっている記事などは、なるほどよく噛み砕いているなあ、とは思うんだけれども、言語・実装・モデルといったものにひきずられてしまって、本来は広い分野や局面における「システム構築の手段」の広い概念であるはずのオブジェクト指向、実装例や用語から再度説明するという堂々巡りをしているという感じがする。

システムの本来の意味が身についたら、オブジェクト指向で説明されているあれやこれやが、このシステムを実現するため手段にすぎず、効率的システムを構築し、サブシステム再利用を容易にするための仕組みや方法論をあるていどまとめて総称したものであることが自然理解できると思う。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん