ここ最近技術系のイベントいっても記事に起こさない事が多いので何の為にメモとってんだろうな となりつつあったし、
今まとまった時間とりやすいので、久し振りに書いておきます。
こないだ『サーバーサイドエンジニアオールスターズ in 関西』にも行ったので、何か書けばよかったな。
]]> 後ろの方の畳スペースは段々になってたんだけど、前の椅子スペースの後ろの方に座ったら、ディスプレイの位置的に割と見づらくなってしまったので失敗した。
左右の画面つかないのかなぁ。
畳スペースにいたヒヨコ けっこう固くてしっかりしていた
スライドは多分そのうち上がるので、感想的なものが中心。
クローバのサーバーサイドで行っている音声処理とその下地になる音声解析のモデル作成(機械学習)の話し。
○音声認識
まず最初に引数として 音声と単語列を突っ込んでる式が示されてて、最初の段階で単語列なんて定まってるもんなの? っと思ったんだけど、
「単語列」って言葉から想像するような規模感のものではなくて、想定される単語全部の莫大なリストっぽい。
入力された音声は、音響モデルを使って 個々人の個性を削ぎ落した特徴量のデータに変換され、そこからアルファベット1音ずつの音素に分解され、
前後の音と組合せた tri-phone というデータにして言語モデルに渡す。
最終的にその言語モデルが、「日本語らしいもの」を導き出すのだが、これを機械学習で学ばせていくのが音声認識揮発の主体になるようだ。
音響モデルのほうは、マイクとか背景音がかわらなければアップデートされないし年に2度程度。1回の生成には1週間以上かかる。
一方、言語モデルは新語なんかも取り込むので毎週アップデートされていく。
言語モデルの中身は数千万オーダーの単語列。
1工程に1日とかかるし、分散処理がしずらいのでhadoopを使えない部分もある。
評価用のテストデータもめちゃくちゃ多くて、並列化しててもそこだけで1~2日かかる。
結果として1週間に1度更新するスケジュールはかなりカツカツらしい。
○デコーダー
機械学習は莫大な時間をかけて莫大なデータを処理するが、実際にスマートスピーカーに音声が投げられた時に処理するのがデコーダー。
こちらはユーザーにすぐ反応を返さないといけない為、最長数百msecオーダーの音声認識を低レイテンシで返す。
性能と速度はトレードオフな部分があるので、速度を優先して精度を下げる事もあるみたい。
・性能改善
モデル再学習で副作用が大きい物は別処理する。
→ドメイン(専門用語)モデルなんかは別でやったものをマージする。
(特にスマートスピーカーは音楽関連の機能豊富だから、アーティスト名なんかの芸能関係の名詞はゴリゴリにやってそうよね
間違えやすい単語や発話に対する処理(デコーダー側でスコアをみて切り分ける
ノーマライゼーション(乃木坂フォーティーエイト→乃木坂48のような表示のノーマライズ
誤認識をどこの問題か切り分けてフィードバックする などなど
○質疑応答
Q. 吃音症とかもひろえるの?
A. 特徴的な人や子供の表現が難しい
モデル化されてる元データが平均的な男性のボイスを元にしているので、そこから大幅にズレるものは精度が落ちる。
(これ元のセット複数持って、初動であてるモデル切り替えたりみたいなのできたらいいんだろうけど、現状でもリソースやばいの考えると何個もモデル持つのはきつそうだなぁ
っと思ってたらその質問出てきた
まず初動で子供どうか とか知るのが結構大変っぽい(ステップ増やすとレイテンシに影響でるだろうしな
特徴量にする前に捨ててる情報をつかえばできるかもしれないとの事。
(声紋みたいな認識あるけど、あれって速度どうなんやろな。
(個人的にはスマートスピーカーって不特定多数の人が使うシーンよりも、同じ端末からは特定のグループの人しか話しかけない気がするので、そこでパーソナリティ絞るみたいなのはできるんじゃないか?(抜本的な話しではある)
(実際 google アシスタントとか、本人以外の声からの命令は無視する機能とかあった気がするし、ドアの開錠とかセンシティブな機能を提供する時には必要よねぇ
「サーバーサイド」って銘でいきなりアカデミックなサイドの話しになったなぁと感じたが、
確かにクライアントでやらない事は全てサーバーサイドなんだよな......という意味ではくくりが難しいのかもしれない。
途中は英語でやるっぽいので、みよたさんが翻訳しながら。
基本的にはクリスさんが何故サーバーサイドが好きなのかと、LINE のサーバーインフラが何で構成されているか のお話し。
別のイベントでお聞きしたことがあったので、メモは取らず。
docker はいいぞ!みたいな感じ
Kubernetes の話しもっと聞いてみたくはあるけど、技術的に興味あっても個人的に触る事はなかろうな と思うので難しい。
クリエーターズマーケットとかやられてたらしいのでお世話になっている。
箱ペンギン - LINE スタンプ | LINE STORE (宣伝)
今はLIFF(LINE Front-end Framework)のバックグラウンドをやれらてるそうです。
フロントエンドフレームのバックグラウンドという表現の複雑さ。
まったく知らないでもないので、あまりメモらなかったけど LIFF は LINE 上で動く web アプリのプラットフォームで、
LINE の画面にオーバーレイして動く小さなブラウザみたいな感じで、HTLM と JS と CSS で動く。
普段クライアントは talk サーバーの通信してるけど、その間で LIFF のサーバーが動く感じ(?)で、LIFF サーバーがトークン取得したりメッセージ投げたりの API を叩くっぽい。
(これLIFFサーバーにアクセスしてるけど、開発がアップしてんのは静的なファイルだから js が動くのはクライアントよな、悪意があるスクリプトとか動かないのかな
(そもそも動いてるjsのバージョンがどんなもんで、どんくらいサンドボックスかされてんだろうか
→懇親会で聞いてみたけど、普通に WebView で動いてるっぽいので、JS のバージョンは端末に依存するし、破壊的な事されても View だけの事っぽいかな。
LIFFに許可可能な権限はユーザー情報の取得とメッセージの送信の2つだけ
(友達とかは追加できないんだな(悪用されたら怖いが「最大n名の友達を追加する許可」みたいなのできればおもしろそう。 その人数追加しきった所で権限失効する感じで
・Kotlin
ここから kotlin の話し
スライドあったけど null 安全最高!みたいな話し以外はほぼ全部はしょられた
kotlinのコードについていろいろしゃべりたかったが 全部はしょられたけど、軽く Coroutine にもふれた
ロギングの話しにちょっと触れたあと LIFF の v2 の話し。
まずブラウザで動かす事ができるようになったので、開発が凄い楽になる模様。
権限的に許可している人のリストから個人やグループにメッセージ投げれるデモ映像が出ててすごかった。
また、今までモバイルクライアントでしか動いてなかったけど、これだと PC 版でも使えそうとの事。
11月くらいに公開予定
サーバーサイド広いな......
あと、懇親感で色んな人と話した感じ、サーバーサイド専門って人ばっかりじゃなくて けっこう広範囲の人が来てるっぽかった
まぁそもそもインフラやってる人もアプリケーションやってる人もサーバーサイドなわけだし広いわなぁ
今後は9月にオフィスが移動するとして、8月はインターンとかあって お忙しいそうなので、次に何かやるとしても 旧オフィスさよなら会じゃなくて、新オフィス お披露目会になるかも?との事。
ちょうどインターンで8月から来られる という方ともお話したけど、オフィスの移動のタイミングでジョインするの大変そうだなぁ。
]]>言語そのものを気にいったのもあるけど、Android Studio の kotlin 対応の出来の良さと、アプリ実装のし易さが気持ちよかったので、そのまま本格的に勉強しながら アプリを一本作ってみました。
期間は丸一月くらいですが、法事と腸炎で10日ちょっと作業できない日があったので、実質20日弱くらいの可動日数ですかね。
方眼紙マッピング - Google Play の Android アプリ
もの自体は比較的簡単な構造のエディタアプリで、方眼紙状のキャンバスのセル1つ1つに、アイコンや文字を置いて色を変えて記録する為のものです。
昨年『The Witness』をプレイした際に、用途に適したメモアプリを発見出来ず、最終的に手書きのメモアプリに自分で線を引いてメモしたのを覚えていたので、題材はアレにしよう と気軽に決めた感じでした。
]]> まずぶっちゃけると、出発点は kotlin の勉強のつもりだったけど、どっちかというと Android の Layout & View についてと、マテリアルデザインについて学ぶ時間が大半だった。
kotlin(とKotlin Android Extensions) は確かに非常に書きやすいというか、Java でアプリ書く時に必要なお約束ごとを大量に省略できるので、コードがスッキリして良かったが、本来的には Java の実装を把握した上で、それを置き換えるような学習フローをとるべきなのかも。
いきなり kotlin から入ると、Android の実装を学ぶ為に大量に読む事になるであろう Java のサンプルコードが直感的に読み取れなくて大変つらかった。(そもそも Java も10年触ってねーしな......)
ただもう 今更 Java に戻して書き直す気もしないので、やっていく気持ちでやっていくしかないのである。
(Android Studio には高機能な Java -> kotlin 変換機能がついていて、Java のコードを貼り付けるとある程度のコードなら自動変換してくれたりするが)
さて Kotlin は置いといて、Android の実装自体は Windows Phone の実装と似た感覚で出来たというか、当時の xaml よりも 書きやすいしエディタも優秀で編集しやすいし Android Studio 様々だな っといった感じ。
WEB 開発者が取っ付き易いというか、ある程度似通った構造になってて、エンジニアの流動性が確保されてる感がある。
あと門外漢ながらアプリ全体のデザインもやらなければならない個人開発者としては、共通的なデザイン指標としてマテリアルデザインが存在している事に多いに助けられた。
この辺はデザイン的な素養次第なとこもあるけど、こーゆー指標みたいなのが無いと手探りで実装した上で見た目もダサい みたいな微妙なものになりかねないので、WindowsPhone アプリ作ってた時の Modern UI と同じく かなり楽させてもらった。
ただ実際に「こーゆー用途のメニューはココにこーゆー形で実装するのが望ましい」みたいな指標が明確な割に、その機能を実装する為の方法が公式で提供されてないケースが多々あってちょっと辛い。
サポートライブラリでカバーしてるものもあるが、その他には有志のライブラリにも助けられた。
この辺、SDKの世代ごとの変遷がけっこう激しいので、検索する時はある程度記事の時期を絞って参照した方が良い。
今回触れた技術的なトピックは以下
並べている Cell 1つ1つが独自ビューになってる。
canva 描画関係の色々なノウハウが学べた。
View の配置に関しては DOM に似てるようで、ちょっと違う所があるので 似たようなもんだと思ってやってると痛い目みる事がある。
各サイズにアイコンを準備する手間が省け、また表示サイズをあまり意識しなくて良い。
実際にアプリのアイコンも最終的に Inkspace で自分で SVG ファイル作ったりした。
デフォルトのテーマに組込まれているものなので特段変わった事はしていないが、undo/redoボタンの色変更時の再描画とかわりと癖があった。
Google Maps アプリとかその他大半のアプリで下から出るダイアログ変わりのメニュー的なもの。
今回はエディタの編集パレット的なものを全部ここに出している。
左側にメインメニューを出したり、チャットアプリだとチャンネル一覧を出したりなど、多彩に使われている片付けられるサイドバー的なもの。
今回はファイル関連のメニューを突っ込んだ。
SDK に組込まれているものは ボタン機能のみで、展開するメニュー等の実装方法は提供されていない為、サードのライブラリを使わせてもらった。
メニューがスッキリしたが、現状展開用のボタンのアイコンを途中変更する機能が無いので、
モード選択等に使いやすい UI なわりには current を示すのに使えない点が少し不満。(今は色だけ変えて対処してる)
Android は SDK が新しくなるにつれ、セキュリティ的な制限が厳しくなっていく為、やる事はシンプルだけど気をつける点は多かった。
画像をシェアなどでアプリローカルに保存した画像をシェアさせる所が詰まりがち。
実際のフォーマットは json と csv の合わせ技みたいになってる。
あと Android だと保存せず終了されるケースが多そうなので、オートバックアップ機能なんかも組み込んだ。
難しかった点についてはすでに書いたが、ここで Facebook と Twitter のフィシャル SDK の組み込みを行った。
実際に投稿するテストまでは行えたが、最終的に個別メニューとして置く事をやめ intent による共有に統一したため、ライブラリは削除した。
これはちょっとカスタムビューの勉強と平行するのは面倒くさかったのでライブラリに頼りました。
初期のズームサイズがビューがすべて入り切るまで縮小してしまう仕様に難があり、最終的にソースほぼ全部読む羽目になったので、果たして早かったのか遅かったのかは不明。
2本指スクロールに対応していない為、レイヤー機能実装の前段階で こちらのライブラリを自前で拡張する事になるかも。
アイコン画像の選択画面やファイルの一覧表示など、Adapter を使って流し込むのが大変楽でした。
データバインディングとは別で一方通行なのだが、出来れば Cell 全体のデータについて 二重のコンテナと結び付けてデータバインディングしたいのだが、少し根が深そう。
AdMod による広告表示を実装。
以前 ads SDK で組込まれていた所が、Firebase ベースに置き換え中のようで、
古い情報が混ざっているのでオフィシャルのサンプルみるのが一番良かった。
なお、広告はある程度ユーザーにバラつきが発生するまで配信されないケースもしばしばなようで、自分で見てみても全然表示されない。(test ad は見れる)
ビルドツールの設定から自動生成してライセンスを表示する為のプラグインなんかもあるんだけど、その辺選びつつ Qiita に記事書きながら cookpad さんのやつ組み込んだ。
Androidアプリにライセンス表示を埋め込むライブラリいくつか - Qiita
正直他の人どうしてんだろう?って所が気になる。
やらないといけない所だけど時間かけたくない所でもあるし、もっとノウハウあってもいい気がする。
今後組込みたい機能と技術トピック
広告を消すくらいしか提供できるものがないが、とりあえず組み込んでみたいトピック。
すでにアプリ内の文字列データに関しては 外部データ化しながら実装してあるので、言語パックを用意すればいいだけだとは思う。
海外向けにもリリースするとなると、ストアとかの表示もローカライズしないとなので、ちょっと準備がいりそう。
(組み込みの sample ファイルは言語に依存しないようにしてある)
公開直後に、ユーザー間で編集を共有できると使い方に広がりができるのではないか?というアドバイスをもらったのですが、
とりあえずスタンドアロンのエディタとして作ってる間には手を出せないけど、Firebase のサービスを使って Map データを共有できるチャット機能を組込むのは面白そうだな っと思ってます。
ただ、実際につかうと Firebase にどの程度データを送る事になるのか考えないと、無料アプリの運用で金が飛んでいく事になりかねいないけども......
現在、メインのビューへの操作は全て ZoomLayout が処理しており、スクロールとピンチ操作を処理しつつ、子ビューに伝播させるか判断しているのだけど、
これだと子ビュー側でスライド操作が利用できない為、範囲選択や線を描いたりといった操作が実装できない。
まず ZoomLayout を拡張するなりして、2本指スクロールを実装して、通常のスライド操作を子ビューで使えるようにする事。
その上で、マッピングした Cell の上にレイヤを置けて フリーハンドで書きこんだり、ラインツールで線を描けるようにしたいと思ってます。
こんなトコかな。
久し振りに土日もガッツリ開発にかけれてハマっていた楽しかった。
UI 回りは使いまわせる部分も多いし、同程度の規模の独自View詰んだエディタアプリなら、今なら1週間で仕上げられる気がする。
なんか面白いアイデアないかな~
]]>イベント行ってきたので、久し振りに更新。
今日梅田でやってた FRONTEND CONFERENCE 2016 に行ってきました。
最近はインフラ8割バックエンド2割みたいになってフロントエンド触る事もほぼ無いのだけど、
もはや js だけやれる事が増えてて、フロントエンドの敷居も広くて楽しそうよね。
興味はあるけど、ガッツリなんか勉強しようと家に帰ると ff14 を起動しちゃう というような毎日には、こーゆー腰すえて参加できるイベントがあると助かる。
]]> 現地にちょっと遅れて着いて基調講演聞きはじめたら、しょっぱな「インターン先の新サービスが先日リリースしました」って STEERS のサイトサムネイルが表示されてたんだけど、友人が関わってるプロダクトだったので、ちょっとビックリした(というか中継先の別室で一人ふきだしそうになった)
自分もシャツつくってみたけど、T シャツのクラウドファンディングみたいなサイトなので、元々の知名度の無い個人プロダクトだと
身内イベントに絡めるか、広範囲に売る前提でプロモーションしていかないとな感じはするけど、スタートが気軽にできて楽しい。
ここからは いつものスタイルで、セッションを聞きながらとったメモをベースに感想を。(詳細な内容は資料読めばいいと思う。
会場のアンケートに3セッション分の感想欄があって調度いい感じだったので、興味を持った3セッションほど。
(奥野 賢太郎さん - 資料 )
チャットワークの方なのでチャットワークの紹介から
導入企業92k...200地域... すさまじい...
前半はノンフレームワークな現行の WEB 版チャットワークを変えていく話し。
レガシーなコードを書き換える上で、フロントエンドチーム全員がES2015を習得済み という環境は羨ましくある。
AngularJS をプロトタイピングで採用していたので、そちらの導入もスムーズ。
どんどんチームで作業をする時の問題点の解決の話題に。
コメントは指針をもつ/意図を残す
→ そう書かざるを得なかった理由を明確にする
コーディングスタイルの統一は自動化(tslint)
・デザイナー連携
JS側にはスタイルを書かない
デザイナーがテンプレートをさわることがない
→ロジカルな設計にする必要があるので エンジニアがテンプレートを書く
(うちだとここまで切り分けできるテンプレートをエンジニア側が書けんな...
メンテしやすいよう BEM のライブラリを採用
axross/bemmer: BEM-like simple classname builder.
・デザイン仕様書の取り扱い
GitHub Wiki 全文検索できない 更新に気づけない
Markdown にして プルリク必須
(デザイナが git 使いこなしてる環境うらやましい
・単体テスト
盲目的なカバレッジ100%はめざさない
→変更の度に修正が必要なテストは メソッドのロジックが切り分けられていない
テスト内の負債を無視しない
・タスクランナー
gulp 属人化に気を付ける / 記述者を分散する
差分が見やすいように ファイルを分割、ワンライナーにせず改行をいれていく
・環境の構築
保守、ダミー、更新...だれが?
Ciが回る度に容量が許すかぎりデプロイして実行できる状態でのこしていく
非エンジニアも確認しやすい、バグも追いやすい
(おぉ...これやりたかったやつだ...
ストレスなくビルドできるように改善していく
・TypeScript と DDD(ドメイン駆動設計) が必要に
TypeScriptの型はチーム内で設計を共有するのに役立つ
大規模なシステムは覚えないといけない事が増えていく
→共通言語の定義
・型の恩恵
→一ヶ月後の自分は他人(あるある
コンパイラはドキュメントと違い嘘をつかない
@param に型をかかない 短いコメントをつけるくらいなら型で
型名厳格にすると IDE が活きる
テストで型を意識せずといいので ロジックの振る舞いに集中できる
・ドメイン駆動設計
完璧な実践は難しい(重い
→活かすために触れる
ユビキタス言語の定義
人によるブレを無くす
・フレームワーク
どれがオワコンか? という考えを捨てる
フレームワークの隆盛に影響されないアーキテクチャ
フレームワークを捨てられる状態を保つ
ロジックをapplicationドメインに
二槽式アーキテクチャ
フロントエンド内をフロントとバックエンドにわける
(ビューによったもの コアやアプリケーションによったもの
チーム全体がうまく回る 仕組み作り
管理がおいつかなくなる → 機械に頼ろう
-----------
うちはそこまで大型な開発ではないけど
チームで作業する上で導入したい事がやま程ある
チーム規模小さくても、その辺のフットワークが重いのは自分の力不足だなぁ...
(花谷 拓磨さん / http://webrunner.jp/ に後日関連する記事が上がるそうです )
タイトル通り HTML5 に存在する様々な API を使ってみた話し。
(色々触った中でも絞っての紹介)
冒頭は webstorage,indexedDB,webSQL あたりで、自分でも触った事がある範囲のお話。
webSQL は廃止されるので、それ以外の話しだが、まぁ個人開発の規模感だと webstorage が使いやすくていいよね。
・WebRTC
ブラウザ同士でリアルタイム通信をする為のAPI
(サーバークライアト間ではなくクライアントクライアント通信
IE/Safariは使えないが Edge は対応している
クライアント間通信の前にサーバーに相手を問合せないといけない為,シグナリングサーバーが必要になる
(ロビーサーバー的なやつね
実装範囲が低レイヤーなため スキルが求められる
シグナリングサーバーを作るのがそもそも大変
WebRTC をラッピングしたSkyWayでだいたいやってくれる(PC間だけじゃなく、スマホまでやってくれるらしい
その他類似事例(ちょうど3/3に GIGAZIN Eに記事が出た. ファイルの相互送信とか,ビデオ通話ができるサービスとか
自身でつくったもの(音声通話とかの実験用
PeerJS のラッピングを利用、PC/Android では動作できた(iOSはダメ
PeerJS 用の無料のクラウドサーバーが使える
peerJs に頼る形で 100行程度のコードで実現している
(接続の確立のネゴシエーション部分がよくわからなかった
ある程度ラッピングされてるので ハードルは下げれる
iOSが対応してないので,ファイル共有とかPC/PCをメインターゲットにできるところだと利用できるかも
・notifications
push api とは別物で,ブラウザからの通知を一元化して扱えるというもの
(tiarraMetroにいれてみるか
・実験的なAPIについて
Chrome/Firefox でしかうごかないものがおおい
iOS が使えないのがおおい ので iOS で使えるかどうかにひっぱられる
SSL 以外禁止になってどんどん使えなくなっていくので https で動かしましょう
localhost で動いても、本番環境に持っていくと通信制限の問題で動かなくなる事があるので気をつけて
日本は iPhone のシェアが高いので厳しい
まだパフォーマンス論争以前に機能が足りてないものがおおい
よいところとしては Web 技術ですべてかける
-----------
昔、Firefox に実装された加速度の API とか geocoding の API とかは、何かの勉強会で見て弄ってみた記憶があるが
HTML5 になってほんとに出来る事が多彩になっていて、それを WEB の技術で制御できるのが面白い。
個人的にはスライドの最初にリスト表示されていた D&D API とかも気になったし、
個人的に自作して使っているプロダクト(tiarraMetro)とかで気軽に導入できそうなものもあったので為になった。
push はちょっとハードル高そう。
(竹洞 陽一郎さん 資料 126ページ!)
前半は統計学がいかに大事で、日本が統計学教育でどれだけ遅れてるかという話し。
今は高校の数I に入ってるみたいだし、最低限教育課程でやられてる範囲くらいは自習しとかないと 共通言語が扱えない みたいになって追いていかれるのかもしれないな。
・配信品質の話し「速さはなぜ大事か?」
我々が思う以上に一般の人は、サイトロードの遅さに対してシビア
最初に行って遅いサイトにはもうアクセスしない、っという人が半数近く居る。
「サイトパフォーマンスの大事さは分かるけど、他の優先事項が出来てない...」
というのは間違いで、サイトパフォーマンスを上げておかないと 優先で実装されたものを見てもらえない。
チャンスは一度きり。
こっから人の感覚の不確かさの話しとか。
・手法のはなし
ハイパフォーマンスwebサイト、9年たった今も通用するのか?
→通用しないよ
そもそも事象の背後にある原因が違うと解決策は変わる、ベストプラクティスとか辞めませんか?
(個人的にはハイパフォーマンス WEB に載ってる内容は使っているのだが
(結局そのまま当て嵌める何て出来ないし、要は参考にする指針程度のものだと思って使っていたので、柔軟性の問題よな...と思う
ベストプラクティスはそこら中にころがってるが,それは「健康法」みたいなもん
問題は特定の事象から発生しているもので,それは「健康法」で解決できるわけじゃない
ちゃんと医師の診察を受けろ。
・PPDACサイクル
(ニュージーランドでは小学校でやるらしい、何か基本情報かソフ開でやった気がする。
診察(実行可能データの計測)→手術
「健康法」をどうこうするのではなく,エンジニアは「医師」であるべき.
ベストプラクティスやめましょう
(まぁ参考にするくらい でいいよな っと思うし,エラー対応はまずログを見ろ!!!!みたいなのと同じかな
・計測の仕方
サーバーサイド / 合成 / リアルユーザー
リアルユーザ→エラー率が分からない(欠損値)
ランダムの欠損なのか,パターンの欠損なのか
また何の環境に依存しているかも分からないから統計的には扱えない。
・品質管理の原則
コントロール可能な範疇に中力
→なので合成計測でやっていこう
実験計画法 三原則
表示速度,どれくらい確かか?
→サンプルをふやしていかないと 正しい情報がえられない
ラプラスの魔 → 全てを知る事はできないので,確率的に近づくしかない
母集団と標本 → 神しか知らない真の平均値(μ) 標本から得られる人間が知れる値x_
3回とか5回で何が分かるのか? 統計学的に最低20~回はやろう
平均はバラつく、偏差をとる
6σ(製造業は100万個に1個のレベルで管理している
平均が全部4秒のグラフ
(品質がいいのは まとまってるやつ という話しだが、まとまってても4秒だと品質とは という気持ちになるな
=======この辺で時間切れで駆け足
パフォーマンス改善の手順
主要動線でのページ遷移計測
(これは合成計測の短所になってた部分でもありそうだが
分散の加法性
例外が発生しているものは、エラー値かパターン値か? これはサンプルの期間を増やすしかない
chrome の開発ツールではそんなに取れない ツールの限界は知るべき
PageSpeed Insights では今上げてきたような問題が計測できない
google は自社の計測ツールではなく catchpoint のを使ってる
サンプルに出してるような接続ホスト数(40とか)だと、http2 にした方が ssl を接続数が大量になって重い
(最近 DeNA の H2O でリンザンプション使えばその限りじゃないよ みたいな記事を読んだのでタイムリー
-----------
ちょうど今仕事でやってるような範囲に近かった(こちらの程度はかなり低いのだけど)ので、勉強になった。
仕事にすぐ活かせるかは分からないけど、計測に関しては まだ手を付けはじめた感じで序の口なので、
今回学んだ事を活かしていきたい所。
最近はあまり個人開発のモチベーションが無かった(...というか家にいると無限に FF14 やってるというのがあるが、
とりあえず出来る所から何かやろうかな っと思って、手元の環境で初めやすいのもフロントエンドのいい所だと思う。(成果を見やすい
長らく触ってないものの、自分自身で利用は続けてる tiarraMetro に notification API を取り込む、なんて小さな所からでいいので ちょっと触ってみたくなりました。
あとイベントのランチマップがいい感じだったので、「お昼ここに行くぞ!」っと決めて 友人と約束してて梅田に戻っちゃったのはちょっと勿体無かった。
そして40分開始だと思って悠長に買い物して戻ったら、午後が20分からで聞きたかった。
・JS フレームワークと年月- ExtJS, AngularJS, React -
を聞き逃したので、他の方のレポート blog なんかが上がるのを楽しみにしておくかな...っといった所。
]]>スマートウォッチの類にはあまり食指が動いてなかったのだけど、この記事を見て「軽さ」「安さ」「開発し易そうな感じ」「電池持ちがいい」辺りが気になって注文してしまった。
ぐっとくるでしょ?
ぐっときたわ。
ハッカソンには距離的な問題もあって参加は出来なさそうだけど、開発コストが低そうなので せっかくだしちょっと触ってみようって気になるよね。
]]> とりあえず注文前に開発でどんな事が出来るのかさらっとググったり本家見てみたので、さらっとまとめてみる。自分に関係なさそう、興味なさそうな部分は飛ばしたので ここに書いてないから出来ないって訳でもないからね。
あと何か 実装してみた事じゃなくて調べた感じなので、捕捉が必要な所あったら指摘してほしい。
一応 Mac, Windows, Linux 向けの開発環境は出ているんだけど、そっちはなんか準備が面倒くさそう。
で何で不要かっつーとクラウド環境が用意されていて、ブラウザ上での開発ができる。
ブラウザ上で開発っつーと、どっちかと言うと「えー」ってなる側の人間なのだが、何かゴテゴテのヘビーなもの開発するなともかく、元々出来る事に制限ある端末だから書くコード量なんて知れてるしええやんってなった。
本体届く前に登録して色々触れるのでちょっと弄ってみたけど、十分そうな感じ。
デプロイも楽そう。
C で書くか JavaScript で書くか の二択。
って話しだったんだけど、JS の方はそれ用のエミュレータアプリ上で走らせるってスタイルだった。
dropbox とか github やら http アクセス可能な空間にソース置くだけで利用できる気軽さがあるし、ハードウェア的な部分も一通り API が用意されてて 簡単なもの作るには十分そう。
元々使われてたっぽい Simply.js ってのは、描画周りはほぼ何も触れない感じで、「title,subtitle,body」の3サイズの文字が表示できるだけなんだけど、
今サポートされてる、後継の Pebble.js ってのには、UI 周りの API が充実してるように見えるので色々弄れそうかな?
使えそうな記事を検索してみると、だいたい Simply.js のしかヒットしないので、最新のものを使うように気をつけたい。
JS は嫌だしネイティブで書きたいってのなら、C を選ぶ事になる。
リッチな言語に慣れた今になって C++ ですらなく C を書くのはちょっと辛いんだけど、これも開発規模とやる事の範囲考えたらそんなに辛くもないかな?
C+JS で組み込み JS 使って開発みたいなのも出来るみたいだけど、まだ詳しく見てない。
図とか使って分かり易く解説してるサイトがあったらいいんだけど、それっぽいのが見当たらない。
あまり組み込み系の環境触った事ないので、そーゆー方面として当たり前だったりするのかもだけど、とりあえず今は WEB しかやってない人間としてトピックになりそうな部分を洗ってみた。
pebble では1画面に表示されているウィンドウは1つだけ。
新しいウィンドウを開くとどんどんスタックされていき、常に最上位のウィンドウだけが表示される。
ポップすれば前画面に戻る。
公式で示されている pebble のナビゲーションモデルとしては水平スタックとの事なので、ちょっと WP のアプリ開発を彷彿とさせる。
各シーンで描画対象となるウィンドウは1つで済むし、WEB サイトの遷移のような形になるので、WEB 屋が考え易い実装になってると思う。
(配置済みのウィンドウをリソースとして持てないんだろうか?)
基本的にクリックや通知などのイベントに対して対応する、イベントドリブンな実装になっている。
昔 C 言語で Windows ソフトを作成していた頃は、プロシージャに投げこんで switch-case でイベント処理したものだけど、pebble はちゃんとモダンな実装になっているので、イベントループになる部分は。
int main(void) { app_event_loop(); }
といった風に専用のメソッドを呼べば処理してくれる。
我々は window_single_click_subscribe,
window_load といったメソッドを呼出して、ハンドラーとなるメソッドを登録するだけでいい。
あれ、ほぼ WEB じゃね?
もちろんこれはイベントドリブンなアプリを作る為に提供されている構造なので、ゲームとかリアルタイム処理をするアプリを作りたかったら、ループ部分は自分で書かないといけなさそう。
ここがちょっと面倒くさい。
基本的に全てのUIオブジェクトは TextLayer だとか MenuLayer だとか BitmapLayer だとか、レイヤーに所属している。
このレイヤーは階層構造になっていて、共通のroot レイヤーを持つ一群の木みたいな形になる。
これらのレイヤーはイラストレーターソフトなどで使われる重なった全体を覆う面というわけではなく、レイヤー1つ1つが矩形のサイズを持っている。
そして、子レイヤー上のオブジェクトは親レイヤーからはみ出して描画する事は出来ず、もし親レイヤーよりも広く描画していた場合はクリッピングされて表示される。
時には階層構造からはみ出して配置・描画される WEB とは違った所なのでちょっと理解しづらいが、MDI型のウィンドウ構造と同じだと考えると良さそう。
このような構造になっている利点は、再レンダリングの処理にあるのかな?
無駄な部分を再描画しない為に、レイヤー単位で再レンダリングを行なうかを明示できる。(汚れをマークできる)
layer_mark_dirty(custom_text_layer->layer);
マークせずに再描画を行なうと既存画面がそのまま表示され、マークしていれば マークしたレイヤーより下層の範囲だけを再レンダリングしてから描画できるので無駄を省けるのだろう。
( E-Ink だから書き換え行なう必要がある場所を絞るようにこうなってんのかもだけど、ハードに絡む再描画の要/不要はメモリ比較して勝手にやってくれや と思うが、E-Inkがどんな構造になってるのかよくわからんしなぁ...)
効率的な描画ができるようにか、アニメーションを描画する為の手段とかも提供されているので、モノクロ低解像度とはいえ色々表現できる幅は広そう。
とりあえずさらっと読んで気になったのはこんな感じ。
届くのが楽しみです。
ハッカソンまでまだ3週間あるし、注文すれば3~5日くらいで届くみたいだから、とりあえず気になった人はポチって参加してみればいいんじゃないかな。
しかし何か作るのが楽しそうな端末ではあるんだけど、あまり手首にある端末で出来ると楽しい事があまり浮かばなくて、未知のものに対する想像力が足りてない...
なんか複雑な操作を手首に持ってきて長々と操作するんだったら端末出しちゃうし、ほんとに簡単な事をしたい時に端末出さなくていい ってメリットを活かす為には何をアプリ化するのがいいんだろうなぁ。
まぁ既に提供されてるアプリストアのものを触りながら、自分にとってあると便利そうなものを考えていくかなぁ。
]]>LINE Developer Meetup #8 in Kyoto - connpass
仕事で触ってる範囲はフルスタックな感じなんだけど、規模がとても小さいので自分みたいなのが行っていいのかなーっと思ってたけど、興味深い話しばっかりで凄く面白かったので行って良かった。
会場は京都駅から南に下った所の京都テルサの会議室。
テルサはスポーツ施設しか利用した事がなかったので、ちょっと新鮮な感覚だった。
]]>こっからは会場で取っていたメモベースにまとめたもの。
すぐ纏めないとすぐ忘れるのでとりあえず書いとかないと。
起きたら読み直して変な所はなおします...Zzz...
あと今回はノート持ってくの諦めて、z ultra と BTキーボードでメモ取ってみた。
LINE のインターン生で未踏プログラマーな @tarunon さんによる、iOS8 で追加された WKWebView は従来の UIWebView と比べてどうなのか...というお話。
といった感じで、最初はまず UIWebView でサードパーティーブラウザを実装するのがどれくらい大変なのか...というお話から。
WEBビューをアプリに組込むって時に使われるコンポーネントとしては最低限の機能は持ってるんだろうけど、ブラウザを実装するにはあまりにも機能が足りない...
そこで3つの拡張手法でブラウザの必要な機能を実装していく。
「JS による拡張」「ネットワークによる拡張(NSURLProtocolによる)」「プライベート API (!)で頑張る」
特に NSURLProtocol でコンポーネント側でサポートされているスキームのリクエストまでフックして色々弄れるって話しは面白かった。
(しかしこれを時前でやるのはキツいな...
この辺一通り、どーいった機能が足りなくてどう制限を回避していくのか、というのが各機能の表で見やすく整理されて解説されていて面白かった。
んで、WKWebView はデキる子か?という話しで、上記の UIWebView がサポートしていなかった機能の大半をサポートしている!
素晴しい!
でも NSURLProtocol が上手く動かないので使えない!残念!
WKWebView のが便利なシーンはかなりあるけど、サードパーティブラウザを開発するには適材適所で今後も UIWebView と付き合っていきましょう...というちょっと寂しい感じの締めだった。
質問し損ねたけど、「NSURLProtocol が上手く動かない」部分がブロックされた機能なのではなく不具合であるなら将来的には WKWebView に移行してく事もありうるのかな。
「この先」の話しもちょっと聞きたかった。
最初は LINE の運用規模のおさらい。
ググれば出てきそうな情報ではあったのでメモってないけど、ユーザーは日本に偏ってるのかと思えば案外台湾やタイが多い。
popもかなり世界中に散ってて、サポセンの拠点も今では世界4箇所に。
・マイクロサービスアーキテクチャ
サービスを広げると、システムはどんどん巨大化していく。
低コスト・スピード重視で開発を続けていくと、いずれ巨大なモノリスが出来あがる。
結果コストは増大し、スピード感が落ちる。
全てを把握しないと何もできなくなり、新しい事に挑戦できないエンジニアのモチベーションは低下していき山手線を彷徨う。
・LINE は?
複数の独立したコードベースでチーム単位に動ける。
→コミュニケーションコストが低い。 新しい技術もサービス単位でガンガンいれれる。
→もちろんチームによって差があり、コアな所はとてもコンサバ。
データ管理なんかもチーム毎に違う手法をとるので、採用DBもバラバラだったり。
(HBase,Redis,MySQL,MongoDB,InfluxDB...
→ビルド、デプロイ、モニタリング、ログ収集なんかの基盤部分は専門のチームがやっている。
・API
サービスごとに API セットができる。
→インターナルな API で json on http とか必要なのだろうか?
自由度が高すぎるとサービス毎にスタイルがバラバラになる。
それを統一する為にはドキュメント等で縛らねばならないし、それすら従わなかったりする。
その為採用したのが serialization/RPC フレームワーク 『Apache Thrift』
まず、Thrift IDL で定義ファイルを書いて、各言語ごとに必要なコードをそこからジェネレートする為、API の定義ファイルがドキュメント代わりになる。
→ WIKI を管理する必要がなく、また多国籍なエンジニアが開発に参加し多言語化している環境でも翻訳を意識する必要がない。
line ではこの定義ファイルを git で管理し、API の更新時はブランチを切って更新していき、利用するサービス側はそれを見て実装を進める。
主要の言語はサポートされている為、開発言語から違うチーム間でもやりとりが可能でプラガブル。
何より話し聞いててでかいなと思ったのがエラーハンドリング。
json だと手法が固まってない所為で割りと適当にバラつきがちなエラーハンドリングだけど、Thrift だと各言語に最適な形でエラーハンドリングができ、例外が扱える言語ならちゃんと適切な例外が飛んでくる。
便利!
・マイクロサービスのトレーサビリティ
複数のシンプルなサービスをいくつも介してサービスを提供している。
マイクロサービスのいい所は、サービス単体の完成度をあげていけば 全体で何が起きているか把握しなくてもいい所だ。
ほんとうに把握しなくても大丈夫なのか?
実際に何が起きているのか。
(この時のぐちゃぐちゃした感じの図が大変わかりやすかったw
クライアントまで到達する間に複数のサービスをいったりきたりしている。
結果、「何か」が起きた時に原因を究明したくても、どこのサービスが原因なのかが分からないし、それを調査する責任者が誰なのかすら分からない。
詳細を把握しなくてもいいのはいいが、パフォーマンスのボトルネックが可視化できない。
そこで登場するのが Google の論文を元に Twitter が作った『Zipkin』
単体サービスでボトルネックになっているものを Firebug で探すように、結合されたサービスの中からボトルネックになっている部分をタイムライン形式で表示して可視化できる。
また非同期的なものを可視化できる。
(実際にキューを積んで処理してる図がわかりやすかった。
どのように動くのか?
サービス間のやりとりをスパンとして木構造で集約していく。
実際にはクライアントと各サービスのリクエスト・レスポンスのタイミングでロギングしていく。
またデバッガーにブレークポイントを仕込むように、コード上の任意のタイミングでのロギングも可能な為、サービス内の処理も切り分けて視覚化できる。
構成としてはサービスからScribeでログを受け取るコレクタ、コレクタが受け取ったデータを溜めるストレージ、ストレージから検索機能を提供するクエリサーバー、そしてそれらの集計した結果を表示するWEB UI で構成される。
ストレージは Twitter が最近まで使っていた Cassandra が一番テストされていて熟れているが、運用実績を考慮して HBase に。
また各サービスに zipkin-collector とのやりとりを実装してもらうのはコストが高い為、サービス間で Thrift によるリクエストを受けたタイミングでフィルタに通す形でログに保存するデータを収集して Scribe プラグインをいれた fluentd 経由でログを送信している。
今後は収集したログをよりインテリジェントに分析できるように、またトレーシングの導入コストをより軽減させるライブラリをつくって可能であれば公開したい とのこと。
というような事をまとめがてら、記憶の不確かな部分を調べる為に検索していたら、本家の記事があったので、こちらを読みましょう。
LINEのマイクロサービス環境における分散トレーシング « LINE Engineers' Blog
図もあって大変わかりやすい。
現在のエンジニアさんの分布だとか福岡の新オフィスの話しとか、福岡のサポセンの話しとか、他言語化初期のサポセンの苦労話しとか、社内言語の話しとか、なぜ京都開催になったのかとか色々とお話が聞けた。
なんでテルサになったの?というか「なんではてなじゃないの?」みたいな会話が面白かった。
あとは大手サービスの裏側を支えるエンジニアみたいな話題で某大手動画配信サイトの話しなど聞けたのが楽しかった。
勉強会で色んなエンジニアが集まれば色んな繋がりがあるもんだなぁ。
最後まで居たら終電逃して途中駅から歩く感じにはなったけど、ほんとに面白い話題しかない みたいな感じで過せたので とても楽しかったしモチベーション上がる感じでした。
次回もし関西(大阪でも)開催されたら参加したいな。
はてなオフィスだといいなー。
それはそれとして、明日(というか今日10/18)の夜22時からプログラマーズナイトというイベントがあります。
プログラマーやらエンジニアが集まって、素敵な音楽が流れる中お酒を呑みながらあーだこーだ話したり、しゃべりたい事をLTしたりするイベントです。
LT する人も現地でまだまだ募集してるし、「こんなサービスつくったぜ」みたいな宣伝がてら技術解説するLTとかでも歓迎...のはず。
夜22時から朝4時までのオールナイトイベントなので、近くで飲んでで帰りそびれた人なんかも ふらっと立ち寄ると楽しいかもしれません。
まぁなんか聞かせたい人も聞きたい人も、だらだらだべって酒のみたい人も是非。
]]>90年代の思い出がまた1つ消える―Winamp、15年の歴史に幕 | TechCrunch Japan
15年かぁ...
これをきっかけに身内のチャットで懐しいフリーソフトの話題が出てたんだけど、
『自分が今使っているので一番歴史の古いのは何だろう?』 ってのと 『一番長く使ってるのは何だろう?』 みたいな話題に発展していった。
vim っていつからあるのってなったりもしたが、Windows 以外をいれたら そっちの話しで終わってしまうので Windows に制限しようとなった。
(ちなみに Vim は87年に出来たらしい。
]]> 今も入れているものそもそも OS 入れ直して最初にいれるフリーソフトってもう殆どなくなってる。
当時は大量にダウンロードしてフォルダ分けしてランチャに登録してたが、今となっては
Firefox,Chrome,iTunes,Putty,terapad,Lhaplus,GOMPlayer,Launchy,X-Finder,skkime
あたりか。
最初の3つはかなり大手だし、後半の方は比較的最近。
なんかしっくりこないが、Firefoxが一番歴史は古そう。
一番長く使ってるのは多分 Lhaplus と terapad 。
解凍は explzh 使ったり WinRAR使ったりもするが。
開発目的に都度いれてるフリーソフトもいくらかあるが、FFFTP以外でそんな長く使ってるのは無いかな。
FFFTP,cassava,tksqlite,WinMerge,Namery
VS Express とか Windows Live 系とかフリーソフトって感じじゃないけど、一応フリーソフトの範疇なんかね。
そんなような事を考えてたら、一番古いのは Adobe Reader なのではないか? という疑問が出されて、
調べてみると 1993年初出で、自分が今使ってるソフトで一番歴史が古いものに該当しそう...
うーん何かしっくりこない。
これ使ってたなーって話題も尽きなかった。
皆が色んなソフト使ってるのと比べて、俺は移行を面倒臭がるのであまり触ってないような気がする。
(流れ上、シェアウェアも入っている)
IE6 -> Lunascape -> Firefox -> Opera -> Firefox(Vimp) -> Firefox(Vimp) & Chrome
回りが Sleipnir を使う中、かなり長い事 Lunascape を使っていた。
Opera もかなり愛用していたが、Vimperator を使う為に Firefox に戻った。
変わり種だと、一時期『ほぼテキストブラウザ』というのを一部の場所で使っていて、MSの メモ帳 みたいな見た目で面白かった。
他にも2ch用に『A bone』とか『JaneStyle』とか、ブラウザにaddonが少ない頃は、専用品もけっこうあったな。
普通に使ってると用のないツールかもしれないが、『うめ~このみかん』とか『璃樹無』『らるちー』なんかの名前にピンとくる人にはお馴染だろう。
iria, FlashGet, DCさくら -> Irvine -> Chrome
今はもうブラウザのDL管理機能が充実しているし、そもそもファイルを保存する機会も殆ど無くなってしまった。
こうやってリッチな環境に統合されて使わなくなったものは、かなり多い気がする。
話題元である所の Winamp も勿論使っていた。
Winamp -> KbMedia Player -> Winamp -> iTunes
CD2WAV32 & 午後のこ~だ -> CDex -> iTunes ->
昔は取り込みも別ソフトでやってたけど、今は iTuensに任せっぱなしというか、
そもそもデータで購入できるようになって、ノートPCからドライブすらついてないというか...
CD関係だと『CD Manipulator』とか『DAEMON Tools』とか『CloneCD』とか『DVD Decrypter』とか色々お世話になりましたね。
変わり種で『Virtual CD-ROM Case』ってソフト使ってて、大量にあるCDを管理するのに便利だった。
Susie -> Leeyes -> マンガミーヤ -> ComicGlass -> PerfectViewer
今でも MangaMeeya の実行ファイルは残ってるんだけど、利用は iOS の『ComicGlass』やAndroidの『PerfectViewer』に移った。
WindowsMobile ですら マンガミーヤCE 使ってたシンパではあるんだが、滅びてしまったのが寂しいソフトだなぁ。
学友との連絡やらゲーム仲間との連絡にと、色々と活躍してくれたもの。
ICQ -> MSN Messanger & Yahoo Messanger -> Regnessem -> Skype & LimeChat
グループによって使っているメッセンジャーが違って難儀したが、Regnessem の登場はそれを解決する画期的なツールだった。
音声通話のしやすさから Skype へと移行したが、文字チャットの主体はコミュニティの影響で IRC になった。
今も一部で使っているので LimeChat と書いたけど、殆どの利用は 拙作ではあるが tiarra Metro を使っている。
少しズレるが、夜な夜なFPSをやってた頃は『TeamSpeak』なんかも使っていた。
普通だとここもズラーっと並ぶと思うんだけど、俺は秀丸もsakuraエディタも使ってなくて、最初期に触った terapad を今でも使ってるので、遍歴がない。
(開発に使うIDEは右往左往しているが)
メーラーも今は Gmail なので殆ど使わないが、使う必要がある時も 昔と変わらず Thunderbird を使っている。
学生メアドの運用に持ち運びが効く nPOP を使っていた事もあったな。
書きながら当時の事思い出してたら『めもりーくりーなー』とか『伺か』とか『窓の手』やら何かどんどんと...
何か思い出話をどっかに書き殴りたいだけ、みたいなエントリになったが、そもそも実際思い出話をどっかに書き殴りたかったので仕方がないな...
シェアウェアも含めると、一番長く使ってるのはチューチューマウスな気がせんでもない。
ねずみかわいい。
]]>使えない間に取り込めなかった写真を一気に取り込んで整理したが、やっぱり便利だ。
何か丁度 Adobe の15%オフキャンペーンを2/15から開始してるんだけど、それとは別に Amazon がキャンペーンを2つやっているので、それを適用すれば さらに1000円引きになる。
殺安!
※Lightroom4 だけじゃなく、PhotoShop Elements11 もキャンペーン対象だけど、とりあえず自分が買った Lightroom4 の話しに絞る。
]]> キャンペーンアドビ側のキャンペーンはアドビの公式ショップはもちろん、家電量販でも価格適用されているので、ヨドバシやビックの方がポイントも含めると Amazon より少しだけ安い。
けど、Amazon はそれに加えて2種類のキャンペーンを以前から展開している。
Amazon.co.jp: アドビ製品とお好きな対象商品を一緒に買うと、その場で1,000円引
文字通り 一緒に買うと購入時に1000円引きされるというもの。
この対象商品はかなり幅広くて『Amazon.co.jpが販売かつ発送する商品』であれば何でもいいので、本でもCDでもマケプレや外部ショップのものじゃなければ大丈夫。
詳しくはリンク先参照。
Amazon.co.jp: アドビダウンロード版を買った方にクーポン1,000円分をプレゼント
文字通り ダウンロード版を買うとすぐにメールでギフト券がアカウントに適用された旨が通知される。
こっちは対象商品にしか使えないギフト券だけど、それも『Amazon.co.jpが販売かつ発送する商品』であれば何でもいいので 自由に使える。(ただし3月一杯までに使わないといけない
これ前者にだけ "※ 他キャンペーンとの併用はできません。" って注釈が付いてるので重複は出来ないのかな?
後述するけど、facebookで学割アップキャンペーンとは併用できるらしいので、この注釈がどの程度正しいのか分からなかったりする…
俺はキャンペーンに気付かずに買ってしまっていたので、DL版の方だけ自動適用されてたので検証はできなかった。
そんなこんなで対象の『Lightroom4』のラインナップは以下。
まずパッケージ版。
左から通常版、アップグレード版、特別提供版(乗換用)、学生・教職員用アカデミック版。
1000円引きで、通常版で11500円くらい、アップグレード版や特別提供版で6700円くらいになる。
アカデミック版になると、Facebookでシェアすると10%オフになるキャンペーンが併用できるので、3800円くらいだろうか?
学生いいなぁ…
続いてダウンロード版のWindows用。
左から通常版、特別提供版、アカデミック版。
ダウンロード版にはアップロード版の取り扱いが無いらしい。
そしてダウンロード版のMac用。
左から通常版、特別提供版、アカデミック版。
パッケージが全部同じでややこしい。
価格設定は基本的にパッケージ版と一緒だけど、通常版だけ300円ほど高くなっている。
ダウンロード版には1つだけ難点があって、Windows/Mac が別扱いになっている所。
ただこれは多分システム上 ソフトウェアのダウンロード部分でどっちかしかダウンロードできないから切り分けているだけで、ライセンスキーは一緒なんじゃないかなと疑っている。
今回ダウンロード版を購入して、"既にインストールしていた体験版"にライセンスを登録する形で使えたので、Amazon からダウンロードする必要はないし、将来的にどっちかに移行するかもって人もダウンロード版で問題なかったりするのかな?
まぁ憶測なので保証はしません…
うちは乗り換え対象になるソフトがあったので特別提供ダウンロード版を買いましたが、7711円での購入後に1000円のAmazonギフト券が自動でアカウントに付与された形。
キャンペーン重複できるか試しておけばよかったなぁ…
しかし出来る事が今更分かったらそれはそれで悔しい。
]]>
以前から Nexus7 で nesne の録画番組を見るのに使っていた Twonky Beam がアップデートされたんだけど、新機能として動画をアプリ内に保存できるようになった。
これ割りと凄い事で、今迄 sony 製品くらいでいか受け取って外部で見たりできなかったのが、Android 4.0以上対応の端末であれば とりあえず持ち出せるようになった。
ただしこのアップデート以降はアプリ内課金でキー購入しないと、再生も含めて DTCP-IP を利用した機能が使えないらしいが、前々からのバージョン使ってる人は別に そのまま使えるらしい。
使ってて良かった。
]]> 書き出し機能の使い方は簡単で、Twonky Beam 上で番組を選択するとメニューがポップアップするので ダウンロードのアイコン押すだけ。あとはライブラリのトップに出てる「ダウンロード済み」から通信切ってようが再生できるという嬉しい感じですね。
あとサイズがどうなってんのか見てみたんだけど、
元々3倍で録画してる300MB程度の5分番組が、Nexus7 場では90MBくらいに縮小されていたので、
これ Vita とかに書き出す用のエンコードされたモバイル向けファイルを持ってきてくれてるみたいで、SDカードの無い Nexus7 としては大変ありがたい。
ただそれでも元データが30Gとかあるアメフトの試合は持ってこれんかったが...( ´-`)
あと多分 Android の事だから、機種による相性とかもあるかもしれんが、この記事みて プレミアム版買ったけど見れねぇぞこらとか言われても僕は知りません。
とりあえずウチの Nexus7 ではいい感じで動作しております。
そういえば Twonky Beam と言えば、iOS 版でも DTCP-IP 対応して番組が見れるようになったので、iOS ユーザーも今のうちに入れておいた方がいいんじゃないかって感じですが、
なぜか Android 版では出来ないスクリーンショットの録画が iOS 版では(警告が出るにせよ)出来てしまうみたいで、
なんかネタとして fb とかに投げる時に それ使えると便利だなぁと思うけど、色々問題ありそうだなこれ...
]]>indexs そのままでは殺風景なので何かデザインをつけたかった。
h5ai はちょっと重いので何かないかなーと相談していたら mapi 先生が apache-autoindex-theme というのを見付けてくれた。
適用してみたが 軽いし 見た目もそれっぽくていい感じ。
]]> 導入はとても簡単で、適当なディレクトリに設置して alias を設定した後、後は conf ファイルにテーマ設定用のコードをコピペするだけ。お手軽感がすごいね。
これ、autoindex 以下にcssやらjsのディレクトリがあって、header.html にちょっと変更を加えてやれば 自分なりのカスタマイズが出来るのも良さげ。
んで、日本語のディレクトリだと、ヘッダーのリンク部分がエンコードされたまま出ちゃうのね。
んで、header.html 見てみたら、ディレクトリへのリンクは js で生成してる。
なので、こんな感じにデコードのメソッド追加してやると。
こんな風にちゃんと表示されるようになりました。
お手軽。
]]>これを使えば比較的簡単に ストアアプリを gyazo れる…筈。
gyazowinp 自体は Windows8 でも正常に動作するのですが、
ストアアプリで gyazo を利用するにはいくつか問題があります。
]]> 問題Windows8 でもデスクトップソフトウェアとして gyazowinp 自体は問題なく動作するのですが、
ストアアプリの表示中にはそもそも、デスクトップソフトウェアを起動する事ができません。
(起動すると画面がデスクトップに切り替わってしまう。
複数のディスプレイでの利用の場合は、一方の画面にストアアプリを表示し、
デスクトップ側でクリックしてキャプチャを開始すれば gyazo の範囲に指定する事はできますが、
結果としてデスクトップ側のゴミが入るし、アプリ内の一部分のみの投稿とかには向きません。
その為、Windows8 ではプリントスクリーンなどでキャプチャした後にペイントソフト等で開いて、
あらためてその画面を gyazo で切り出す といった事を ここ2日間ほどしていました。
が、正直めんどくさい。
gyazowinp の起動時にクリップボードに画像が入っている場合、画面上に表示する機能を実装しました。
つまり、プリントスクリーンをした後の切り出し動作自体を機能として盛り込みました。
これで、例えば alt+PrtSc でクリップボードに画像が入った後に gyazowinp を起動すると、
こういったキャプチャ画像の入ったウィンドウが表示されます。
このウィンドウは gyazowinp 終了時に勝手に閉じます。
今まで通りの感覚とは言い難いのがちょっと残念ですが、これには利点もあって、
例えば従来の gyazo ソフトでは、右クリックメニューなんかのフォーカスが外れると消えてしまうモノには使えませんでした。
ストアアプリ同様 プリントスクリーンを使うしか無かった訳ですが、その時の手順も少なくなってて、楽になると思います。
また クリップボードに何も画像データが存在しない場合は従来通りの動作をします。
っという事で実装したものがこちらになります。
--- download ---
なおこの機能は、デフォルトではオフになっていますので、有効化する場合は readme.txt に従って ini ファイルに設定してください。
ちょっと実装コストが高そうなので僕は作る予定はありませんが、
一つアイディアが浮かんだのでそれを記載しておきます。
ストアアプリで動作するIME作成のガイドラインを見ていると、他プロセスから ストアアプリのウィンドウに所属するウィンドウを作成する事は可能なようです。
その為、起動時に画面表示が切り替わらない、ウィンドウの無いアプリを作る事が出来れば、ストアアプリ用の gyazo も作れるのではないかと思いました。
ただ、チャームを利用するにせよ何にせよ、アプリのランチャそのものを起動すると画面が変わってしまうというのがあるので、
もし gyazo を常駐アプリとして裏で動かしておき、何らかのモーションやキーフックで作動するようにできれば…
みたいな所までは考えました。
ただまぁアプリ間の独立がガッチガッチなので、そういうのキーフックとか MSさんが許してくれていない気はします…
なので未検証で、とくに調べてないので 誰か検証してみてくれるといいかな~
]]>あまり外で速度を必要とするコンテンツに触れないので、今の所はイーモバの速度があれば充分なのだけど、
今迄使っていた GP02 は電池が持たない…
という事で、LTE 対応端末である sim フリーな GL01P を買って、データプランB の sim を刺して運用する事にしました。
GP02 には通称バスタブバッテリーと呼ばれる巨大な交換バッテリーもありますが、正直 GL01P の方が安い。
]]> GL04P の登場もあって、旧端末である GL01P は市場に余りつつあります。Amazon ユーズドの中古品で 8000円くらいしますが、オークファン の落札相場では5000円を切りつつあります。
殺安!
そんなこんなで4980円で落札したGL01Pが届きました。
(俺は本体だけという条件で安いのを手にしましたが、何か備品全部揃ってて 4200円で落札されてるのを見て悲しい気持です。
プランBユーザーは このまま sim を指すだけでは使えません。
それっぽく接続するような動作はしますが、画面に×印が出ます。
接続席 APN の変更をすれば使えるので、この辺とか見て設定しましょう。
SIMフリーをいかさなければ!!GL01PのAPNを変更する方法。 « ajstdrop
プリセットにデータプランB のAPNは存在しないので 『emb2.ne.jp』を新規で入力する必要があります。
無事接続され、3Gの表示がでました。
やったー!
今日昼から出かけていたので Nexus7 と1日繋げっぱなしにしてみましたが、
夜帰ってきて確認しても1メモリしかバッテリーが減ってません。
まぁ そんな多量の通信をしていないので、ガリガリ使えばそれなりに減ると思いますが、
ソーシャルとかで使ったりIRC使ったりWEBブラウジングしたり とかだと1日どころか2~3日余裕で持ちそうですね。
これで外で呼吸の心配をしなくてよくなるかなー。
]]>ってか下部メニューとかは WindowsPhoneと かに近い気もする。
色々教えてもらってアプリいれたり試行錯誤したのが取り敢えず落ち着いたので、導入したものを一覧にしてみた。
これ入れてないとかモグりやわー みたいなのあったら教えてほしい。
]]> そもそも Android を持つのも初めてだったので、友達に聞きながらとりあえず基本的っぽいアプリを突っ込んでいった。PC側で購入やインストールを押すと端末に勝手に降ってくるの面白いですね。
Windows Phone にもそういう機能あるにはあったんだけど、何か海外の sms が上手い事受信できてないのかウチでは使えなかったから新体験な感じがある。
あと、リストにしたけど半分以上 教えてくれた友人の受売りです。
かなり完成度の高い書籍リーダー。
NASとの親和性がとてお高いのが魅力的。
pdfプラグインなどもある。
個人的にはタッチ操作の操作は変えれても、区切を追加したりできないのが寂しい。
多機能な動画再生アプリ。
友人の配信環境から直で受信できる最適なのがコレだった。
※追記:これどうやら試用版扱いで ある程度使うと有料版に誘導されるみたい。
DTCP-IP に対応している為、nasne の録画動画が見れる唯一と言っていい DLNA クライアント。
ただし映像形式の問題か、nasne 側を3倍録画にしないと音しか出ないとかの問題があるようだが、ウチは全部3倍で撮っているので問題ない。
DLNAクライアントとしてはお世辞にも使いやすい とは言えないので、それ以外に目的があるなら Skifta とかのがいいかもしれない。
名前の通りファイラ。
Android は標準でファイラが付いてないが、割りとアプリで共有領域にアクセスするので、こーゆーの入れておくと便利げ。
他にも2つLDRアプリはあるけど、フィードの一覧表示やfull feedの読みこみ、ブクマ数の表示など必要な機能が揃ってるのはコレだけと言える。
URLの転送などは一度選択したものを1件覚えておいてメニューに追加してくれるなど、心憎いUIである。
Google Play 上では『アンロイド用 フリッカー手引き』というダサい名前になっている。
デザインがモバイル向けなのでスカスカになっているが、機能は一通り揃ってる。
複数画像を同時にアップしたい時はギャラリーから複数選択してアプリに投げてやる必要がある。
Flickr を使うアプリはそこそこ出ているようだけど、検索にゴミがヒットしすぎだし、試すのにイチイチ アカウントからアプリの承認しないといけないやらで面倒くさい。
本家アプリも出ているようだけど、残念ながら Android4.1 非対応なので Nexus7 では使えない。
だいたいのアプリがモバイルを想定したサイズで タブレットには画像が小さい。
いっそアップのはもっとシンプルな機能のにしといて、ビュワー用に FlickFolio for Flickr HD とか入れると良さそうかな。
いくつか他にも入れてみたので、後で野良apkとかも試してみるつもり。
SSHクライアント。
秘密鍵認証にも対応している。
だいたいの操作は出来るが標準のキーボードだとタブや上下キーが操作できなくて、けっこうダルい。
Atokとか入れてれば上下操作はできるらしい。
GP02を使っているなら入れておいて損はない。
接続/切断やバッテリー残量や電波状態などのモニターがAndroidから出来る為、一々本体を取り出さずにすむ。
東京限定の良質のお天気アプリはそこそこあるが、全国区のがあまりない。
(国交省のデータの地方性の問題?
いくつか見てこれか『雨ぐもん』あたりでいいかなと思った。
高機能でデータの良いアメダスウィジェットは、何故かウィジェット限定っぽい。
壁紙をストックから選んで適用したいのだが、何か横にした時も想定された切り出し方を強いられるので合わない。
その辺なんとかしてくれるアプリがこれのよう。
カスタマイズ性の高いウィジェットを作成できるアプリ。
ウィジェットとしてのみならず通知バーに突っ込む事すら出来る優れものだが、多機能すぎてどうやれば目的の形に出来るかかなり迷う。
オンオフとかはWigetsoid 使う事が多いが、無線の管理とかは 呼出しやすくてコレが機能的に良いので通知バーに置いてる。
クリップボードの履歴管理したり出来て、通知バーに置いておけるアプリ。
他アプリのURLの送り先とかにも設定できるので、地味にLDRMateと相性がいい。
けっこう苦労して入れたものの、ソフトウェアキーボードではシフトが同時押しではなく後押しであるが故に感覚がズレる。
というか、置いてタイピングするならともかく、持って親指タイピングが多いので、あまり使えない感じがする。
いっそ Atok 買おうかという気分。
以上はサービス使ってる人はいれておくと良い。
同期系は贅沢に使ってるとバッテリーへの負担になるので注意。
10月30日までに購入してアカウント設定した人には2000円分の google play のチャージが貰えるので何か有料アプリで便利なのあったら入れてみてもいいかな とも思う。
せっかくセールなので25円セールのゲームを7~8本買っていれてみた。
使うか分からないけど25円だし という事でツールも3~4つ買った。
それからと言うもの『冒険ダンジョン村』というのに時間が吸われてたが、5日で遊びきった感あるので解放されそう。
Madden NFL 12 も25円で買えたので、アメフトファンとして嬉しい所。
ゲーム機として買ったわけじゃない筈や…
それはそうとコナミの音ゲーはないんですか?
]]>今回の日本発売の夕方に注文してみました。
(同じ日に注文して前日に届いた D7000 と一緒に)
丁度、google play アプリの250億ダウンロード記念セールとかぶったようで、日替わりセールの2日目に届きました。
1日目の office アプリは落としておきたかったな…
]]> 到着25日に注文して、翌日26日の夕方には発送通知が来てました。
さらに翌日 FedEx のサイトで追っていると27日の朝には日本に着き、昼には京都へ。
そこで "Delivery exception" というステータスになって動かなくなってしまったのだが、
どうやら備考を見る感じだと日本の配達業者への受け渡し時間が過ぎてるから、明日の取り扱いになるよ という事だったみたい。
翌日も "Delivery exception" からステータスは一向に変わらなかったけど、変わらないまま午前中に届いた。
kindle4 買った時も X201s買った時も思ったけど、最近はなんでも香港からすぐに届きますやね。
開封してみるとモノは小さいし軽いけど、普段持つガジェットが IS12T と kindle4 だから重く感じる。
kindleの変わりにするにはちょっと重いし、持ったままウロウロしてると 手を空けたいなっと思った時けっこう邪魔。
でも意外にジーンズのポケットに押し込めたので、サッと手を空けたい時には何とかなりそう。
付属のACアダプタには ”アスースジャパン" のシールが貼られており、とてもタイムリーに郷愁を誘う。
このアダプタ、最初購入サイトで『壁掛け充電器』って書いてて意味が分からなかったんだが、
原語で"ウォールマウント"を直訳して壁がけになったらしい。
この場合 ウォールマウント はコンセントに直ざしするやつの事だと教えてもらった。
まだ 保護フィルムが出揃ってないので、とりあえず何も貼らずに使ってるが、
出来たら rayout とかのアンチグレアフィルムとかが欲しい。
ただ、そーゆーの貼っちゃうと画面の綺麗さが全力を発揮できなくなるので悩むっちゃ悩む。
この後導入したアプリ一覧を書いたみたけど、長くなったの記事分けるわ。
明日更新する。
まだ5日だから活用全然してないんだが、この1週間で使ったケースを書いてみる。
そもそも WindowsPhone の "目的地検索するボタンすらない" 日本版の地図を使っていた身からすると、
目的地が検索できるという時点で革新的なんだが。
(実際は他の地図アプリとかを使ってなんとかしてるが、総じて使いにくい)
google map の地図検索としての有効性は今更語る事もないが、
個人的には地図レイヤの切り替えで渋滞情報が出せるのがありがたい。
サービス自体は昨年末からあって、モバイルでもブラウザでも見れるものだったが、
これがさくっとこのサイズの画面で検索して出せるのは車での旅行が多いので重宝する。
これが apple がやりたかった事か。
といったクオリティで、土曜になんば駅から『山中酒の店』という場所に移動するのに使ったのだけど、
十分頼りになるナビアプリだった。
ただ、Nexus7 はGPSの精度にちょっとブレがあるように感じるので、スタート地点があってるかはちゃんと回り見て確認した方がいい。
多きな交差点のどの角にいるかがハッキリしなくて歩き出しに難儀した。
元々、自炊漫画は自室のノートPCで、小説や一般書は通勤電車で kindle で読んでいた。
漫画に関しては申し分ない。
元々紙の本も椅子に座って読む事を好むので、寝っ転がって読めるようになった!みたいなのはないんだけど、
何よりアプリの出来がいいのもあって、とても手軽である。
ただちょっと画面小さいかなと思うし、横にして見開きみたいなのには無理があるね。
一般書に関しても、kindle みたいに専用チューニングした pdf じゃなくてもサクサク読めるのはランニングの敷居が下がったと言える。
文庫だと取り込んだままだと 左右の余白が邪魔だが、とりあず読んでたのは縦に合わせるとかすれば丁度いい感じになった。
ただやっぱり目は疲れる。
長時間連続で読む事の多い小説は、やはり kindleで読みたいかな という思いが強い。
短時間の移動の時にちょっとずつ読んでる新書とかはこっちでいいかも。
(左右ボタンに慣れてるからページ繰りが面倒というのもあるが、これは慣れの問題かな。
家族でTVを見ている時に気になった事はすぐ調べるようにしている。
辞書が手の届く所にあるので言葉を調べるのはそれでいいけど、ナレーターの俳優の名前だけ出て顔が分からない…みたいなケースでは家族それぞれがスマホで調べてる。
でタブレットだと 回し見も楽でいい感じである。
あと場所の検索。
マップの話しに戻るけど、ウチのリビングにはもう10年以上前に使っていた中学時代の地図帳が置いてあって、
旅番組やクイズ番組なんかを見る時は毎回家族がそれで場所を調べるんだが、
それが劇的に快適になった。
休日リビングで一緒にUst見たりとかでも使えたので、まぁ便利かなと思う。
ただ俺は持ち歩き用に買ったので、リビングに常設できないから 自由に使えるのは俺が飽きるのを待ってもらう事になるが。
朝電車に乗る時間が40~50分くらいあって、読書にあてたり 最近はソーシャルゲームにあてたりしてた。
フィードの消化を前々からしたかったんだが、iPod touch はちょっと非力だし、WindowsPhone はLDRアプリが無い。
google readlerにすればいいんだけど、PCでは使い慣れてるLDRから離れたくないし、既読がバラけるとダルいのでLDRの読みやすい環境になったのはありがたい。
後、通勤時に遅刻していつもと違う時間帯の電車に乘ったら、車掌さんの声がすげーかわいかったので、思わず録音アプリをサクッと落としてきて録音するなど、活用しております。
カメラで撮った写真をすぐに Nexus7 で確認したりできるといいんじゃないかと思った。
Eye-Fi があれば実現できる。
Androidには公式の Eye-Fi アプリがあって、ダイレクトにデジカメで撮った写真を転送できる。
まぁその分カメラの電池食うのが難点ではあるが…
タブレット思ってたより便利だった。
PCとスマホの間を埋めるものがあるのは PCの前に縛られる時間が減っていい。
その改善が革命的とまで言うかは分からない。
出来る事はスマホの延長線ではあるけど、快適度という面では上なので、重さとか持ち歩くのが気にならないなら持ってみても良さそう。
あと他のタブレットと比べて Nexus7 が特別良いかどうかは知らない。
2万切る価格のモノとしては良いモノな気はするけど、どんどんモノが安く 性能が良くなっていく時代だしよく分からん。
用途的にはもしかしたらもう一回り小さくてもいいのかもしれないし、5インチのものが出たらそっちの方がいいのかもしれないけど、
ある程度解像度も保つとお高くはなりそうよね。
これよりも大きいサイズのものは、自分の手が小さいのもあって使いづらいと思うので、
今後もし こいつを家族共有用機にして新しいタブレット買うとしても、似たようなサイズでシンプルなのを選びたいな。
]]>配線にはかなり苦労させられたものの、とりあえず設置して BS/CS が使える torne として使いはじめました。
便利に1週間弱使ってたのだけど、今日ようやっと存在を知った CHAN-TORU がとても便利なので、blogに書こうと思った次第。
何が便利って本体起動せずに録画予約できるだけじゃなくて、録画ファイルの整理やら予約確認やら一通りの作業ができる!
]]> CHAN-TORUってなんだ?さて、CHAN-TORU とは何かなのですが、簡単に言うと 出先から番組の録画予約をする為のものです。
なんだ そんなの昔からあるじゃん って事なんですが、えっ こんな進化してたの?って驚きが色々ありました。
そもそも CHAN-TORU は nasne の為のものではなく、 SONY 製の BD レコーダー全般で使えるものらしいのですが、
まず登録が簡単
普段ネットで使っているアカウントを使ってログインできるので、非常に簡単に利用を開始できる。
nasne とのヒモ付も、CHAN-TORU で表示される数字列をコピペして、nasne の設定画面に貼っつけるだけ。
マジ簡単。
これだけでかなりの連携を見せてくれる。
具体的な繋ぎ方の手順は、nasne のオンラインマニュアルを見てね。
外出先から録画予約する | nasne(ナスネ)™ オンラインマニュアル
ちなみに家電事情事態には疎いので、今時のレコーダーならどこのだろうと こんくらい出来たりするのかは知らない。
放送中の番組リスト、番組表、検索、ランキング から番組の予約録画が出来ます。
表示は今時のスマホっぽい表示で整っていて見やすい。
放送中の番組だと今はじまった所とか終わりそうとかがパッと見で分かる。
検索の結果も見やすく、録画予約済みの番組はちゃんと表示が変わっている。
この辺が、一方通行で予約情報を投げるだけのサービスでない事がよく分かる。
番組情報を選択すれば、レコーダーの選択可能な設定に合わせた録画メニューが出ている。
ここで"予約録画をする"をクリックすれば簡単に録画できるわけだ。
ちなみに重複録画なんかの警告もちゃんと表示される。
とはいえ、ここまでは使い易いってだけで、番組表からの録画システムってだけだ。
まずは予約管理
予約リストが表示でき、予約の管理ができる。
これは、CHAN-TORU から録画設定したものだけでなく、本体の番組表から録画設定したものもモチロン反映されている。
これを使って撮り忘れの確認をしたり、重複番組の確認なんかが出来るわけだ。
次にファイル管理。
こちらも予約リストと同じような見た目の録画ファイルリストが確認でき、選択をすると
このような録画した番組情報の確認と削除ができる。
こういった管理を外から出来るというのは、全然認識していなかったので驚きである。
(外部からうっかりファイル消されたりしないか、ちょっと心配でもある)
まぁ「外出先でファイルの管理とかしねぇーよ。」っと 思われるかもしれないが、
外出先ではないが、本体を操作せずにファイルを管理したい状況は nasne にはある。
nasne の利点の一つに、DLNA を使って 家中の同一ネットワークに繋がった機器から番組を再生出来る というものがある。
まぁ DLNA の事をあまり知らない人は nasne のページで詳しく見てくれ。
2台の機器で番組を見る | nasne(ナスネ)™ オンラインマニュアル
本体を起動せずに 家の中の好きな所で PC や TV やモバイル端末から試聴する事ができるわけだから、
本体を起動せずに 家の中の好きな所から 番組の管理が出来ると便利だよね。
日常的にPS3は起動しっぱだとか、ワンルームだから部屋は移動しねぇよ!って人には必要なかったりもする。
この家庭内でどこでも見れるやったー って運用を開始するには注意点がある。
DTCP-IP 対応のDLNA クライアントソフトと DDCP 対応のモニタでないと利用できないのだ。
前者は Windows だといくつか有料のソフトがあって5000円とかそんなん。 ( Mac は知らん
後者は使っているモニタのメーカーサイトを確認すると良い。
なおウチは TV に DLNA クライアント機能がついていたので、とりあえず LAN を繋いでる TV からは見る事ができた。
この辺も、最近の大型テレビならだいたい付いている気はするけど、メーカーサイトなり説明書なりで確認するのが良さそう。
ウチのパソコンには対応クライアントが無かったが Power DVD とかでも対応してるみたいなので持ってる人も居たりしそう。
個人的には体験版触った感じ『Dixim Digital TV Plus』というのが良さそうかなと思っている。
便利なので、みんなも CHAN-TORU 使お~
なお、設置に使う分配器や分波器を買う時は、ケーブル2本付きのものがお勧めです。
僕は分配器を買わねばならない所で分波器を買ってしまうという うっかりミスをしてしまったので、構成に難儀したので、
皆間違えないように気をつけましょう。
]]>
この辺、夜中に色々相談していたので、その辺まとめとく。
誰かメシどこか補足頼む。
最終的にどう初期化されるのかまでは元記事が追記で説明してしまってるのだが、
なんでこんなんあるのかみたいな所の話しがないので、個人的に到達した結論。
そもそも何でクラスとプリミティブな型の初期化時の構文を合わせる必要があるのか、だけど
クラスのメンバー変数の初期化リストを記述する時に、クラスのコンストラクタ呼出しと同じような記法でプリミティブ型も初期化できるようにする為だと思う。
class Test{ int a,b; public: Test() : a(5), b(){ } }
こーゆーこと。
ここでは『変数名()』の形で記述する事が認められていて、クラスと同じように書けるようになっている。
統一感を出す為なのか、同様に宣言の所でも int x(n);で初期化できるようにしたが、
int x();
のように引き数を省いた初期化は変数の宣言と見分けが付かない。
(これは同様にクラスでも 明示的にデフォルトコンストラクタを呼び出す形に () を付けた宣言はできない。
しかしクラスは
Test x;
でコンストラクタが走る。
プリミティブ型はクラスと違ってインスタンス生成がないのでコンストラクタは走らないが、
int x;
で、スタック領域に配置される。
しかしこの段階では初期化が行なわれないので、変数の値は不定である。
この辺は C との互換を守る為にはどうしようもない部分。
そんなこんなで、『変数名()』 で 特定の場所だけ初期化できるけど全体的に統一感に欠けるのはその辺の互換絡みの しがらみの所為なのかな。
ここまでは全て想像で書いているので、裏付けとかが欲しいので明日もうちょっと調べてみようかなぁ。
誰か仕様策定の経緯に詳しい人がいたら、是非なんかブコメとかでもいいので教えてもらいたい。
「 こうゆう理由でプリミティブ型の初期化構文はクラスに合わす事を強いられているんだ!」みたいな感じで。
]]>