HTMLのカスタムデータ属性(data-*)へのアクセス

小ネタです。

HTML5でカスタムデータ属性(いわゆる「data-*」属性)が導入されましたが、JavaScript(やTypeScript)からのアクセスの際のキー命名規則については、MDNの記述がやや微妙です(ここでは原典として英語版を参照しています)。

続きを読む

TypeScript+ElectronでUDPポートで受信待ち受け

タイトルのまんまです。ただし、サンプルコードではなく実際的な話です。

Electronでsocketを使う時は、mainプロセスでNode.jsの機能を使うことになります。私の場合、UDPを扱いたかったので、 dgram を使います。

私が必要だった機能は、次のようなものです。

  • 特定のIPアドレスNIC)とポートの組み合わせに対して、受信待ち受けを開始・終了できること
  • IPアドレスとポートの組み合わせが既に使われている可能性があるため、その場合は利用者にエラーを通知できること
  • 複数のポートが一括で開けること(※実際には、今は使っていません。つまり1ポートだけ)

この場合、受信待ち受けを開始するには、1つの組み合わせに対する受信待ち受けをPromiseにして、それを束ねてPromise.allで実行し、then/catchで結果に基づく処理を行えばよさそうです。

続きを読む

TypeScript最大のハマりポイント:this

TypeScriptは、全体としては整然として、素直に動作します。しかし、たまに意外な落とし穴があります(自分もはまったのですが、その時のコードが残ってませんでした。すみません)。

「なぜか型がundefinedになっている」などの問題が起きるようなら、次のTypeScript公式の文書を参考にするといいでしょう。

github.com

重要なのは「メソッドを参照だけして呼び出しが後、という形式はヤバい」ということです。それをアロー関数などで回避すれば、意味不明のトラブルに見舞われる頻度は下がると思います。

なお、参考として、以下に2016年12月1日版の原文の簡易版の和訳を示します。

(※注意)訳質が怪しい部分があります。誤りに気付いた場合、コメントなどいただければ幸いです。

続きを読む

TypeScriptを使ってみて「使うべき」と思った話

最近、ずっとブログを休んでいましたが、そろそろ再開。ただ、以前のような話は少なくなる見込みです。

個人的にTypeScriptとElectronでアプリケーションを書いています(Eto.Formsもいいのですが、プラットフォームごとの挙動の違いの扱いがつらいところです。GUIがシンプル、かつ、マルチプラットフォームでも主な対象がWindows、というケースなら向いていると思います)。

とりあえず、今回はポエム的に印象だけさらっと書いておきます。

開発の流れを作るのが本当に大変

JavaScript界隈のほとんどで言えることですが、開発で使う要素が非常に多く、なおかつ頻繁に変化しているため、基本構造や開発フローを作るのに苦労しました。

Electronも、TypeScriptとElectronの組み合わせも、サンプルはたくさんあるのですが、公式サンプルとあまり変わらないシンプルすぎるものか、特定のフレームワーク(ReactかAngular)に強烈に依存するものがほとんどと感じました。

自分の場合、少なくとも数年間、片手間で(仕事でも重要な趣味でもなく)メンテナンスを続ける、という前提で考えているので、頻繁に構成要素が更新されると追従コストがあふれてしまいます。また、データ構造はシンプルなもので、(追従コストを考えると)フレームワークは使わない方がいいと判断しました。

とりあえず数か月前に検討した結果、現状は次の形で動かしています。

  • 開発用のNode.jsは、WindowsではNodistを利用して管理
  • ビルドなどはnpm script
  • tsからjsへのトランスクリプトtsc
    • webpackなどでの一括ビルドは回避:ツールチェインの変更がしんどいのと、jsになった結果が簡単に分かった方が問題を切り分けやすいため
  • jsはwebpackで結合とuglifyをかけて、main.jsとrenderer.jsを生成
    • webpack内でbabel-loaderを利用
  • jQueryjQuery UI(両方ともjQuery UIのDialogだけが目的)はビルド後の領域に直接配置(npm管理外)
    • TypeScriptからは@typesで型定義のみ利用
    • DOM操作はDialog処理以外は(Dialogの中身も含めて)jQueryは使わず、素のTypeScript(Vanilla TS?)で操作

これでも開発用Node.jsとnpm、ビルド用のTypeScriptとwebpackとbabel、動作用のElectronは比較的更新が頻繁ですし、それぞれ動きは別なので、十分負担です。特にビルド周りは、近いうちに見直したいと思っています。

ここにNodeで使えるサードパーティのライブラリやrenderer側のフレームワークなどが加わると、個人が片手間に追従するのは厳しいのでは、と感じてしまいます。業務などで重複する領域を扱っていれば、追従の手間はそちらに投げられるのでしょうけど。

TypeScriptは段々楽になる

最初は、TypeScriptだと面倒と感じるシーンもありました(「JavaScriptなら簡単なのに~!」という気持ち)。しかし、使い続けると、むしろ楽に感じられてきました。

