トップ > 勉強会、カンファレンス > OSC2008Kansaiに行ってきた

OSC2008Kansaiに行ってきた

勉強会、カンファレンス

7/19、東京在住ながら、OSC2008Kansaiに行ってきました。
こういうカンファレンスなどに行くのは初めてです。
普段はBlogでしか見る事のできない人たちから直に話しを聞く事ができるのは大きいと思ってのことです。

以下、メモ

10:15〜のセッションはShibuya.jsの皆さん

ActionScript -> JavaScript

  • js, asを連携して使う。
  • javascriptでクロスドメイン越えができる。
  • ASだと、マルチメディア関連(音楽、動画など)が強い
  • JSで、userAgentを取得して、ASで、ブラウザごとに表示する
  • JSのAPI
  • ExternalInterface # addCallback
  • 問題としては、Flashが非同期処理のため、ロードし終わってないとエラーになってしまう。
  • 関数しか呼び出せない
  • 解決策：クロージャで文字列で処理する。
  • JSProxy
  • 続き、詳しくは、blogの20071213のを見る
  • Uffy
  • ASから、JSのAPI呼び出し
  • まとめ
  • ASとJSは相互に補間し合う関係

取説:正規表現

  • exec(str)
  • true or false
  • test(str)
  • null or array
  • グローバルマッチ
  • gフラグをたてる？？
  • lastIndexプロパティ



function MyObject(){

	 MyObject.prototype.re = /hoge/;

}

  • まとめ
  • まっちしたかどうか？ -> re.test
  • マッチの結果を利用したいときは -> re.exec

WSHでDOM

  • WSript.echo("Hello");
  • cmdで、
  • > cscript.exe /nologo helloworld.js
  • 外部jsをインクルード
  • eval(include(hoge.js));
  • window.とか、documentなどのオブジェクトがないため、エラー。
  • →無理矢理宣言してオブジェクトを作ってしまう。
  • jquery→css like に、DOMを操作できる。
  • 気づき事項：驚かせるには、視覚に訴えるのがよい??
  • dom4macui.js
  • WSHのMac版みたいのはあるのか？？→ちょっと調べてみる

IE8登場前に絶対に押さえておくべき~

id:amachangさん

  • Cross-site Server sent events
  • Selectors API
  • CSSセレクタで、DOMの操作ができる
  • 仕様はきまった？けど、実装はない。
  • Cross-document messaging
  • 2つのドキュメント間で、
  • 用途として，JSONPの代わりに使う？
  • Storageが共有出来る？

ライトニングトークセッション

id:takesakoさん

id:yossyさん

id:yunocchiさん

id:Yusuke Kawasakiさん

  • KAWA.netというサイトを運営

id:yukoba??さん

+名前なし
+AS1
+AS2
+AS3


id:motemenさん

id:kanasanさん

  • 機能よりも体感をもとめるのでは？ -> おもてなし
  • Greasemonkey
  • ブラウザは連続した半角英数を改行しない。

id:piroさん(の代理でid:nagayamaさん)

  • assert()関数 -> 調べる
  • 自動テストの効用 : 網羅性が高い
  • 短所 : GUIでは難しい
  • キー操作、画面の要素の変化を判定してテストを行う。

以上、Shibuya.jsの皆さんの発表だった。後半はいっぱいいっぱいでメモも少なめ...
普段の業務では、JSは入力チェックや、FORMをsubmitしたり、OnBlurを使ってAjaxもどき(画面遷移なしで値取得、といっても、隠しフレームに処理を投げていたりするので、めんどいことが多いですが。。。)とかにしか使われていないので、JSを使ってこんなにいろいろなことができるなんてスゴイ!!!そして、こんなことできないかな〜という疑問を持って、それを解決、実装できるだけのプログラミング力をもっているShibuya.jsの皆さんもスゴイ!!

プログラマーはプログラマーでも、こんなに違うものなのかとただただ、驚き、そしてへこみました^^;
でも、へこんでいるだけでは、いつまで経っても変わらない!!!ので、自分も、もっとプログラミングをしなければ!!!と思いました。

つづいては、お昼をはさんで、

jus研究会京都大会「PerlとWaftを使った軽量Webアプリケーション 作成の紹介」

玉城　勇二さん（NTTスマートコネクト株式会社）

