職業プログラマの休日出勤

職業プログラマによる日曜自宅プログラミングや思考実験の成果たち。リアル休日出勤が発生すると更新が滞りがちになる。記事の内容は個人の意見であり、所属している(いた)組織の意見ではない。

英語から開発しよう、そのアプリ。

私は、WebアプリでもiOSアプリでもその他のものでも、何かしらUI(User Interface)を伴うアプリケーションを開発するときはまず英語バージョンを先に作るようにしています。


これは昨年1月に関モバに参加したときの発言です。

この記事では、次のようなことを述べています。

  • 英語版から開発すると、どんな幸せなことが起きるのか?
  • どんな状況のときは、英語版を作らない方が良いのか?
  • 和文英訳力を鍛える方法

また、この記事のタイトルは美しい川柳になっています。575です。

続きを読む

ITストラテジスト試験 #jitec #jitecst 受験記 ver2017

ITストラテジスト試験を受験してきました。
この記事は、その記録です。

続きを読む

RFC(Relocation for Creativity) 1918 : Address Allocation for Private Life

Address Allocation for Private Life
プライベートな生活におけるアドレス割り当て

Status of this Memo このメモの状態

この文書は、インターネット生活者のための、現時点で最も効率の高い生活手法について述べたものであり、改善のための議論や提案を受け付けている。再配布には制限があり、引用には一般的な引用の要件を満足する必要がある。

1. Introduction 前書き

この文書は、プライベートな生活におけるアドレス割り当てについて述べている。アドレスを適切に割り当てることにより、人間関係ネットワークにおける必要な全てのノードとの通信が正常に行われるようになり、人生が上手く行く。

続きを読む

RDSを定期的にstart/stop

今年の6月から、RDSのインスタンスを stop/start できるようになりました。
Amazon RDS Supports Stopping and Starting of Database Instances
当然ながら、ここで想定されるユースケースの中で最もそれっぽいものは、開発環境やテスト環境の夜間停止・週末停止です。
この機能が出るまでは、RDSの機能を停止(言い換えればRDS本体の課金を停止)させるには、データが削除されることが前提でした。(snapshotは取れますが)

さて、夜間停止や週末停止を実現したり、1週間stopのまま放置(放置すると自動で起動する仕様)した後の自動stopを実現するためには、自動化したいところです。
既に実現している人もきっと多いことでしょう。
この記事は、その自動化を実施するにあたってのメモです。

続きを読む

CakePHPの nested transaction まわりの挙動を見てみる

CakePHPでちょっとハマったのでメモ。

三行まとめ

続きを読む

テーブル名と照合順序

古めのPHPから SQL Server のデータベースに接続するアプリケーションをメンテナンスすることになり、環境構築している途中でハマったのでメモ。

三行まとめ

  • DBの照合順序がLatin系だと、テーブル名が日本語になっているテーブルはPHPから見えなくなる。
  • でも、SSMSからはテーブル作れるし、見える。
  • なんで?
続きを読む

commandキー押しっぱなし

続きを読む

パラレルキャリア生活へ(a.k.a. 退職エントリ)

2013年10月から勤めていた会社を2017年7月で退職しました。無職なのは一瞬だけで、8月からは仕事をします。えらい!(褒めて!!)

続きを読む

iptablesの設定内容を見る

新しくサーバをセットアップするにあたって、sshdのポート番号をデフォルトの22から他のものに変えようとしたところ、外部から接続できない、という症状に見舞われました。
症状から考えれば何らかのファイアウォール装置によって弾かれていることは明らかだったのですが、iptablesの設定内容の確認方法を間違えていたため、無駄な時間を費やしてしまいました。
この記事は、そのときのメモです。

続きを読む

葛藤:自分にしかできないこと

何か新しいものを作るとき、自分にしかできないことを実行して上手く進んで行くという状況は最高に楽しく、有意義に感じる。自分にしかできないことが存在するとき、需要と供給のバランスが崩れ、売り手市場を闊歩する状態になる。
「自分にしかできないこと」の存在は正義である。

既存のものを守り育てて行くとき、自分にしかできないことが存在すると、自分が死んだらコイツも死ぬということが容易に想像できるようになり、その状況は大きなストレスになる。対象物が重要なものであればあるほど、ストレスは積み重なる。
「自分にしかできないこと」の存在は悪である。

自分自身が情報処理界隈に身を置いているからソフトウェアの開発や情報システムの保守運用を思い浮かべながら書いたが、きっと他の業界でも同じようなことは観測できるだろう。

続きを読む

「ユニコード戦記」を読んだ

仕事もプライベートもUnicode無しには考えられないという時代になって久しいですが、皆様いかがお過ごしでしょうか。
私は元気ですが、文字のことが頭から離れる日はありません。

さて、3月に東京に遊びに行ったとき、渋谷のとある書店に立ち寄ったのですが、その時に偶然「ユニコード戦記」を見かけたので、衝動買いしました。

ユニコード戦記 ─文字符号の国際標準化バトル

ユニコード戦記 ─文字符号の国際標準化バトル

「これって確か数年前に流行ってた本だよなー」という認識でした。周囲の何人かの技術者に聞いても同じようなコメントが帰ってきたので、きっとそうなのでしょう。2011年の発行です。

内容は、Unicodeの規格の制定に関わる物語です。
規格を感覚的にでもある程度知っていると「あー、この部分、そういう歴史的経緯だったのか!!!!」という発見の連続で、本当にためになります。異体字とか、特にそうですね。国際会議でどのように信頼を勝ち取っていき、意見を通していくのかということについても、ためになります。
もちろん、規格をあまり知らなくても、単純に物語として楽しめると思います。
ミスると一つもしくは複数の言語文化を殺してしまうことにつながる、というプレッシャーは凄いものがあったことでしょう。


