社長BLOG
加藤登紀子さんインストアライブ新宿で開催【10月19日19:00~】
- 2009-10-15 (木)
- スタッフブログ
営業部の篠原です。
先月から、加藤登紀子さんのニューマキシシングル「1968」を購入した方のみが参加できるSNS「1968 by 加藤登紀子」の立ち上げ、運営に関わっています。
SNS立ち上げにあたっては、日本の音楽界の大御所である加藤登紀子さんと一緒にお仕事をさせていただき、とても貴重な経験になりました。
そんな加藤登紀子さんが、10月19日 19:00から新宿タワーレコードにてインストアライブ&サイン会を行います。
渋谷で行われた記者会見の際も登紀子さんの歌声を間近で聴かせていただきましたが、その迫力には圧倒されました。
19日のインストアライブも、登紀子さんの素敵な歌声を間近で聴くことができますので、お時間のある方は是非足を運んでみて下さい♪
シングルリリースと共に同時スタートした「1968SNS」の中でも、19日のインストアライブ終了後、SNS参加者の方や関係者の方が出席できる交流会が企画されているようです。
始まったばかりの1968×SNSですが、今後も登紀子さんのライブやイベントに連動する形で、SNSの中でもでたくさんのイベントが起こっていきそうです。
17日土曜日京都で公開セミナー開催(Rubyのまつもとゆきひろさんも参加)
- 2009-10-15 (木)
- 社長BLOG
17日土曜日、京都女子大学でセミナーを開催する。
参加は自由なので、ぜひご参加いただきたい。
公開セミナータイトル
現代社会学科公開講座 中の人に聞け~情報化社会を作り上げる人々~
セミナー内容
講題 情報化社会を作り上げる人々
講師 本学准教授 宮下 健輔 氏
講題 社会のためのソフトウエアOpenPNE:どう開発し何を目指すか
講師 手嶋屋代表取締役 手嶋 守 氏
講題 ライブ配信の仕組みと舞台裏
講師 奈良先端科学技術大学院大学助教 寺田 直美 氏
講題 Rubyはどのようにして生まれ、どう育てられてきたか
講師 (株)ネットワーク応用通信研究所フェロー まつもと ゆきひろ 氏
日時 10月17日(土)13:00~13:30・13:30~14:30・14:30~15:30・15:30~16:30
場所 J420教室
Rubyのまつもとゆきひろさんも講演される。
オープンソース業界の大先輩であるまつもとさんに会うのは初めて。
とても楽しみである。
2009年10月|京都女子大学・京都女子大学短期大学部
今日の情報化社会で日常的に利用されている情報技術(IT)は、初めからそこにあったわけではありません。あらゆるITには生み出した人がいて、維持管理をしている人がいて、改良され続けています。この公開講座の目的そのような「中の人」の講演を通じてITを見つめ直すことにあります。
.
「顧客コミュニティ」で商品作り
- 2009-10-14 (水)
- 社長BLOG
http://itpro.nikkeibp.co.jp/article/JIREI/20091005/338398/?ST=biz_trend
このニュース、顧客コミュニティを作って、商品開発に役立てようと言うもの。
顧客コミュニティの一番簡単な定義は
「相互にコミュニケーションする上客」
だ。
上客が相互にコミュニケーションを行うと何が起きるか?
このコミュニティがうまく運営できた場合、ぱっと思いつくだけでも
・上客同士のつどい、絆が深まりロイヤルティが高まる
・ユーザー同士の製品サポートが行われる
・新たに入った初心者ユーザーを成長させる
・商品サービスのフィードバックが得られる
・外部ソーシャルメディアへのプロモーションにおける、発信源になる
そのたもろもろ、と。
手嶋屋はOpenPNEを通じて、あらゆる顧客コミュニティの運営に貢献していく。
OSS を育てるために僕らができること
- 2009-10-10 (土)
- 開発者ブログ
開発部の海老原です。
先日、 htmlspecialchars() の文字エンコーディングのチェックが甘く、これを利用して XSS に利用される危険があるということで日本人の岩本さんがパッチを提供しましたが、却下されてしまっていました。
(ただ現時点で、 id:moriyoshi さんにより Subversion 上の PHP では対応済みです。ありがとうございます)
この件について各所で議論がされていました。
大まかな流れについては、徳丸浩さんがブログでまとめておられます。
このエントリ中で、「このあたりから、一連の流れが広く知られるようになって、『もっと効果的な訴求方法があるよ』とか、海老原昂輔さんからもバグレポートが投稿されるなどの働きかけが始まっているようです。海老原さんのレポートには私のエントリも英訳されていて、本当にありがとうございます。」という風に述べられているように、僕もバグレポートの reject に対して抗議をしたり、その抗議のよりどころとして徳丸浩さんのエントリと id:t_komura のエントリを英訳し、レポートとしてまとめたりしました(お二方にはこの場を借りて厚く御礼申し上げます)(僕のひどい英語についてはとりあえず目を瞑ってください……)。
ここまで読んで、こんな疑問を思った方はいらっしゃるでしょうか。「なぜ手嶋屋というアプリ屋の人間が / OpenPNE の開発者が PHP 内部のことに口を出すのだろう」と。
僕個人はあまり PHP に愛着を持っているわけではありませんし、文字エンコーディングについて精通しているわけでもありません。ただ、僕は、ひとりの OSS 開発者としてこの問題を見過ごせなかったのです。
ちょっと長くなってしまいましたが、このエントリでは、「なぜ海老原がそんなことを」ということから「OSS を育てるには?」というところをお話ししたいと思っています。
もちろん一口に OSS といっても様々ですので、すべてのプロジェクトに当てはまるとは思っていませんが、みなさんが「自分ももっと OSS に貢献してみよう」と思うきっかけになれば幸いです。
落下したリンゴは、定価で売れば良いのに
- 2009-10-09 (金)
- 社長BLOG
<イトーヨーカ堂>落下リンゴ半値 13日から3店舗(毎日新聞)
イトーヨーカー堂には落下リンゴを半値で売るんじゃなく、消費者を信じ、心意気で定価で売ってほしい。消費者に訴えかけ、挑戦してほしい。
消費者もそのメッセージを受け取り、傷ついたリンゴを定価で買ってやってほしい。
そのぐらいのことをやってのける優しさが、日本人にはあると思っている。
落下したリンゴ以外の被害以外にも、農家は被害を受けているとおもう。リンゴの木が倒れて次の年から取れなくなったり、設備が壊れたり。
そんなことを考えながら、ちょっと傷ついたリンゴを家族みんなで食べたらいい。
災害時だけでなく、豊作の時も問題だ。
野菜は保存がきかないので、値崩れの問題が顕著に出る。
できすぎた食べ物を採算性が悪いからと言って廃棄するのは、倫理に反するのではないか?
「今年はキャベツたくさん取れたから、キャベツ料理をいつもよりも余計に作ろう」
生産と消費との距離があまりにもシステマチックに、遠くなりすぎてしまったので、こんなあたりまえのことが、あたりまえにできなくなっている。
OpenPNEで生産者と消費者との絆を取り戻せないか?
そんなことを考えたニュースであった。
【つぶやき】「件名」はいらない?「本文」のみのコミュニケーション。
- 2009-10-08 (木)
- 社長BLOG
twitterは件名が無い。ついでに署名もないし、本文も140文字までの制限がある。
「いつもお世話になります ●●です」15文字
「よろしくお願いいたします」12文字
140文字なのでこんな無駄な挨拶を書いている暇は無い。
要件だけを短く伝えなくてはならない。
ちなみに自分は辞書に登録してあるので
「いつー」で変換すると「いつもお世話になります」
「よろー」で変換すると「よろしくお願いします」
「てじまー」で変換すると「手嶋屋手嶋です。」
と、楽をしている。
ところで。
OpenPNE3の機能はVer2時代のものを取りそろえていく方針でいる。日記にしても、メッセージにしても件名+本文スタイルのものが多いので、本文のみで使えるプラグインも提供したい。
(pne.jpから)
コミットメッセージに Issue ID を含むことを強制させる Git のフックスクリプトを書きました
- 2009-10-06 (火)
- 開発者ブログ
開発部の海老原です。
OpenPNE プロジェクトで必要になったので、コミットメッセージに Issue ID を含むことを強制させる Git のフックスクリプトを書いてみました。
gist にコードをあげたので、是非ご自分の clone の .git/hooks/commit-msg 向けに変更して使ってみてください。
(僕はあまりシェルスクリプトを書き慣れてはいないので、指摘などもお待ちしています)
これを使うことで、たとえばコミットメッセージを含まないメッセージを記述した場合、エラーとなってコミットできないようになります。
また、 curl が実行可能な場合、 http://redmine.openpne.jp/ から Issue のタイトルを取得して表示させます。もし間違えた Issue を指定した場合でも、 git commit –amend ですぐにコミットを訂正することができます。
OpenPNE プロジェクトや手嶋屋での開発のように、チケットや Issue に強く依った開発をしている場合、コミット毎に Issue ID を強制することはかなり有効に働くはずです。是非活用してみてください。





