なんとなく日記

Everyday studying...

Mitaka.rb night に行ってきた!

いやー,さすがおいしい食べ物の Mitaka.rb だけあって,おいしかったですね.雰囲気も良かったし.主催の @ysakaki さん,お疲れ様でした!ざっと感想など. ##基調講演 日本Hamlの会 会長の @ursm さんによる講演 Saas はかなり使えると思った. 今日から Haml の会の会員になりたいと思います. ##客員研究員 @bto さんの話 起業を支援してもらえるのはいいかなと思ったけど,私では技術力が足りなさそうです. ##あとで行くの人 @jishiha さんの話 Getting Realは絶対に読みます. ##ぺけBASICの人 @中谷さん [http://labs.cybozu.co.jp/blog/nakatani/:サイボウズ・ラボ COO です!] みんな処理系作ろうよ!と言う話でした. ##30min. の人 @野々村さん [http://30min.jp/] エンジニア募集中!

iPhone とか UI とか勉強会@万葉

##iPhone とか UI とか勉強会 by tsuyoshikawa iPhone UI 勉強会の開催のキッカケ @jugyo & @tsuyoshikawa の twitter の掛け合いから デザインイングインターフェイス パターンによる実践インタラクションデザイン ユーザの期待値が上がっているから,基本セットでそこそこのものでは,ユーザは満足しない イディオムの増加 Ajax などによる Web / Desktop の境界が無くなってきた 使いやすいアプリケーション 「直感的」だという場合,実は「慣用的」だと言わんとしている アフォーダンス 人間の脳は生得的に対象が何かを知るという本能的な情報はない 環境が有機体に意味を与える = afford 「使いやすいアプリケーション = 慣用的」になるようにデザインされる 人間にとっての「獣道」が作られていく パターン・ランゲージ パターン 様々な対象における「居住性」を向上させるような,構造・動作 つまり,イディオムに着目する デザインのボキャブラリーを増やすこと デザインのプロセス フィールドの調査 データベースとかフォームという意味ではない,フィールド シナリオモデルで,ユーザをシミュレートする 結局は人を知ることが重要 人 = ユーザ ユーザの事情を理解し,台本を作って,用語を整理する必要がある ユーザの分析 目的だけではなく,事情,状況,理由を考える必要がある 表層的な事情や目的にとらわれずに,ちゃんと考えなければならない ユーザの調査 実際に要件定義から始めるような状況では,なかなか実行しづらい場合もある ##ビアバッシュスタート

Ruby会議2009

##まとめと感想 初日で平日にも関わらず,結構な入り具合 Rails 3 は劇的ビフォア・アフター ただ構造はよくなる予感 大場さん@万葉社長のプレゼンの前半にのろけがあった模様? Github が小数で運用されているらしいのが,凄いことだと言うことと同時に,やればできるんだなぁと思いました. ##開会の言葉 高橋さんによる開会の言葉 4回目 3日間 3セッション同時並行 スポンサーのご紹介 中継をどこかでやるらしい 中会議場,特別会議室などには電源がある ##Using Git and GitHub to Develope One Millon Times Faster Scott Chacon from github.com http://git-scm.com/ の人 Pro git http://progit.org/ ###What is git Snapshot, not patch branche is pointer to a commit. merging -> create a new commit which parent is default and experimental 3 hot way(?

Ruby会議2009

##まとめと感想 朝早いからか,部屋が分かれるからか,ちょっと少なめな感じ 一橋記念会議場は都合により10分遅れ まさか来ていない? 無線LANの繋がりにくいので,iPhone がうらやましい感じ Reject会議は体調の都合により不参加.非常に残念.... RegionalRubyKaigi会議では,高橋会長とかくたにさんの,Ruby会議への熱い思いを感じました. 「Ruby はフェアで」と言うのが,ここんところ周りで起こってた言語論争の答えじゃないかと思った. Ruby を楽しんで,そして愛そう! 1.9 への移行を急いだ方がいいな,Rails アプリの. 今週中にるりまのMLに参加しよう. 手伝えそうなことは何でも手伝うべきだな.Ruby 好きだし. コミュニティーアピールは時間切れ.漫才師の道は険しい. ##Ruby 1.8 のゆくえ 卜部さん @ Trans New Technology 2010 には Yugui さんが Commit 数 1位の予定 ###past 1.X.0 trunk から start 安定したら branch を切る 1.8.1 から branch 化 1.8.6 Maintainer が Kirk Haines @ Engine Yard に 1.8.7 が incompatible だと思われた関係で,1.

Ruby会議2009