　-データセンター事業
　-ASPサービスの開発、運用、ホスティング
　-CGIアプリ(フォーム)

  • 問題点として、部署ごとに様々な案件
  • アプリケーションが(案件に)合わせる?
  • アプリケーションに(業務を)合わせる?
  • perlを使えるにしても、標準モジュールは使えるけど、CPANモジュールは使えないとか、
  • バージョンが違うといった問題。
  • 制約がおおく、同じCGIでは運用できないことがある。
  • フレームワークを使って、開発効率アップをはかる。
  • はじめて作ったフレームワーク(SQ.pl)
  • 1.ページ管理
  • 2.データ保持
  • 3.テンプレート処理
  • SQ.plでは、デザインとロジックが分離されていなかった．
  • で、Waftの作成に至る
  • 特徴
  • クラスベース
  • 1テンプレート=1ファイル(=1メソッド)

そして、一番聞きたかった、はてなの伊藤さんの講演

はてなのバックエンドシステムと開発手法、過去と今

  • インフラ:ハード350台、14ラック
  • バックエンド
  • サーバ構成
  • 3層構造(reverse-proxyの導入)
  • DB
  • PostgreSQL -> MySQLへ2001年に変更
  • 理由 : 高速、Vacuumレス、使いやすい
  • 監視用にNagios->ケータイへメール
  • DBはテーブル単位で分割していた。->JOINを行っていないもの。レプリケーションがなかったため。
  • 自作ケース(フレームは、京都の製作所に図面を持って行ってつくってもらった。中身はPCパーツ)
  • レプリケーション、3層構造、など、構成を分離することで、機器を増設することで、スケールする構成を作れる。
  • mod_perlは落ちると接続できない
  • mod_proxyがフェイルオーバーの機能を持っていないため。
  • サービスが大きくなった場合の問題点
  • SPOF(single point of failure)
  • 冗長性
  • 回線(ベストエフォート100Mbps回線)
  • 電力不足など
  • サービスが大きくなった場合の解決策
  • DSAS-
  • Linuxでロードバランサ()
  • オープンソースでの可用性確保
  • 運用体制(組織化する)
  • LVS(IPVS) ->ソフトウェアでロードバランサが作れる
  • 運用の効率化ができる -> アプリケーション担当とサーバメンテナンス担当のエンジニアの作業の切り分けができる。
  • (サーバメンテナンス担当がシステムのコードを知らなくてもメンテ可能)
  • 商用サーバは、メモリが壊れたときにカーネルパニックを発生させてくれるため、故障に気づく事ができる。
  • ECCついてないと、故障を知る術がないため、悲惨なことに。。。
  • MySQLマスタのSPOF -> マルチマスタ化
  • 問題点として、マスタのスレーブを作るときに、binlogが追いつかない。
  • リソースを効率的に使うため、Xen(仮想化技術)を使う。
  • 働いていないサーバに複数OSを入れて動かす。
  • ネットワーク越しにOSをインストールできるように。(PXE Boot でインストール)
  • RPMリポジトリを使って，Perlモジュール、カスタマイズしたソフト、自社ライブラリを管理
  • 数百台規模になったとき、障害の起きたマシンの番号を感知するために自作ツール -> どのサーバを再起動するかすぐに分かるように
  • BackUp Tool
  • Notch

1日にものすごいPVのあるシステムというのは、システムが止まらないようにいろいろな対策が講じられていることが分かりました。
そして所々にOSSが使われていて、技術屋として作っていて楽しいんじゃないかなぁ、なんて思ったりもしました。

まとめ

はじめてのカンファレンスはとても刺激的なものであると同時に、自分の課題も浮き彫りとなりました。
技術力が圧倒的に足りないことです。
こんなことしたいなぁと思ったときに何とか実装できるくらいのプログラミング力を付けなければ!!!

最後に

自分の今の仕事である業務システムの保守は、保守ならではの今までの機能を壊さずに統一感を出したコーディングなど難しく、やりがいのある点もありますが、苦労して仕上げた機能をリリースした後のユーザさんからの反応を聞く事ができないため、自分の追加した機能が果たしてどの程度、役に立っているのか感じる事ができません。そこがツライところです。
反応を聞いて、使いやすくなったよ!!とか、こんなんじゃ業務は改善されないよ!!とか反応を知りたいです。
なので、今の自分は自社のサービスの開発をやっている人達がすごくうらやましいです。