Go のライトバリアに関するバグを修正した話 : DSAS開発者の部屋
Goのランタイムのバグを踏んで解決しました。解決までの過程を記事にします。 同じようなランタイムのバグを踏んで、小さい再現コードを作れない場合の参考にしてください。 自分のプログラムを疑う あるSlackチャンネルで Go で書かれたサーバーのクラッシュが話題になっているのを見つけました。その時に共有してもらったトレースバックです。 runtime: pointer 0xc007b8af97 to unused region of span span.base()=0xc004000000 span.limit=0xc004002000 span.state=1 fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?) runtime stack: runtime.throw(0xc046ca,
「推測するな計測せよ」は「性能上がらなかったら捨てろ」ではない : DSAS開発者の部屋
「推測するな計測せよ」という格言がよく知られています。この格言は（ISUCONに優勝した）Goの作者の一人でもある、 Rob Pike 氏の言葉が元になっています。 ルール1: プログラムがどこで時間を消費することになるか知ることはできない。ボトルネックは驚くべき箇所で起こるものである。したがって、どこがボトルネックなのかをはっきりさせるまでは、推測を行ったり、スピードハックをしてはならない。 ルール2: 計測すべし。計測するまでは速度のための調整をしてはならない。コードの一部が残りを圧倒しないのであれば、なおさらである。 UNIX哲学 on Wikipedia このルールは、推測だけで高速化のための変更をすることを諌めていますが、直接に高速化の効果が無い変更をするなとは言っていません。 正しいデータ構造やアーキテクチャは、それだけでは性能が向上せず、それを利用した改善を入れて初めて効果が
音を利用する 2 〜Android デバイスでの音波通信：準備編〜 : DSAS開発者の部屋
音を利用する 1 この記事の内容 前回の記事では音を媒体とする機器間の情報通信が近年ふたたび注目されていることに触れ複数の具体的な事例を挙げました。近距離通信手段としての音波の利用には技術的好奇心をそそられますが、それをどのように形にすればよいのかは案外ピンと来ません。そこで、Android デバイスを題材に手元で行った音波通信の実験と試作の内容をこれから何回かに分けて紹介します。今回は準備編として実装に必要な要素の整理を行います。 準備 1. Andorid での音声入出力処理を覚える 入力：AudioRecord クラス 出力：AudioTrack クラス 試作 処理のイメージ 動作の様子 ソースコード 準備 2. 任意の周波数の音波を生成・出力する サイン波について サンプリングレートについて 試作 動作の様子 ソースコード スプレッドシートを使っての検証 準備 3. 集音したデータ
音を利用する 1 : DSAS開発者の部屋
はじめに 技術・インフラの進化とともに情報通信の効率が加速を続ける状況にあって、「音」を利用した往年の通信手法が近年あらためて注目されています。関連する話題をいくつか以下にピックアップしてみます。これらはいずれも最新の技術や文化に密着した要件での応用という点で共通しており、懐古的なモチーフとはまったく無縁であることが興味深く感じられます。 （※各引用文中の青字表示は筆者によるものです） お買い物体験をあたらしく （株式会社スポットライト様サイトより） スポットライトの技術 (1) 位置検出技術 独自の超音波技術により、Andorid/iOS双方に対応した、正確でセキュアな来店検知が実現できます 『SSC』Smart Sonic Communication 超音波通信のご案内 （ドリームニュース様サイトより： 2012-06-20） SINGAPORE SDI PTE LTD（本社：シンガポ
Android で今後ネイティブ実行形式を扱う際に注意すべきこと : DSAS開発者の部屋
5.1.1 (API 22) 環境で実行時の様子 root@generic:/data/local/tmp # ./hello error: only position independent executables (PIE) are supported. root@generic:/data/local/tmp # ./hello_pie hello! root@generic:/data/local/tmp # ./stone error: only position independent executables (PIE) are supported. root@generic:/data/local/tmp # ./stone_pie May 1 10:40:28.556080 start (2.3e) [375] May 1 10:40:28.570865 stone 2.3
Go ではエラーを文字列比較する？という話について : DSAS開発者の部屋
Go で関数の戻り値のエラーを判別するときに、エラーメッセージの文字列をチェックするコードが存在します。 (例) これは、 Go が言語設計としてエラー処理が貧弱だったり、標準ライブラリがエラー処理を軽視しているからでしょうか？ 言語設計や標準ライブラリのAPIの設計をみて行きましょう。 TL;DR 言語設計としては、Java的例外機構と同等以上の（文字列比較によらない）エラー検査が可能 ただし Go のエラーに関する哲学により、公開されていないエラーが多い 実際にエラーを文字列比較されている実例についての解説 Go のエラー検査方法 Java の例外機構では、例外をキャッチするために専用の構文が用意されており、型によりマッチングすることができます。 これはクラスのツリー構造を利用してサブクラスをまとめて分岐することもできます。 一方で、同じクラスでも値によりエラー処理が異なる場合には、
Goのdatabase/sql.Stmtのスケーラビリティを改善しました : DSAS開発者の部屋
先日、 Goに初めて私のパッチが取り込まれ 、コントリビュータに仲間入りしました。 このパッチは、 database/sql.Stmt をヘビーに使った時に性能がだいたい16コア以上のコア数にスケールしないという問題を解決するものです。 こういった問題をどうやって調査するのかと、Goにパッチが取り込まれるまでの手順を紹介します。 背景 私は TechEmpower の FrameworkBenchmarks という、いろんな言語/フレームワークで同一のアプリを作ってベンチマークするというプロジェクトで、主にPython関連のメンテナをしています。 Goにも興味があるので、Ginというフレームワークを追加したりコードレビューに参加したりしています。 2014-05-01 に行われた前回のベンチマーク Round 9 では、 PEAK Hosting が実行環境に加わりました。この環境は、デュ
Dropbox アカウントひとつで利用できるプッシュ通知機構 : DSAS開発者の部屋
2018年6月追記： Dropbox API の仕様変更により以下の内容はすでに obsolete です。記事は残しますが、過去の情報であることをご了承下さい。 Dropbox 社は広く知られるファイル系のサービスとは別に 2013年より非ファイル形式の構造化データの保存・読み出しに対応するデータストアサービスを公開しており、Dropbox アカウントを持っていれば Dropbox Datastore API 経由でこのサービスを利用できます。同 API は全体的にシンプルで SDK のサポート範囲も広いため自作のソフトウェアへ手軽に組み込むことが可能です。 自前でサーバ環境を構築・運用する手間なしにレコードイメージのデータをネットワークストレージ上で取り回せるのは便利で、また多くの人がアカウントを持っていることへの安心感もあり、この Dropbox のデータストアサービスはさまざまな用途
「パスワードの管理を避ける」という考え方 : DSAS開発者の部屋
手持ちのアカウントが増えてくるとパスワードの管理方法が考えどころとなります。このところメジャーなネットサービスへの不正ログインやアカウントの悪用が相次いで報じられていることもあり パスワード管理の重要性は「古くて新しい問題」としてあらためて広い層に浸透しつつあります。 その一方でパスワードをきっちり管理することは必ずしも簡単ではありません。平易な内容だと第三者によって類推・導出されるリスクが大きいものの複雑にすると覚えにくい。だからと言って複数のサービスで同じものを使いまわすとそれが漏洩した場合に一斉に攻撃を受ける危険がある。結局、安全度の高いパスワードをサービスごとに使い分けることは人間の記憶だけでは困難なので何らかの外部記憶を利用することになります。ただし、それが何らかのデバイスであれコンピュータデータの形式であれ、情報としてそこへ保存した時点で盗難・流出の可能性はゼロではなくなります
Android NDKで使えないシステムコール・ライブラリ関数一覧 : DSAS開発者の部屋
Android NDKでCのコードを書いていると、普段のCプログラミングでは悩まないことで悩むことがあります。たとえば、AndroidのlibcはGoogle製でPOSIXに準拠していません。他のUnix系環境であれば必ず実装されているライブラリ関数が存在しないなどの罠があるため、メジャーなツールをビルドするのにもconfigure;makeが素直に通らなかったりします。 それだけでなく、Android NDKが提供する開発環境にも問題があります。特に、NDKで配られているヘッダファイルとビルド用の共有ライブラリで対応が取れていないのは頭痛のタネです。どういうことかというと、ヘッダファイルに定義されているシステムコールを使おうと思ったらリンカエラーが出ることがあります。 また、システムコールの一部については、カーネルレベルでは正しく実装されているもののlibcにインターフェース実装がなく、
TCP高速化プロキシ「AccelTCP」を公開しました : DSAS開発者の部屋
昨年末からずっとこんなことをしてまして、この時期になってようやく今年初のブログ記事です。 進捗的なアレがアレでごめんなさい。そろそろ3年目に突入の @pandax381です。 RTT > 100ms との戦い 経緯はこのへんとか見ていただけるとわかりますが「日本と海外の間を結ぶ長距離ネットワーク（いわゆるLong Fat pipe Network）において、通信時間を削減するにはどうしたらいいか？」ということを、昨年末くらいからずっとアレコレやっていました。 送信したパケットが相手に到達するまでの時間（伝送遅延）を削減するのは、光ファイバーの効率の研究とかしないと物理的に無理なので、ここで言う通信時間とは「TCP通信」における一連の通信を完了するまでの時間です。 伝送遅延については、日本国内のホスト同士であれば、RTT（往復遅延時間）はだいたい10〜30ms程度ですが、日本・北米間だと10
スマホアプリと米国輸出規制に関するメモの続き : DSAS開発者の部屋
前回の記事の続きです。今回は、前回の記事において米国商務省によるフローチャートで輸出規制への該非判定を行った iOS アプリ「stone for iOS」を App Store へ登録申請し、それが一度のリジェクトを経て公開されるまでの経緯を紹介します。 ※記事へ引用の原文および参考訳は 2014年4月7日時点のものです ※引用文中の赤字・強調表示は筆者によるものです。「：」は引用の中略を示します 許可例外「TSU」とは？ さて、暗号を使用するオープンソースの iOS アプリ「stone for iOS」は、ソースコードが「一般に入手可能（publicly available）」であることから 米国輸出管理規則上の許可例外のひとつである「TSU」の適用が可能で、その措置により商務省の輸出許可を得ることなく米国内の App Store からの輸出が可能であることがわかりました。 一連の許可例
スマホアプリと米国輸出規制に関するメモ : DSAS開発者の部屋
記事の概要 スマートフォンの普及に伴いそれをターゲットとするソフトウェアベンダや開発者が増えています。スマートフォン向けのアプリケーションを公開する際には通常 Google Play や App Store 等のアプリケーションストアを使用しますが、これらのストアの拠点は米国にあるためそこでアプリを配布することは米国からの輸出に該当し 同国の輸出法の適用対象となることに注意が必要です。 米国の輸出規制の内容は EAR (Export Administration Regulations 輸出管理規則) に定められており、規制に該当するか否かは「何」を「どこへ」輸出しそれを「誰」が「何のため」に使用するかによって決まります。規制対象にあたる輸出を行う際には米国商務省へ申請を行い有効期限を伴う 輸出許可（Export License）を得なければならないケースもありますが、EAR にはある品目
Android/iOS向けテストアプリ配信ツール 「EMLauncher」を公開しました : DSAS開発者の部屋
先日、TestFlightのAndroidサポート終了、Appleによる買収といったニュースが世間を騒がせましたが、皆さんテストアプリの配信はどうしていますか？ KLabでは自社製のテストアプリ配信ツール「EMLauncher」を使用しているのですが、せっかくなのでOSSとして公開することにしました。 https://github.com/KLab/emlauncher 今すぐ試す 今すぐ試したい方のために、セットアップ済みのAWS EC2イメージを用意しました。 ami-9b295f9a EMLauncher Sample インスタンスを起動後、設定ファイルのAWSアカウント情報を編集し、S3のバケットを作成してください。 (設定の詳細はconfigディレクトリのサンプルをご覧ください) /home/ohoflight/emlauncher/config/emlauncher_confi
QR コードを機器間での秘密情報の輸送に利用する試み : DSAS開発者の部屋
QR コードのもうひとつの利点 QR コードはインターネットアドレスなど所定のテキストデータを簡単に機器に取り込むための手段として広く利用されています。印刷物に限らずさまざまな媒体で扱えるのも便利ですね。 先日、公開鍵暗号を使う Android アプリを試作していた折に、自分の端末 A で生成した秘密鍵を手持ちの別の端末 B へ安全に輸送する手段の検討が必要になりました。やり方はいろいろありそうですが、よりシンプルな方法をとあれこれ考えている内に、机上に無造作に置いたチラシの QR コードにふと目が留まりました。 QR コードからのデータ取り込みは通常光学的に行われます。このことは電子機器の視覚を利用したデータ通信と考えることができるでしょう。第三者による情報窃取の可能性がしばしば問題となるネットワーク通信とは異なり、「目」を使っての情報伝達には物理的に介入することが難しいため、デジタルデ
「ZXing QR コードスキャナー」の内部処理を追う : DSAS開発者の部屋
ZXing ("Zebra Crossing") Team による「QR コードスキャナー」 （以下、"ZXing スキャナ"と略記） は操作性が良く人気の高い定番 Android アプリのひとつです。同アプリでは ZXing Team 自らが開発を継続しているオープンソースのバーコード処理用ライブラリが使用されています。 このライブラリの優秀さはスマートフォンでバーコード／QR コードを処理する際の実質標準の座にある状況からも裏打ちされていますが、ZXing スキャナの「使いやすさ」は本ライブラリの性能のみに依るものではなくアプリの実装に大きく支えられています。ZXing スキャナのソースコードは公開されているので、それに学べば本家と同等の使いやすさを備えた QR コードリーダーの自作が可能となるはずですね。操作性の良いリーダーを自作できるのであれば QR コード読み取り機能をアプリへ組
gitでバイナリファイルを気軽に扱えるフィルターを作りました : DSAS開発者の部屋
ネイティブアプリの開発とかしてると、ついつい git にスプライトの png とか一緒にコミットしてしまって、気づいたらリポジトリサイズが 1GB 超えてたとかありますよね。 git annex とか、本格的なアセット管理システムとか使えば良いんだけど、普通のgitコマンド覚えるだけでいっぱいいっぱいな人にさらに他のツールまで覚えてもらうのは大変です。 そこで、登録しておいた拡張子のファイルはハッシュ値だけをリポジトリに格納し、ファイルの内容は別のディレクトリやAmazon S3に格納する git-largefile/gits3 を作りました。 git-largefile/gits3 は git の filter として動きます。 filter は通常改行コードの変換をしたり $Id$ のようなキーワードを変換したり行末のスペースを消す、文字通りフィルターなのですが、ここでファイル本体から
Android パッケージインストール処理のしくみを追う : DSAS開発者の部屋
身近な話題でありながら中身のよくわからないことを調べてみるのは興味ぶかいもので、そこから得た知識が意外なところで役に立つことも少なくありません。かねてより Android 環境へアプリケーションをインストールする際に内部でどのような処理が行われるのかに関心を持っていたのですが、知りたい情報がなかなか見当たらないため手元で調査を行いました。その内容を公開します。 まとめ ※クリックすると大きな図が開きます ※PackageInstaller を起動した状態での関連プロセスの例 $ ps USER PID PPID VSIZE RSS WCHAN PC NAME root 1 0 268 180 c009b74c 0000875c S /init root 36 1 812 244 c02181f4 afd0b45c S /system/bin/installd root 33 1 60900
inotify で Android 上のファイル I/O を監視する : DSAS開発者の部屋
先日 Android のソースコードを読んでいた折に、所定の処理においてシステム上で発生するファイル I/O の流れを確認したいと思いました。処理の全体像を把握する上で有用と考えたためです。そこで inotify を利用することにしました。 Android の Linux カーネルには inotify が含まれており、Android SDK には inotify を利用した FileObserver クラスが用意されています。 inotify で Linux ファイルシステムのイベントを監視する - www.ibm.com FileObserver | Android Developers - developer.android.com Android FileObserver - The Underlying inotify Mechanism and an Example Androi
エンコードされた AndroidManifest.xml を読む : DSAS開発者の部屋
アプリケーションマニフェストである AndroidManifest.xml をはじめ、Android アプリを構成する各種 XML ファイルは apk へのパッケージングの段階でパースされ独自のバイナリ形式にエンコードされます。 このファイルを扱う処理をコンパクトに実装したいと思ったのですが、現時点では形式に関する公式の資料が存在しないことがわかり aapt を参考に手元でフォーマットの分析を行いました。パーサ試作例とともにその内容を公開します。 1. データ例 (A) テストアプリ「MyApp」用に記述した生の AndroidManifest.xml <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="jp.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