最近では、MySQLの「寿司ビール問題」「🍣=🍺問題」を通して、collation(照合順序)の実装はどうあるべきなのか?という議論が様々な場所で繰り広げられています。その議論に参加している皆さんが抱える苦悩は、まさにUnicodeの規格制定に携わってきた皆さんが体験してこられたことと根本的には同じことでしょう。(もちろん、実装面はいろいろと異なるため、その苦労はもう一度誰かが体験することになるのでしょうけれども。)


この本、現在ではあまり数は出回っていないようではありますが、皆さんもぜひ読んでみてはいかがでしょうか。


3月に買った本を今になって「読んだ」と申している点については、どうかご容赦を。

2月の米子の旅日記 〜 中国地方DB勉強会への参加など

先月の話ですが、鳥取県は米子に行ってきました。
中国地方DB勉強会 #19 を動機とした旅行計画でしたが、かなり満喫することができました。

(続きを読む 際は写真が多くなることに注意)

続きを読む

「暗号解読」を読んだ

昨年、オススメの本を紹介しあう会(ビブリオバトル)が会社で開催されたのだが、その会に同僚氏が持ち込んだ「暗号解読」という本がとても興味深かったので、買って読んだ。

暗号解読〈上〉 (新潮文庫)

暗号解読〈上〉 (新潮文庫)

暗号解読 下巻 (新潮文庫 シ 37-3)

暗号解読 下巻 (新潮文庫 シ 37-3)

手元の本は平成25年に15刷と書いてあるので、かなりのロングセラーなのだろう。恥ずかしながら自分は同僚氏に紹介されるまで知らなかった。

暗号解読。
身近なところでは、シェル芸人の皆さんによる暗号解読騒ぎなどが記憶に新しい。
【こわい】唐突に暗号解読を始めるシェル芸人達 - Togetterまとめ

日頃、SSL/TLS を喋るサーバを構築したり管理したり、アプリケーションが取り扱うデータの安全性をどのように確保するのか?といったことに頭を使ったりなど、暗号のことを考えない日は無いと言っていいほどだ。
簡単な暗号なら有限量の努力で解読できる。そういう自信もあった。
しかし、実際に自分の手を動かして、あるいは自分で解読用のプログラムを書いて暗号解読を試みたことはあるかと言われると、ほとんど無い。

この「暗号解読」は少々古い(2000年前後に書かれた本だ)が、古典的な暗号や第二次世界大戦、そしてRSAや量子暗号に至るまで、時代をたどりながら取り上げて行く。簡単なものについては解読するための手法も実践的なものが紹介されている。
また、ただ単に技術的な解説にとどまらず、その暗号の発明や解読に至る人間の動きも紹介されていて没入感が高い。
読むにあたって、全部理解しようとするとなかなか難しいものはあるかもしれないが、話を追う分には、前提知識は特に要らないだろう。きっと。
皆さんも読んでみては。

追記@2017/03/19 01:10頃

そういえば、ちょっと前に「セキュリティフォント」という いかがわしい 製品が話題になっていた。
security.srad.jp
この「セキュリティフォント」の仕組みは、単純な換字式暗号。「暗号解読」の上巻の、かなり最初の方で解読法が解説されてしまう代物だ。
「セキュリティフォント」には情報を守る効果がほとんど無い(ただしゼロではない)ということはすぐにわかることではあるが、この本を読んでいれば、単純な換字がどれだけ危険であるか身を以て知ることができるだろう。

忙しさから遠ざかれ

数ヶ月前、近所のスーパーが閉店した。
閉店の2ヶ月前くらいから、忙しくてそのスーパーには買い物に行けてなかった。忙しさから解放されて「さぁ買い物に行こう」と思ってスーパーに行ってみたら真っ暗、だった。
「あぁ、俺が買い物をしなかったせいで経営不振に…」という気持ちはあって、すごい無力感に襲われた。(実際には、住民の一人が買い物できなかった程度ではスーパーは潰れないだろう。)

話は変わっておおよそ10年前のこと。外的要因によって精神を病んでしまった友人が居て、MSN MessengerMicrosoftさんが運営していたチャット)で話を聞いたりアドバイスしたりしてたんだけども、自分の仕事が忙しくなってなかなか返事を返せなくなって、しばらくしたら死亡していた、ということがあった。自分が返事を返すことができていたら助かっていたかもしれないという思いはあって、やはり無念だった。

人の死とスーパーの閉店とを同列に並べるのは変な話ではあるが、「自分の忙しさのせいで助かったはずのものが助からなかった」という思いを抱いたという点ではこの2つの出来事は全く同じだ。



…という話や思考があったことを、ここ最近の忙しさを振り返っていて思い出した。
断言しよう。忙しくしていることは「悪」である。自分の生活の中から、重要度の低いものはどんどん削ぎ落としていくべきだ。


自分自身の忙しさを測る(≒数値化する)手法は、睡眠時間の統計を取るというのが最も一般的だろうけれども、もしかしたら、自分で気付かないうちに家事を放棄して睡眠時間を確保しているかもしれない。
そうなったときでも、自分の忙しさを測るにはどのようにしていれば良いのだろうか?
例えば「近所のスーパーの特売情報を10秒以内に思い起こすことができなかったらアウト」といった基準は持っていても良いのかもしれない。

今日の教訓

近所のスーパーの閉店に気付かないのは相当ヤバイ。

第27回 #シェル芸 勉強会 参加記録

2週間も前の話ですが、シェル芸勉強会の大阪サテライトに参加してきました。
この記事は、その思い出話です。

リンク集
続きを読む