はてなブックマーク - PHPmatsuriにいって来ました!(一人目?)
    このエントリーをはてなブックマークに追加

    多分久しぶりな登場の気がする萩原です。

    昨年に引き続きPHP Matsuriに参加させていただきました!
    (今回は福岡!)
    弊社からは何と8人も参加させて頂きました。
    全員LTで発表しましたので発表の最後の方にはまたFusicかとつぶやかれるくらいでした。

    一人目って書きましたが別に二人目とかタイトルが続くことは多分ないんじゃないかと思います。

    今回のPHP Matsuri

    今回は、本当にネタが思いつかずやることが決まったのは当日14時くらいでした。
    大して役に立たないものおもしろそうなものを作ろうということは何となく事前に決めていましたが。

    何とかネタは思いついたものの、時間内に出来るんだろうかとか思いながらバタバタ作っていたらなんだかんだで日付が変わったころには大体できてしまっていました。
    残り時間は書いたのもを見直したり、前でファミコンやってるのを眺めてたりホークスと横浜のトレードに衝撃を受けていたり(しかも今日公式に発表されたトレード、メンツが変わってたし)してました。

    今回やったこと

    今回はお絵かきのアプリを作りました。
    ただお絵かきするだけじゃつまらないので、
    お絵描きの履歴を取っておいて速度まで再現するものを
    CakePHPとJavasciptで作成しました。

    具体的に何をしたかというと
    ・canvasを利用して絵を描きつつ、mousemove中のマウスの座標や色、線の太さ、時刻を取得。
    ・絵を描き終わったタイミングでAjaxでデータを送信して保存。
    ・保存したデータを利用して、SetTimeoutを使ってcanvasで描写。

    なんてことをやってました。

    え?PHPがどこにあるのかって?
    saveとかfindとか使ったってば!
    PHPmatsuriの間一つもPHPに関してググらなかったけど!

    因みにmousemoveでとれる座標はすべて取得しているので1分くらい描き続けると保存のAjaxが30秒くらいかかります・・・。
    (まぁVM使って動かしてたんで実際にやればもっと速くなるとは思いますが・・・。)

    ちなみにちょっと公開する場所とかないのでお見せできないのが残念です。

    ついでに言うと発表はダダすべりしました・・・。

    感想

    ネタは2週間くらい前から考えてたんですが、思いついたのは当日。
    当日になって「エイヤ」でやっても意外となんとかなるものだなと思ってしまいました。

    発表は失敗しましたが(一説にはマイクが入ってなかったとかなんとか・・・)、
    作ったものを評価してくれたみたいで本とシャツをいただけました!
    ありがとうございます!

    前回は結構セッションをたくさん聞いたので、今回はコーディングをメインに参加しました。
    やっぱりあの雰囲気でコードを書くのはとても楽しかったです!

    何か次回は北海道とかいう宣言が何かなされていたので次回は北海道なのでしょう(笑)

    次回も楽しみにしておきます!
    後結局のところ私はFusicの変態枠なのでしょうか・・・

      はてなブックマーク - JaSST’12 Kyushuに行ってきました
      このエントリーをはてなブックマークに追加

      こんばんは。フクダリナです。

      今回は11月1日にかごしま県民交流センターで行われた「JaSST’12 Kyushu ソフトウェアテストシンポジウム 2012 九州」というものに参加させていただきました。

      ソフトウェアシンポジウムって何?


      くわしくはコチラで。
      毎年全国で行われているソフトウェアテストに関する講演、LT、セッションが行われています。

      JaSSTの存在を知ったのが、去年のJaSST九州が終わった直後で今回初めて参加しました。
      特に今年は二つの講演内容のキーワードが私にHitしました。

      基調講演「ARCを活用したビジネスにおけるテストの実践」について


      基調講演はソニックガーデン代表取締役社長 倉貫 義人さんによる、
      「ARCを活用したビジネスにおけるテストの実践」
      という講演を聞きました。

      講演内容は倉貫さんのブログを見られてください。

      ソニックガーデンさんの大きな特徴


      ・社員数7名ですべての仕事を行っている
      ・受注型ではなくサービス型
      ・スモールスタート&スケールアウト
      ・1つの仕事をプロダクトオーナー1名、メインプログラマ、サポート1名ずつで行う
      ・プログラマ全員がみんなのソースコードを触ろうと思えば触れる

      とってもスマートな経営、お客様と一緒に製品を育てていくサービスだなという印象を受けました。

      テストについて


      予稿集を見たときから思っていたのですが、テストに関する具体的なお話はほとんど出てきませんでした。Rubyを使っているので、RSpecでテスト自動化していますよ。というくらい。
      1部分についてはテストをアウトソーシングにだすこともあるそうです。
      しかし、基本的にはバグを出さないようにすることはありえないので、バグが出たときにすぐに直せるようにする ということにウェイトを置いていました。

      お客様は一定料金を払うのなら、ドキュメントが増えるとか必要以上のテストに時間を割くよりも、コーディングを進めて欲しい。という気持ちからの部分もあるかな?と思いました。

      講演に関する所感


      今のSIビジネスを全てこのサービス方法にすることは、現段階では完全には無理な仕事もあると思いますが、すごくシンプルで面白いと思います。

      この後の情報交換会で、倉貫さんとお話していただく機会があったので「何でRubyをはじめようと思ったんですか?」とうかがったら
      「当時、Javaをしている人が多く、そのときに出始めて面白そうなのがRubyだった」というような回答をいただきました。(ニュアンスが間違っていたらごめんなさい)

      この質問をJaSSTに行く前から、話せるチャンスがあれば聞こう!と決めていて、私の周りやFBで今やっているプログラム言語を自発的に始めた理由は何?と聞いていましたが「今から流行るな!」「かっこいい」というようなビビビ系なところが多かったように思います。
       もっともな回答「Javaにそのまま使えるから」「文法的にSVNに近くていい」というのもありましたが、意外な人から「他の言語に挫折したから」という回答ももらいました(笑)

      招待講演「世界最初の”モバイルエンジニア”がみた'00年代とこれから」について


      もう一つの講演は ACCESSで品質保証責任者をされている 松木 晋祐さんによる「世界最初の”モバイルエンジニア”がみた'00年代とこれから」についてのお話でした。

      松木さんは社外活動として、JaSST東京実行委員、JaSSTの母体であるASTERの会員、Androidテスト部、自動テスト研究会等をされています。

      講演でのポイント

      ・コンテキストに分けて議論する
      ・モバイルのコンテキストでは、今までとは違うコンテキストが存在する
      ・iOSとAndroidとでは、アプリにおける品質要素が異なる
      ・セキュリティとプライバシー保護はまったく別の概念。一緒に考えない。
      ・端末フラグメント問題へのアプローチとして各要素の重要性を検討し、重み付けする
      ・Androidにはテストツールが充実している

      モバイルの歴史から順を追って説明していただき、具体的なアプローチ例など なるほどというポイントがたくさんありました。

      セキュリティに関する話題


      この後に行われたミニパネルディスカッション(質疑応答に近かった)で取り上げられていました。
      ・受け入れテストにおいては、セキュリティに対しては暗黙の期待がある
      ・アプリでのセキュリティプライバシーは世界でも日本はすごく高い。
       他の国で制限がある場合は、その国別でセキュリティの設定をすることもある。
      (モバイルでシャッター音が出るのは日本と数カ国しかない、という話を思い出しました)
      ・セキュリティに対する勉強は、今抱えている問題・目的を細分化して調べていくほうがよいでしょう。

      iOSとAndroidについて


      ・どちらもセキュリティとプライバシーを何より最重要視しなければならない
      ・iOSでは飽和なアプリに埋もれないための魅力さが品質要素として高い
      ・Androidでは色んな端末に適応していることが重要視される
      ・AndroidはUI規約がなく、センサー類も多数あるために使用する自由度が高い
      ・Androidはテストツールも多く、ツールの特徴や適した例などはAndroidテスト部のサイトで確認できるそうです。

      言われてみれば確かに、なお話ですが、こうやって比べると、Android開発が楽しいという開発者の気持ちがわかるような気がします。
      (テストする側としては・・・ですが)

      おわりに

      他にも学生さんによるポスター発表やスポンサー企業によるLTがあったり、半日では物足りないくらい刺激になったシンポジウムだったと思います。
      個人的には もっと軽い(チャラいという表現がいいのかな?)LTがあっても楽しそうかな?ということと、ワークショップを是非して欲しいいな。と思いました。

      このあと情報交換会にも参加させていただきましたが、参加率80%だったそうです。講演者の方とお話する時間もあったり、大学の先生方や学生さんとも少しだけお話することができて とてもいい機会だったと思います。
      テストにたいしてすごく前向きに真剣に取り組んでいる方々と話すことができるのはすごくモチベーションがあがります。
       まだまだ勉強も必要だし、あらたに色々課題があることを実感したので、モチベーションが下がらないようにがんばりたいと思います。

      { 2012.9.25 }

      円マークについて

        はてなブックマーク - 円マークについて
        このエントリーをはてなブックマークに追加

        こんにちは。フクダです。

        ほんっと今更ですが。円マークについての問題です。

        今回の問題

        Windowsのブラウザで円マークが入れられなくね?

        というお話です。

        なんとなくスルーしていたのですが、気づけばIE8でもfirefoxでもChromeでもGoogleの検索フォームに円マークを入れようとすると、バックスラッシュになってしまっています。

        なんとなくの感覚ですが、バックスラッシュになるのって、Macの方じゃないの?て感じだったのですが
        手元にあるMac+Safariで試したところ、逆に円マークになってる?!

        \ ← これがWindowsで入力した円マーク
        ¥ ← これがMacで入力した円マーク

        ※Fusic Developers' Weblog では、入力はバックスラッシュで見えて、公開すると円マークでみえるらしいΣ(゚∀゚ノ)ノ

        調べたり、聞いているうちに二つの原因パターンがありました。

        その1:font-familyが違う


         サイトのfont-familyが円マークに対応していない場合です。
         この場合、WindowsとかMacとか関係なく バックスラッシュとして表示されます。

        その2:Macで半角円マークをキーを押したときの文字コードが違う


         実は使ってる文字コードが違うという事実!

        上に書いた円マークの文字コードを
        ココのサイトで調べてみました。
        結果が10進数なので、16進数になおすと

        \ (0x5C)← これがWindowsで入力した円マーク
        ¥ (0xA5)← これがMacで入力した円マーク

        になりました。
        そのため、Googleなどのサイトでは0x5Cをバックスラッシュ、0xA5を円マークとして表示しているのです

        Googleでみた円コード

        Googleでみた円コード

        ちなみに、通常エスケープ文字としては『0XC5』を使います。

        問題点


        これらをふまえて出てきた問題点は以下のような感じ。
        ■表示
        ・font-familyによって円マークがバックスラッシュとして表示されてしまう。
         金額表示なのにバックスラッシュとして表示されては意味がないです
         (まぁバックスラッシュとして表示されててもスルーしてしまってますが。。。)
        ■動作周り
        ・円マークとして登録したいのに、できない
        ・Macで円マークを登録したのに、Windowsで検索しようとすると文字コードが違うために検索に引っかからない
        ・サーバの処理によっては0xA5を全角円マークとして処理してしまったりする

        解決策


        表示については金額円マークには全角を使いましょう。ていうのが今のところの回避策のようです。
        なんてったって、Apple自体、金額表示は全角円マークつかってますからね

        処理については、フレームワークも実は考慮して作ってあったりするっぽいので、大問題にはならない気がします。
        処理を入れる必要があるのであれば、0xA5⇒0x5Cに変換して統一するかな?と思います。