SONY のノイズキャンセリングヘッドフォン WH-1000XM2 を買った - 氾濫原
これまでは、2012年1月に買ったBOSE QuietComfort 15を使っていた。途中からコードが煩わしくなりBluetooth化したりして頑張って使った。 耳あて部分も2回ほど交換したけど、そもそもヘッドバンド部分が壊れはじめたり、ネイティブBluetooth対応のものが欲しくなってきたので、いよいよ買い替えることとした。QC15 結構頑張って使ったと思う。 ということで表題の通り、SONY WH-1000XM2 を買った。 BOSE QC35 と悩んだが、現状のノイキャンは SONY のほうが性能が良いそうなので、こっちにしてみた。ちょっと前の SONY のノイキャンヘッドフォンはやたら高音が強調されたり中音域がうるさかったり、ノイキャンもイマイチだったり、なんか微妙だった気がするけど、現行のは柔らかめの普通の音で変な味付けを感じなくていつのまにか最強になってて好印象と思った。
Google Fit の REST API で体重を自動入力する | tech - 氾濫原
(画像は過去に入力したデータを全て Google Fit へ入力しなおした様子) Fit API 全体の概念 単純にグローバルな「体重」に対して値を追加するみたいになっているわけではない。 各アプリケーション(サードパーティ含む)は自分用の「データソース」を作る。これはセンサーに対応する。例えば「体重計 HOGE-001」みたいなデータソース。このとき「体重 (com.google.weight)」とかデータの種類と「浮動小数点」とかデータ型の定義をしておく。 データソースの定義に従って、データソースにデータポイントを追加してく。例えば「体重は 69.95kg」みたいな。 こうしていくと、複数のデータソースから「体重」データがいくつもできることになる。 実は Google Fit の画面から体重を入力すると user_input というデフォルトで存在するデータソースにそのデータは蓄積され
固定回線異常との戦い | tech - 氾濫原
12月中旬から自宅回線に異常が発生していて困っていた。 最初の症状：上りが異常に遅い 最初の症状は上り速度が異常に遅いという症状。下りで70Mbps出ても上りは0.6Mbpsとかがザラ。この時点では明確な症状といえず、プロバイダに連絡するも軽くあしらわれる。この時点では上りだけおかしいので回線異常とは思わずプロバイダ側になんらかの制限がかけられているのでは？と疑っていた。 不規則に回線不通 12月下旬の年末ぎりぎりあたりから回線そのものが不通となる自体が発生。PPPoEセッションが一切張れず、ルータを外してノートPC直結でPPPoEもダメだったため、回線異常であると切り分け。 さすがに症状が明確なのでNTTに連絡したりしていたが、特定の時間になると回復したりして「今起きてます」という状態がつくれず連絡しても「問題なさそうなんですが…」とか言われて困る。 宅内VDSL端末の交換 ただ、宅内V
スプラトゥーン2 は「塗りで貢献できる」ゲームじゃないから騙されるな - 氾濫原
しばらく頑張ってやってたけど、すっかり自分の中の評価は落ち着いてクソゲーとなった。 ランク46、ガチは全ルールA-ぐらいまでやった。ただし表示合計ガチパワー1400ぐらいで適正と感じるのでA帯の実力はないと思う。 期待したものと違った やりたかったスプラトゥーンは「塗って楽しいゲーム」だけど、実際のスプラトゥーン2は「キルとらないとどうしようもないゲーム」 調べてみると1はこんなにキルゲーじゃなかったらしい。ガチ向けに舵を切った結果対象ユーザから外れたってことなんでしょう。ヘタならやめろというゲームになってる。これはニンテンドーのゲームじゃなかったのか…… 「塗りで貢献できる」は嘘 なんか、インタビュー記事とかで「いろんなプレイスタイルがある」「塗りでも貢献できる」「倒しにいかなくてもいい」みたいなのを読んでいたので、そうなのかと思って興味を持っていたんだけど、実際はそうじゃない。これです
Material Design Lite のテキストフィールドと Vue.js の相性があんまりよくない | tech - 氾濫原
Material Design Lite のテキストフィールドの input 要素を Vue.js で扱うとき、普通に v-model で two way binding すると、ラベル位置が更新されなくて文字が重なってしまったりする。つまりこれは Vue.js側の更新処理がMDL側に適切に伝わっていないために起こる。 MDLのソースを軽く読んだ解決として、mdl-js-textfield クラスがついている親要素に v-mdl 属性を追加し、以下のようにカスタムディレクティブを定義すると解決する。あんまり美しくないがしかたない。 静的な要素だけなら upgradeElementは必須ではないが、動的になると必須になるためついでにやっている。 Vue.directive('mdl', { bind: function (el) { componentHandler.upgradeEleme
ネットワーク内の Raspberry Pi の IP アドレスを調べる | tech - 氾濫原
いちいちモニタ繋いで確認とかするのは面倒ですが同じネットワーク内なら簡単に調べることができます。 まず ifconfig で所属するネットワークのブロードキャストアドレスを調べます。 $ ifconfig ... broadcast: 192.168.0.255 broadcast 向けで ping を数回打ちます。ARP テーブルを埋めるためなので結果は気にしません。ネットワーク内の接続機器が多いと大量にかえってくるのでほどほどにしましょう。 $ ping 192.168.0.255 ... arp -a で ARP テーブルを表示し、Raspberry Pi Foundation の OUI ( b8:27:eb) を持つものを列挙します。 $ arp -a | grep b8:27:eb 簡単です。 トップ tech ネットワーク内の Raspberry Pi の IP アドレスを調
見出しの改行位置を適正化する試み | tech - 氾濫原
やりたいのは 1文字だけの改行の拒否 - Hail2u のようなことの延長です。長めの見出しがブラウザによって改行されると、どうもバランスが悪くなったり可読性が微妙になることが多い。これをなんとかする。 仕様 元の高さから変わらないこと 非同期にやってもガタガタしないこと 各行ができるだけバランスをとること 文字数 (正確には幅) をあわせる 元の高さから変わらないことというのは行数を変えないということです。これを制約にしてページ全体の高さに影響を与えないようにすることで、非同期的に行数を調整しても閲覧に支障がないようにという意図があります。 「各行のバランス」はできるだけ行ごとの幅を揃えるという意味でいっています。基本的に幅が揃うことはないので、あくまでできるだけです。また、揃わない場合には一番下の行が一番長くなるようにします。これはデザイン上、重心が下になるほうが安定して見えるからです
一眼レフは終わったな、と思った | tech - 氾濫原
デジタル一眼レフカメラって基本的にフィルムをデジタル化しただけだったけど、そこからデジタルならではという機能が増えていって、ついにはミラー機構とか根本的な撮影体験に手が入ってきてるみたいな昨今。レフレックスの価値は主にファインダー画像と撮影画像が一致することだったが、これについては既にライブビューが機能的に勝る。今はまだAF性能でレフレックスに優位があるが、像面位相差AFがだいぶ進化していて、今後数年ぐらいで追いつくんじゃないかという感じがする。 優位さの比較 ミラーレス一眼の優位 ミラーショックがない ミラーアップ撮影とかする必要がない。騒音も少なくなる フランジバックが短い 短いは長いを兼ねる 拡大表示による厳密なマニュアルフォーカスが可能 一眼レフの場合フォーカシングスクリーンを交換するとピントをあわせやすくなるが、それをするとファインダーが暗くなる欠点があり、暗所だともはや困難とい
IFTTT の通知チャンネルに LINE が増えたので家庭内BOTを作った | tech - 氾濫原
家庭内 Slack とかやってる人は結構いますね。羨しいなと思ってましたが、うちの妻は英語と技術的なことがさっぱりわからないので Slack ですら敷居が高く、インストールしたり説明 (チャンネルの概念とか、それがどういうノリで機能するかとか……) するのもめんどうなので家庭内チャットボットみたいなのは全くやる気がしなかったわけですね。Slack って英語だったけ?と思うかもしれませんね。普通気にもとめないでしょうが英語なんです。ウェブ系IT企業のノリって一般的じゃないんですよ、知っていましたか。 それはともかく、最近 IFTTT の通知先に LINE が増えたり、LINE への通知の API ができたりしたので、家庭内チャットでワンチャンアルデと思ってちょっと頑張って試すことにしました。 つくった IFTTT レシピ エリアを抜けたらグループへ通知 帰宅しはじめを自動的に伝えるようにとい
ErgoDox ではないナニか。オープンソースかつ Bluetooth 接続のキーボード | tech - 氾濫原
ここ数ヶ月ぐらいキーボードを作っていた。そのためにいろいろ yak-shaving としかいいようがないことも多々していた。 いろいろ書くことが多いので、細かい設計などについては別途エントリを分ける。 コンセンプトとキーレイアウトおよび技術仕様の決定 回路設計とアートワーク・実際の製作 ファームウェアの実装 あたりをそれぞれ別途詳細なエントリを書く。だいたいの人は細かいことはどうでもいいと思うので、概要のみこのエントリにまとめる。 コンセプトや特長 UNIX ベースのキーレイアウト (というかHHKBをベース) とし、違和感なしに分割キーボードとする。 キー配列 UNIX キーボードを2分割した形を基本にする。つまり HHKB とほぼ同じで、Ctrl キーはAの左、ESC は 1 の左など。 矢印キーはどうしても欲しい (HHKB への大きな不満のひとつ) F1〜F12キーもできれば欲しい
TF-IDFとコサイン類似度による類似エントリー機能の実装 | tech - 氾濫原
TF-IDFによる類似エントリー機能の実装をしてみました。ほぼSQLiteですませるような構成です。 やっていることの概要 エントリーのHTMLを適当なワード単位に分割 タグ削除とか記号削除とかしつつ、簡単な形態素解析で分割 エントリごとのワード出現回数をSQLiteに全て入れる (テーブル構造的には転置インデックスとして機能) エントリ・ワードごとにTF-IDF の計算 エントリごとにTF-IDFのベクトルとして正規化 エントリごとに共通語が一定数を超えるエントリ複数に対しコサイン類似度でスコアを計算 ワード分割 MeCab を使った形態素解析などでもいいのですが、お手軽にやりたかったので以下のようにしています。 my $text = ...; $text =~ s{<style[^<]*?</style>}{}g; $text =~ s{<script[^<]*?</script>}{
JSDeferred -> Promise 置き換え方法 | tech - 氾濫原
もはや Promise がスタンダードに入り、モダンな実行環境ではポリフィルすら必要なく使えるケースが増えましたね。 かくいう自分も JSDeferred は使っておらず完全に Promise 依存に切替えております。外部ライブラリ依存なんてないほうがいい!! JSDeferred と Promise の違い 機能的にはほぼ変わりがないので機械的に置き換えできますが、Promise は1度だけしか resolve できない点だけ違うので注意が必要。JSDeferred は値を保持しませんが、Promise は resolve した値を保持し、その後の then ではその値が返ってきます。 var resolver; var promise = new Promise(function (resolve, reject) { resolver = resolve; }); promise.t
リファレンスマニュアルをインクリメンタル検索するやつを Electron で実装した | tech - 氾濫原
https://github.com/cho45/Chemrtron 機能 インデックス用のクローラ 作ったインデックスのインクリメンタル検索と表示 できるだけ雑にインデックス作成用のクローラを実装できるようにしたかったので、そのようになっている。 オフライン閲覧はあんまり考慮してないが、file:// でインデックス登録すればオフラインでも使えると思う (ネットワークよりもディスクサイズのほうが厳しいのでオフラインにあまり興味がない…) 動かしかた レポジトリをクローンする場合 electron-prebuilt が必要。 npm -g install electron-prebuilt git clone https://github.com/cho45/Chemrtron.git cd Chemrtron electron . または https://github.com/cho45
CopyHook というペーストボードの中身をいじるツールを作った | tech - 氾濫原
https://github.com/cho45/CopyHook ペーストボードにコピーが行われたときに、JavaScript で何かするというツールを書いた。 競合するソフトウェアがいくつかあると思うけど (dot-clipboard とか)、すぐできそうだし Swift で書かれたのはなさそうということで書いてみた。 ユースケースとしては Slack のチャット画面を適当にコピーしたのを、自動でフォーマットしてペーストしやすくする リッチテキストとしてコピーされるのがウザいので、プレーンテキストにしてしまう 画像を自動でグリッチする というのがあります。 つかいかた 起動するとアクセシビリティを有効にしろといわれるのでする 有効にしたらもう一度起動する。 コピーのイベントをキーイベントの Cmd+C を見ることで実現している (設定で変更可能) あとフォーカスされているアプリとかウィ
スクリーンキャスト用のキーストローク表示アプリ | tech - 氾濫原
前にMacRuby でスクリーンキャスト用のキーストローク表示スクリプトを書いたんですが、それを Swift で書きなおして機能を追加したりしてアプリにしました。 https://github.com/cho45/KeyCast 追加の機能：パスワードフィールドで自動非表示 基本的に AXSecureTextField への入力って、そもそもアクセシビリティのコールバックにこない？っぽいのですが、一部のアプリでは飛んできてしまったり、よくわからない挙動をします。 なので、こちらのツール側で、パスワードフィールドかどうかを判定して非表示に切り替えています。 と書くと簡単なんですが、実際一番やりたい Google Chrome ではデフォルトではアクセシビリティオブジェクトが生成されないみたいな罠があったり (VoiceOver が有効でなければアクセシビリティオブジェクトを作らない)、やっか
自宅をかっこいい作業環境にしたい | tech - 氾濫原
自宅で使っているデスク Garage CL-147H というやつ (約24kg)。fantoni GT-147H というやつ (約34kg) のほうがかっこいいけど、高い。 天板の色が濃くて、丈夫なやつが安くほしかった。これはかなり満足してる。ウォールナットタイプは幕板がないので左右に揺れやすいみたいだけど、普段使いでは全く気にしたことはない 。 天板自体に鉄パイプで補強がしてあり、60kg まで耐荷重がある。最近のモニタは軽いのでまずギリギリになることはなさそう。ゆすろうとすれば揺れるが、キーボード叩きまくる程度ではほとんど揺れることはない。キーボードを叩いてモニタが揺れたりすると、案外かなりイライラしてくるので、机はできるだけ丈夫で重いのを買うほうが良いと感じる。 デスクの配置 窓に背を向ける形、部屋の中のほうを向いて座っている。こうするとモニタを隔てて狭いスペースに身体が押しこめられ
4Kモニタ、24インチ (P2415Q) か、27インチ (P2715Q) か - 氾濫原
最近でた安い4Kディスプレイはサイズ違いで2つある。価格もすこし違うがだいたい一緒で、サイズだけが違う。 スペック 4K は 16:9 なので、横に長いタイプしかない。 P2415Q 23.8インチ 185ppi 527.04 mm x 296.46 mm P2715Q 27インチ 163ppi 596.74 mm x 335.66 mm 検討 24インチでもA4 (210 x 297)見開き (=A3 420x297) 原寸表示は可能。ただし、A3ノビ (483x329) は原寸表示不可 (ノビ分はトンボ用なので、実質的には問題ないと思われる) 一般向け写真プリンタではA3ノビが限界なので24インチで十分な画面サイズといえる。 ppi 的には高いほうが正義なので、24インチのほうがいい。デスクトップ用だと 200ppi ぐらい欲しい気持がある。 一方、dot by dot で使った場合、
YAPC::Asia で「ウェブエンジニアのローレベルプログラミング」という発表をしました | tech - 氾濫原
ちょっと時間に対して話したいことが多すぎて、各分野での掘り下げが足りなかったとは思いますが、一通り下のほうまで盛りこみました。 電子工学について：自分は学校で電子工学を体系的に学んだことはありません。 YAPC 会期中はそこらへん歩いてます。
ユーザ由来の構造化データによるSQLインジェクション | tech - 氾濫原
Kazuho's Weblog: The JSON SQL Injection Vulnerability について。元記事をはっちゃめっちゃに要約すると SQL::Maker にユーザから受けとったデコード済み JSON をそのまま突っ込むと SQL インジェクションになる場合がある SQL::Maker 側でそういったことが起こらないように strict オプションをつけたから、できればそっち使え 別に SQL::Maker に限らないから気をつけろ という話っぽい。本来であればユーザ入力をタイプチェックをすべきだけど、クエリビルダレベルでも、脆弱性にならないようにもうちょっと考慮してもいいよねという趣旨かな… strict モードは非互換なので、既存のコードが動かなくなる可能性があるようです。 Teng での対応 Teng を使っているとデフォルトで SQL::Maker がクエリビ
YAPC 初心者ほど YAPC にトーク応募すべき10の理由 - 氾濫原
懇親会対策 基本的にこういうイベントは懇親会が一番重要といってもいいぐらいだが、コミュ障だと懇親会とかで誰と何を話せばいいのかさっぱりわからなくなる。LT でもなんでもいいがトークをすると一定の人から認識され、トーク後や懇親会などで話しかけられやすくなる。逆に話かける側としても「あれおもしろいですね」と気軽に言いやすくていい。 また一応の話題を前もって作れるのでコミュニケーションしやすくなる。YAPC にきて「いやぁ今日はいい天気ですね」とか話はじめるわけにはいかないので、このような話題を持っておけるのは気が楽になる。 つまりコミュ障ほど応募すべき 強制的アウトプット 普段生活していると、アウトプットといってもブログになんちゃら書いて終わりがちか、あるいはそれ自体も忘れて日々バタバタ過ごしてしまう。何らかのイベントのタイミングにあわせてアウトプットを出すといいモチベーションになる。 それと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
