http://mumumu.github.io/blog/2013/04/26/trying-to-write-blog-on-github-dot-io/
github.io にブログを移行してみることにした。これがここでの最後のエントリになる。
Google の様々なサービスとの連携は素晴らしいと思う。けど、少し気分転換をしたいのと、プログラミング的な記事を書く時に gist に書かないと不便だという点は気になっていた。
けど、気分転換という面が一番大きい。 github.io にしたって、画像の管理が面倒だという欠点はあるわけだし。どこのブログエンジンに行ってもぎゃあぎゃあいうなら自作しろ、という話である。
久しくここに書いていなかったけれども、2013年に入って生活も随分変わりました。いろんな意味で丸くなりそうな気がします。けれども、何があっても、いろんなことをプラスに変えていけるような動きをしていきたい。初心は忘れてはいけない。そう思います。
ですので、このブログの続きは github.io をご覧くださいませ。宜しくお願いします。
mumumuの日記
Development, Translation, daily life, thoughts, and so on.
2013/04/26
2013/01/01
Happy New Year 2013
旧年中は大変お世話になりました。
本年も宜しくお願い致します(*´〜`)
今年はいろんな意味で変化が大きい年になりそうです。
そんな変化の波も頑張って乗り越えていきたいですです。
2012/12/24
Bad arg length for Socket::pack_sockaddr_in - tcp socket communication by Perl
http://www.perlmonks.org/?node_id=642313
Perl を久々に触っていて、TCP 通信のコードを書こうと思った。ただ、自分がHACKしようと思っているソフトウェアはモダンなライブラリを使っておらず、低レベルなAPIを使っていたのでそれに合わせることにした。
そこで書いたのが以下のコードである。
このコードを実行すると「Bad arg length for Socket::pack_sockaddr_in, length is 14, should be 4 at invalid_tcp_code.pl line 15.」というエラーになる。なんでやねんと数十分悩み、よくよく pack_sockaddr_in関数のドキュメント を読んでみると、以下のようになっていた。第2引数には inet_aton 関数の戻り値を渡せとある。
Takes two arguments, a port number and an opaque string (as returned by inet_aton(), or a v-string).
要するにドキュメントはよく読みましょうね、、ってことで。。
動くコードの全体は以下の通りである。www.google.com に HTTP通信するコードだ。エラー処理は省略しているので注意。
Perl を久々に触っていて、TCP 通信のコードを書こうと思った。ただ、自分がHACKしようと思っているソフトウェアはモダンなライブラリを使っておらず、低レベルなAPIを使っていたのでそれに合わせることにした。
そこで書いたのが以下のコードである。
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
#!/usr/bin/perl -w | |
use strict; | |
use warnings; | |
use IO::Socket; | |
use Data::Dumper; | |
my $socket = IO::Socket::INET->new( | |
Proto => 'tcp', | |
Type => SOCK_STREAM | |
) || die "creating socket: $!"; | |
my $port = 80; | |
my $remote_addr = "www.google.com"; | |
$remote_addr = pack_sockaddr_in( $port, $remote_addr ); | |
connect($socket, $remote_addr); |
このコードを実行すると「Bad arg length for Socket::pack_sockaddr_in, length is 14, should be 4 at invalid_tcp_code.pl line 15.」というエラーになる。なんでやねんと数十分悩み、よくよく pack_sockaddr_in関数のドキュメント を読んでみると、以下のようになっていた。第2引数には inet_aton 関数の戻り値を渡せとある。
Takes two arguments, a port number and an opaque string (as returned by inet_aton(), or a v-string).
要するにドキュメントはよく読みましょうね、、ってことで。。
動くコードの全体は以下の通りである。www.google.com に HTTP通信するコードだ。エラー処理は省略しているので注意。
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
#!/usr/bin/perl -w | |
use strict; | |
use warnings; | |
use IO::Socket; | |
use Data::Dumper; | |
my $socket = IO::Socket::INET->new( | |
Proto => 'tcp', | |
Type => SOCK_STREAM | |
) || die "creating socket: $!"; | |
my $port = 80; | |
my $remote_addr = "www.google.com"; | |
$remote_addr = pack_sockaddr_in( $port, inet_aton($remote_addr) ); | |
connect($socket, $remote_addr); | |
my $query = "GET / HTTP/1.0\n\n"; | |
send( $socket, $query, 0, $remote_addr ); | |
my $buffer; | |
my $recv_remote_addr = recv( $socket, $buffer, 8080, 0 ); | |
print Dumper $recv_remote_addr; # should be empty string. | |
print $buffer; | |
1; |
Tags:
development,
perl
[memo] Apache Core Dump on CentOS
CentOS で Apacheモジュール のデバッグをしていて、 Core Dump を吐かせようと思ったときに少し迷ったのでここにメモしておく。
Core Dump はプログラムがクラッシュしたときのメモリの状態を示すものであり、gdb でいろいろ解析ができるのでデバッグ時に重宝するのだが、サイズが結構巨大になる。それに Production な環境では不要なものなので、ディストリビューションはあの手この手で Core Dump を出力しないようにしているのが普通だ。
ググるといろんなやり方が書いてあるけれども、ディストリビューションによって手順が違うのに加えて、一般論も混じっていてかなりわかりづらい。CentOS(Red Hat系ディストリビューション) で一番簡単なのは以下だ。
これは、/etc/init.d/functions で ulimit を環境変数で毎回設定していることによる。
----
1. httpd.conf に CoreDumpDirectory を追加。
CoreDumpDirectory /tmp/
2. コアファイルの ulimit 設定を指定して Apache を再起動
DAEMON_COREFILE_LIMIT=unlimited; /etc/init.d/httpd restart
Core Dump はプログラムがクラッシュしたときのメモリの状態を示すものであり、gdb でいろいろ解析ができるのでデバッグ時に重宝するのだが、サイズが結構巨大になる。それに Production な環境では不要なものなので、ディストリビューションはあの手この手で Core Dump を出力しないようにしているのが普通だ。
ググるといろんなやり方が書いてあるけれども、ディストリビューションによって手順が違うのに加えて、一般論も混じっていてかなりわかりづらい。CentOS(Red Hat系ディストリビューション) で一番簡単なのは以下だ。
これは、/etc/init.d/functions で ulimit を環境変数で毎回設定していることによる。
----
1. httpd.conf に CoreDumpDirectory を追加。
CoreDumpDirectory /tmp/
2. コアファイルの ulimit 設定を指定して Apache を再起動
DAEMON_COREFILE_LIMIT=unlimited; /etc/init.d/httpd restart
Tags:
development
2012/12/15
Titanium 2.x traps
これは、Titanium Mobile Advent Calendar 2012 の参加エントリです。
いやーついに Titanium 3.0 がリリースされましたね! このエントリでは、僕が 2.x を触っていてハマった様々な罠について述べていきますが、3.0 以降ではこれらが全てfixしていることを祈っています。
今回のエントリでも、自分が iPhone, Android 両対応アプリを開発した経験に基づいていますので、皆様の環境では必ずしも再現しない場合もあると思いますが、その点は御容赦くださいませ m(__)m
1. String.format ってクロスプラットフォームで使うときはちょっと注意いりませんか?
今年の Advent Calendar でも触れられている String.format 関数。C言語でのsprintf関数の如く、文字列処理では重宝する関数なのでいやー便利ですよね皆さん! といいたいところなんですけど、、
String.format("input value was %d !!!", "hogehoge");
とかいう具合で誤った使い方をすると以下のような感じだったと記憶しています。
A) iPhone ではアプリが落ちる。
B) Android ではスルーされた。。なんで通るんだ。。
そもそも文字列連結処理が面倒だという理由で この関数を自分は使っていたので、"+" 演算子を使って回避した記憶があります。
2. "iphone" というフォルダ名を [Resources|ui] ディレクトリ以下に作るとアプリが落ちる件
http://developer.appcelerator.com/question/136031/couldnt-find-module-error-on-device
android とか、 iphone という名前は root フォルダで予約されているようで、ビルドが壊れてしまいました。"Could'nt find module error on device" というエラーメッセージが出たときは要注意です。
自分はこの罠によって iPhone アプリのエミュレーターで何の前触れもなくアプリが落ちる事象に遭遇しました。3時間悩み、フォルダ名を変えて動いたときはなんのこったいと頭をかきむしった記憶があります。
3. アプリを起動したとき "application restart is required" と表示される
https://jira.appcelerator.org/browse/TIMOB-4941
これは Android 限定の現象ですが、Google Play から落としてきた配布済みのアプリを Google Play から、またはアプリのショートカットから起動すると "application restart is required" と表示されてしまうという事象がありました。
Titanium 2.0 SDK 以降でこの現象は fix されたとありますが、2.1.x でも再現しました。
<property name="ti.android.bug2373.disableDetection" type="bool">true</property>
4. UTF-8 以外のエンコーディング問題
御存知の通り Titanium Mobile では UTF-8 が使われています。ですがいろいろな理由で UTF-8 以外の文字コードを使わざるを得ない場合もあったりなかったり。。
必要な場合は Escape Codec Library を使うのがよいとは思いますが、ライセンスが不明確なので組み込みは微妙です。
http://www.vector.co.jp/soft/other/java/se342855.html
5. JSS (JavaScript StyleSheet) の扱い
もはや 3.0 以降では別の形でウィジェットの装飾方法が確立されているため、この記述は役に立たないでしょうが、一応記しておきます。
GUIの装飾をJavaScriptで行うjss (Javascript Style Sheet) はドキュメントは残っていないし、仕様と動作が[不明確|不便]なため、自分は結局いろいろ試した末使いませんでした。JSS の記述は以下にあったりしますが、2.x では使わない方がよいでしょう。
http://gihyo.jp/dev/serial/01/titanium/0015
JSSの代替となる流儀は、require してプラットフォームごとに設定を切り替える方法です。僕は以下にあった方法を使いました。
http://higelog.brassworks.jp/?p=1144
おわりに
Titanium 3.0 では Alloy という MVC フレームワークで大幅にアプリの開発が変わるでしょうが、個々のコンポーネントやアプリを公開する時にまつわるバグや罠はいろいろなところに潜んでいることでしょう。けどそれを乗り越えて皆でノウハウをシェアしつつアプリ開発を楽しめればよいなーと思います。再度書きますが、3.0 以降では変な罠を踏みたくないものですね!
次は @astronaughts さんですね! 宜しくお願いします!
Tags:
development,
tips,
titanium
登録:
投稿 (Atom)