「自分で書いた領域が型つきになることで自動的な型チェックが済む」ことはよく言われますが、加えて、既存ライブラリ(NodeやElectronの標準APIも含めて)を使う上でも便利です。引数や戻り値の理解(やドキュメント記述)が不十分な部分は、TypeScriptのコーディング自体で詰まりやすく、結果的に早期に対処できるので。

もちろん型チェックは完璧ではありません。Electronだと、例えばmainとrendererを接続するIPCでは、引数チェックが途切れます。誤解していれば簡単にバグります。

それでも、危ない箇所は見当がつきやすいため、かなり落ち着いた気分でコードが書けます。正直なところ、素のJavaScriptでいきなり書くのは避けたいな、と思う程度にはTypeScriptが気に入りました。

VSCodeはVSじゃない

不満は、VSCodeです。自分が見かける範囲では非常に評価が高いのですが、Visual Studio上でC#のコードを書いてIntelliSyncの恩恵を最大限享受できていた自分が比べると、VSCode上でのTypeScriptは、ちょっと微妙です。

最も不満なのは、入力中の補完候補の表示が途中までしか出ないこと。

f:id:mokake:20180704183416p:plain

マウスカーソルをあてた状態ですら先が見えません。引数も戻り値も(確定しないと)見えないので、補完候補を活用したコーディングはしづらい、という印象を受けます。「IDEじゃなくてエディタだから」といっても、「フォーカスのあたった候補はシグネチャを全部表示する」ぐらいはやってくれても……と思ってしまいます。

まあそれでも3プラットフォームで共通で使えるし特別な設定が比較的少なくて済むので使っていますが。

RSAカンファレンス公式アプリ、再びデータ漏洩の指摘

セキュリティ・カンファレンスに参加すると、スマホアプリがあなたのデータを漏洩する

arstechnica.com

RSAセキュリティ・カンファレンスの公式アプリが、登録者の情報を漏洩しているという指摘がありました(ちなみに2014年にも、アプリのメーカーは違うものの、情報漏洩の脆弱性があったようです)。

これはアプリが受け取るキーを取得してしまえば、APIにリクエストを投げることで他人の情報まで受信出来てしまうというもの。

twitter.com

twitter.com

これを見ると、SQLiteのデータベースが直接ダウンロードできるように見えるので、登録情報は基本的に抜ける状態だったと考えるべきでしょう。主催側は次のように「名前だけしか流出してない」とツイートしているのですが、なぜか「本文が画像」です。

twitter.com

まあ、セキュリティの催しは、(特にBlack Hatあたりだと)ハニーポットもあったりするので、出席者はセキュリティについて考えつつ参加するのは当然……なのかもしれません。

Telegram規制とDomain Frontingの終焉

もう1か月ほど前の話ですが、プライバシーをウリにするチャットアプリの1つTelegramがロシア(とイラン)で禁止された件は、それなりに(一部では)国内でも話題になったように思います。

「プライバシーを売り物にはしない」―Telegram創設者、ロシアでの禁止を受けてコメント

arstechnica.com

一方、その後で出た、Domain Fronting停止の話は、それほど話題になっていないのでは……という気がします。

Googleのアップデートにより、検閲対抗ツールに問題が発生

www.theverge.com

Amazon、Domain Frontingをブロック。さらにSignalのアカウントにサービス停止の警告

arstechnica.com

この2つは、要するに「GoogleAmazonが"Domain Fronting"をやめた」ということです。

Domain Frontingは、何らかのサービス(TelegramやSignalなど)が自らの独自のドメインの代わりにGoogleAmazonドメインを表(Front)に立たせる、というものです。これを使うと、表向きはGoogleAmazonのような、多数の重要なネットサービスにつながっているように見えて、内実はTelegramやSignalの通信、ということが可能になります(いうまでもなくHTTPSなので内容の検出も困難です)。

GoogleAmazonとしては、Telegramなどの隠れ蓑になることでサービス全体が一部の国(ロシアや中東諸国)でアクセス禁止になるのは不利益が大きいと判断したのでしょう。

米陸軍、サイバー防衛競技会を分析。対面コミュニケーションが成績と強い逆相関と確認される。

米陸軍の研究者達「最強のサイバーチームは非社交的なチーム」

arstechnica.com

米のサイバー防衛の学生競技 MACCDCでの、メンバー間のコミュニケーションと結果を、陸軍研究所が調べた結果、強い相関は次の2つの項目にみられたそうです。

  • リーダーシップ
  • 対面コミュニケーション

ただし、リーダーシップは正の相関(強いリーダーシップがあるチームほど成績が良い)だったのに対して、対面コミュニケーションは負の相関(頻繁なほど成績が悪い)でした。

記事終盤にもあるように、これは他の分野でもみられるものです。実時間でチームによる活動をするもの(スポーツや音楽あたりがメジャーでしょうか)であれば、多くは共通すると思います。

しかし、それが改めて数値的に確認されたのは、一応の意義はあるかな、と思います。ちなみに、対面コミュニケーションは、参加者が身に付けたバッジで競技中の顔の様子を撮影、分析したそうです。