伝説に残るかもしれない Ruby会議 3日目 伝説になりました. RubyKaigi Staff のみなさん,KaigiFreeks のみなさん,ほんとにお疲れ様でした.そしてありがとうございました. 午後のかくたにさんの話は良すぎた.あれを感じ取れないやつはいないはずだ. 島本和彦的に言うと,「スパークした男の魂は,本物の男には伝わるはずだ」的な たしかに「みんながRubyに対して持つ様々な「思い」すべてに真摯に受けて立つkakutaniさんは、頼れるRuby兄貴」な感じ Termtter 会議は関西勢が過半数 jugyoさんも私も実は関西勢 基調講演は,決意を表明したかのような,遺言のような,でも何か言いたいことは伝わった感じ. 帰りに,RailsConf を日本でやりたいと急に思った. Rails会議なら名前的に問題ないだろうかとか,いろいろ考えてしまった. ##Project Report: Regional RubyKaigi 角谷さんの話 日本語でやります Ruby会議の運営委員長 Regional RubyKaigi Founder Major Evnets in U.S. RubyConf 2001- RejctConf 2006- Seattle.rb のドンが reject されたことにカッとなって始めたやつ Regional RubyConf 2006?- U.S. は人が多すぎるからいろいろできた 日本では? U.S.map(:&localize) RubyKaigi 2006- RejectKaigi 2007- Regional RubyKaigi 2008- U.S. でやったことを再実装 RubyKaig についておさらい 2006 - 251 2007 - 410 2008 - 564 2009 - 700?

お台場でガンダム見てきた

第一印象は,「でけー」 第二印象は,「これなら勝てる!」 と言うわけで,思わず何度もシャッターを切ってました. ##補足 上記のは qtpsftpi で HDR 補正したものです.お手軽でこんな感じにできて,ちょっと楽しい.

hbstudy#01 インフラエンジニア勉強会に行ってきた

株式会社ハートビーツ主催 色んな意味でアウェー感あり 何となく Mac/iPhone 率高い気がするなぁ ##インフラエンジニア勉強会 馬場さん ハートビーツのCTO インフラエンジニア サーバエンジニア + ネットワークエンジニア + アーキテクト 情報とか交流とか少ない 情報が少ない SD, WEB+DB PRESS, サーバ/インフラを支える技術 インフラエンジニア勉強会 月1 で 2時間程度 セミナーじゃなくて,討論するスタイル bpstudy をまるパクリなんだそうな 扱ってみたいテーマ テクノロジー,運用・マネージメント,事例・実例 企画運営 ハートビーツ + 有志の方々 ##Kerne-based VIrtual Machine (KVM) Accense Technology, Inc. Takano ENDOH http://twitter.com/MiCHiLU 資料 : http://tinyurl.com/WhatisKVM ###What’s KVM loadable kernel module based on QEMU 仮想化支援技術サポート 動作する OS が多い 完全仮想化? ###What’s QEMU

Compiz の Viewport と GNOME の workspace の混同を解決する

CompizConfig Setting Manager(CCSM)の一般オプション -> Desktop Size にあるデスクトップの数と水平仮想サイズ・垂直仮想サイズの意味を履き違えててしばらく悩んでました. まず前提として,Compiz の「Viewportのセット」は workspace につき1つ存在するので,「仮想デスクトップ1は8個欲しいから・・・・」と思って, |水平仮想サイズ|4| |垂直仮想サイズ|2| |デスクトップ数|8| なんてやると, |workspace1|Viewport1|Viewport2|Viewport3|Viewport4| | |Viewport5|Viewport6|Viewport7|Viewport8| |中略||| |workspace8|Viewport1|Viewport2|Viewport3|Viewport4| | |Viewport5|Viewport6|Viewport7|Viewport8| という具合に,全部で64個の viewport ができてしまいます. さらに都合が悪いのは,GNOME パネルのワークスペース切替器やウィンドウの一覧の表示がおかしくなってしまいます.GNOME 的には「workspace1に(viewport1~8の)全部のウィンドウがある」と思ってしまうようです.なので,ここは |水平仮想サイズ|4| |垂直仮想サイズ|2| |デスクトップ数|1| とすることで想定どおりの動作をするようになります.これに気づくまで時間がかなりとられました.... これも違う単語なのでさらに混同しやすい [return]

git svn での開発方法#2

前回の改訂版. ##remote branch の作成 Subversion リポジトリにブランチを作成する. % svn copy https://conceal-rs.repos/path/to/svn/trunk https://conceal-rs.repos/path/to/svn/branches/new-branch ##git repository から fetch % git svn fetch ##git branch の作成 Subversion のブランチは remote branch となるので,それを元に git branch を作成 % git branch --track git-branch-name new-branch % git checkout git-branch-name ##開発 普通に開発して git repos に commit ##svn ci Subversion ブランチへコミットします. % git svn dcommit ##マージ trunk やリリースブランチへマージする時は,git でマージして svn dcommit します. % git branch --track trunk-local trunk % git checkout trunk-local % git merge --squash git-branch-name % git commit -a -s -v % git svn dcommit git でマージするので git の利点も堪能できます.