Hatena::Grouphatena

はてな技術発表会日記 このページをアンテナに追加 RSSフィード

株式会社はてなでは日々、開発者が持ち回りでひとつの技術トピックについて発表を行っており、公開可能なものについては、その内容を音声と動画で公開しています。

|

2006-05-08

5月2日の技術勉強会

16:35 | 5月2日の技術勉強会 - はてな技術発表会日記 を含むブックマーク はてなブックマーク - 5月2日の技術勉強会 - はてな技術発表会日記

5月2日に行われました技術発表会の内容を撮影した動画ファイルを公開いたしました。内容は以下のとおりです。

テーマこれだけは知っておけ! vim 勉強
発表d:id:secondlife
時間24:51

動画ファイル

以下の再生画面より、勉強会の動画をご覧いただけます。

filelist

目的

ぐらいは何とか知ってる人が conf ファイル編集をもっと楽に!

サーバに入ってる .vimrc を書いてない vim 対象。

はまりどころ

FedoraCore での vi は alias vi='vim' なため、root編集しようとすると /bin/vi が使われて悲しい。範囲選択などが使えません。なので vim コマンド編集しましょう。

V

範囲選択モード

コピペ

範囲選択して y

貼り付けたいところで P

切り取り・貼り付け

範囲選択して d

貼り付けたいところで P

範囲置換

範囲選択して :s/foo/bar/g

整形

範囲選択して > もしくは <

syntax で対応していれば範囲選択して =

Ctrl + v

矩形範囲選択モード

コメント

行頭を範囲選択して I#<ESC>

# を // に変えれば…

コメント削除

コメント部分を矩形範囲選択して d

これだけ知ってるだけで、だいぶコンフィグ編集が楽に!

次点

列の結合

範囲選択で J

範囲選択で gJ (スペース含まず)

行末に文字列

範囲選択して :s/$/<br>/

物理的行移動

gj, gk

syntax

:sy on

:syntax on

:sy off

:syntax off

行番号

:set nu

:set number

:set nonu

:set nonumber

次の一手

:h

help 最高

:h j

:h Ctrl-v

:h syntax

:h :syntax

hi_deckyhi_decky2006/05/10 22:31はてなの勉強会は「いぇーい」で始まり「いぇーい」で終わる。
あの何とも言えない脱力具合が好きです。
次回も期待しています。

トラックバック - http://hatena.g.hatena.ne.jp/hatenatech/20060508

2006-02-20

2月20日の技術勉強会

10:19 | 2月20日の技術勉強会 - はてな技術発表会日記 を含むブックマーク はてなブックマーク - 2月20日の技術勉強会 - はてな技術発表会日記

2月20日に行われました技術発表会の内容を撮影した動画ファイルを公開いたしました。内容は以下のとおりです。

テーマRuby on Rails
発表d:id:secondlife
時間46:38
ファイルサイズ270,470,182Bytes

以下よりダウンロードしてご覧ください。

http://www.hatena.ne.jp/sound/tech/060220hatenatech.wmv (※現在はご覧いただけません。)

Rails って?

37SignalsのDHHが作ったRubyMVCフレームワーク

Rails の構成ライブラリ

ActionPack

enviroment で環境の切り分け
  • test
  • development
  • production
DB接続周り

ActiveRecordオブジェクト接続したり

requireするライブラリ自動ロード
  • productionならロードしたら終わり、productionなら毎回ロードしたいのはrequire_dependency
  • サーバ自動再起動が必要ない
Filter
  • before
  • after

簡単にフィルタをかけれる。またFilterオブジェクトを渡すことも可能

plugin

プラグイン拡張が楽

Layout

外枠templateの共有が楽

Routes
params

CGIのqueryみたいなもの

request

リクエストオブジェクト

@request.env['HTTP_USER_AGENT']
@request.post?
response

レスポンスオブジェクト

@response.body = 'foobar'
@response.header['content-type'] = 'text/html'
header['content-type'] # text/html
render

templateにレンダリングさせる処理。通常透過的に呼ばれる。

render :text => 'texttest', :layout => 'false'
render :template => '/foo/bar/baz'
render :nothing => 'true'

ActionPack

controllerとviewの結びつけ

いちばんべんり

controllerのインスタンス変数view(デフォルトerb)に渡す。じわじわととても便利。

# controller 
def index
  @foo = 'foostr'
end

#view
<%= @foo %>
template周り

デフォルトhelperいろいろ

その他もろもろ

自作helper

使い周しできそうな処理の外部分離

# helper
module HatenaHelper
  def usericon(name)
    usericon_prefix(name) + ".gif"
  end

  def usericon_small(name)
    usericon_prefix(name) + "_s.gif"
  end

  def usericon_prefix(name)
    "http://www.hatena.ne.jp/users/#{name[0, 2]}/#{name}/profile"
  end

# view
<%= usericon('secondlife') %>

ActiveRecord

ActiveRecordパターンのO/Rマッパ。拡張しまくってるので一般的に云われるActiveRecordパターンなのはコアの部分だけ。

DBIxっぽい?

シンプル
User.find 1234
User.find_by_name 'secondlife'
User.find_by_sql('select * from users where name = ?', ['secondlife'])
User.find(:all,:condition => ['name like "?", 'second*'], :limit => 50)

Usef.find([1..50]).each do |user|
  user.money += 100
  user.money_add_flag = true
  user.save
end
validate
class User < ActiveRecord::Base
  validates_length_of :first_name, :maximum => 10
  validates_inclusion_of :age, :in=>0..99
user = User.new :name => 'aaaaaaaaaaaaaaaaaaaaaaaa'
user.valid?
user.save
observer
  • (-) save
  • (-) valid?
  • (1) before_validation
  • (2) before_validation_on_create
  • (-) validate
  • (-) validate_on_create
  • (4) after_validation
  • (5) after_validation_on_create
  • (6) before_save
  • (7) before_create
  • (-) create
  • (8) after_create
  • (9) after_save
class User < ActiveRecord::Base
~snip
def before_save
  self.passwd = Digest::SHA1.hexdigest(self.passwd)
end

def after_save
  logger.info "#{self.id} complete"

もちろんObserverオブジェクトの登録も

ActionWebService

WebServiceを簡単に作れるよ。

ActionMailer

メールを簡単に送れるよ。日本語問題(UTF-8で送る)がデフォルトだと発生するよ。

Railsの強み

  • Berryz工房
    • Atok2006で「べりーずこうぼう」で変換できた!

Railsの弱み

  • 運用実績
    • 遅い?安定しない?
  • fcgiまわりよくわかんない
    • はまったとき・・・
    • メモリ管理周り
  • lighttpd
    • こまい設定手探り

shingoyshingoy2006/02/22 12:30ATOK 2005でもBerryz工房でべりーずこうぼう変換できました。報告まで

test_31331test_313312006/02/28 18:05enviromentであってないです(汗
正しくはenvironmentですよ。nがつくんです。

2006-02-07

2月6日の技術勉強会

13:39 | 2月6日の技術勉強会 - はてな技術発表会日記 を含むブックマーク はてなブックマーク - 2月6日の技術勉強会 - はてな技術発表会日記

2月6日に行われました技術発表会の内容を撮影した動画ファイルを公開いたしました。内容は以下のとおりです。

テーマREST
発表d:id:naoya
時間22:08
ファイルサイズ128,445,362Bytes

以下よりダウンロードしてご覧ください。

http://www.hatena.ne.jp/sound/tech/060206hatenatech.wmv

RESTとは何か

以下、基本的には資料そのものです。この勉強会の後、それぞれ ppt 見てもらったほうがいいかも。

以下、yohei さんの資料を参考に。

REST は○○ではない

はじめにこれを知っておくと理解が早そう。間違った先入観をとっぱらおう。ppt から抜粋します。

で、REST とは何か

まだよくわからない?? REST とは何か

まず、具体例

要は、ウェブアーキテクチャリソースの状態を転送するためのアーキテクチャスタイル

ういういいことがあるのか

yohei さん曰く、

おそらく一番最後の疎結合が重要

AtomPPREST

  • POST で新規作成
  • PUT で編集
  • DELTE で削除
  • GET で取得

詳しくは http://d.hatena.ne.jp/naoya/20051125/1132891578 の資料あたり。

REST を知ったことで導かれる具体的な話。

  • どういうときに POST、どういうときに GET を使うべきか意識して設計しよう。
  • どういう URI 設計が正しいか意識しよう。
  • 疎結合を意識してアプリケーションを設計しよう。

URI重要

ということでこれ(CoolURI の設計) も読むこと。

2005-11-28

11月28日の技術勉強会

19:09 | 11月28日の技術勉強会 - はてな技術発表会日記 を含むブックマーク はてなブックマーク - 11月28日の技術勉強会 - はてな技術発表会日記

11月28日に行われました技術発表会の内容を撮影した動画ファイルを公開いたしました。内容は以下のとおりです。

テーマSubversion
発表d:id:higepon
時間11:15
ファイルサイズ65,297,444Bytes

以下よりダウンロードしてご覧ください。

http://www.hatena.ne.jp/sound/tech/051128hatenatech.wmv

Subversionとは何か?

Subversion は、フリーオープンソースバージョン管理システムで、時間とともに変化するファイルディレクトリを管理します。

CVSの代替ツールとして、地位を確立しつつあります。

誰が開発しているの?開発の背景は?

バージョン管理のソフトを提供しているCollabNetという会社が開発。

Open Source Development with CVS (Coriolis, 1999)の著者である Karl Fogel とか、 Jim Blandyとか。

CVSには不満がたくさん!。ばっさりと不具合と言い切っていたりする(仕様不具合

不幸にも CVSオープンソースの世界において 事実上の標準となっていましたが、それは単に、少なくともフリーライセンスの下ではそれより良いものが何もなかったというのが理由の大部分でした

なぜいまSubversionか?

  • 人柱時代の終焉。1.0.0は2004/9 (現在は Subversion 1.2.3)
  • Ruby?
  • miyagawaさんも絶賛!

CVSとの違い、導入のメリットは?

1.ディレクトリ単位バージョン管理

CVSファイル単位バージョン管理なのに対して、Subversionは、ディレクトリ(ツリー)単位でも履歴が追えます。

ツリーで管理されるプロジェクトと相性がよい。


2.ファイルコピー・名称変更・移動

CVSの不満点の大部分を占める、この問題を解決してくれます。

CVSファイル移動

cvs remove して、 cvs add 履歴はリセットされる

Subversionならコマンドがあるよ。


3.アトミックなコミット

CVSでは、ファイル単位コミットでしたが、Subversionでは変更点すべてをひとかたまりとしてコミットします。

何らかのエラーで途中までコミットとかはない。


4.ネットワーク層

Subversionリポジトリアクセス用の抽象レイアがあり、新しいネットワークプログラムを簡単に実装できるようになっています。

→たくさん対応ツールができてくるかもね

5.他

データ処理の一貫性バイナリテキストが同じ方法で圧縮格納

効率的なブランチタグの作成→作成が速い


CVSからの移行は大丈夫?

いけてる機能

微妙な動作の違い

svn propset svn:ignore *.BAK .\src

svn copy # ブランチ作成
svn merge -r 303:302 http://svn.example.com/repos/calc/trunk

まとめ

良いところばかりだから早く移行しましょう。

desutaidesutai2005/12/01 21:46svn -N add ディレクトリ名 でディレクトリだけaddされるよ

j1r0j1r02006/02/04 09:52こちらのコーナーはもう更新されないのでしょうか。
毎回非常に楽しみにしていたので残念です。

naoyanaoya2006/02/06 22:20プロジェクタが壊れて更新が停止していました。今日から再開しましたので、まもなく更新する予定です。

2005-11-25

11月25日の技術勉強会

12:19 | 11月25日の技術勉強会 - はてな技術発表会日記 を含むブックマーク はてなブックマーク - 11月25日の技術勉強会 - はてな技術発表会日記

11月25日に行われました技術発表会の内容を撮影した動画ファイルを公開いたしました。内容は以下のとおりです。

テーマPerl::Critic
発表d:id:onishi
時間15:17
ファイルサイズ88,770,896Bytes

以下よりダウンロードしてご覧ください。

http://www.hatena.ne.jp/sound/tech/051125hatenatech.wmv

Perl::Critic::Policy::TestingAndDebugging::RequirePackageStricture

Using strictures is probably the single most effective way to improve the quality of your code. This policy requires that the 'use strict' statement must come before any other staments except package, require, and other use statements. Thus, all the code in the entire package will be affected.

use strict を使用するのは、あなたのコードの品質を改良する最も効果的な方法だよ。

use strict はpackage以外のrequire,useなどのあらゆるステートメントの前に書こう。そうすればpackage内の全てのコードに有効になるよ。

Perl::Critic::Policy::TestingAndDebugging::RequirePackageWarnings

Using warnings is probably the single most effective way to improve the quality of your code. This policy requires that the 'use warnings' statement must come before any other staments except package, require, and other use statements. Thus, all the code in the entire package will be affected.

use warnings も同様だよ。

Perl::Critic::Policy::ValuesAndExpressions::ProhibitConstantPragma

Named constants are a good thing. But don't use the constant pragma because barewords don't interpolate. Instead use the Readonly module.

定数に名前をつけるのはいいけど、constantプラグマは使わないこと。なぜならbarewordは展開しないから。

代わりにReadonlyモジュールを使おう。

  use constant FOOBAR => 42;  #not ok

  use Readonly;
  Readonly  my $FOOBAR => 42;  #ok 
大西注

use constantでbarewordを定数にした場合、文脈によりどっちだかわかんなくて困ることがあるから、Readonlyモジュールを使おう、ということらしい。

use constant HOGE => 'hoge';
$fuga{HOGE} = 'fuga';

みたいに書いた場合、HOGEがconstantで指定した定数なのか、hashキーなのかわかんない、みたいな。

Perl::Critic::Policy::ValuesAndExpressions::ProhibitEmptyQuotes

Don't use quotes for an empty string or any string that is pure whitespace. Instead, use q{} to improve legibility. Better still, created named values like this. Use the x operator to repeat characters.

空文字列のクォートは使わないで、代わりにq{}を使おう。名前をつけるとなおよし。繰り返すときはx 演算子を使おう。

  $message = '';      #not ok
  $message = "";      #not ok
  $message = "     "; #not ok

  $message = q{};     #better
  $message = q{     } #better

  $EMPTY = q{};
  $message = $EMPTY;      #best

  $SPACE = q{ };
  $message = $SPACE x 5;  #best

Perl::Critic::Policy::ValuesAndExpressions::ProhibitInterpolationOfLiterals

Don't use double-quotes or qq// if your string doesn't require interpolation. This saves the interpreter a bit of work and it lets the reader know that you really did intend the string to be literal.

展開する必要がないところでダブルクォートやqq//を使わないように。

これはインタプリタ仕事を少し節約できるし、コードを読む人が文字列がそのままの文字通りであると意図していることができるよ。

  print "foobar";     #not ok
  print 'foobar';     #ok
  print qq/foobar/;   #not ok
  print q/foobar/;    #ok

  print "$foobar";    #ok
  print "foobar\n";   #ok
  print qq/$foobar/;  #ok
  print qq/foobar\n/; #ok

  print qq{$foobar};  #preferred
  print qq{foobar\n}; #preferred

Perl::Critic::Policy::ValuesAndExpressions::ProhibitLeadingZeros

Perl interprets numbers with leading zeros as octal. If that's what you really want, its better to use oct and make it obvious.

0先行の禁止。Perlは0が先行する数字を8進数としてみなすよ。本当に8進数を使いたい場合はoctを使ってそれをわかりやすくしよう。

  $var = 041;     #not ok, actually 33
  $var = oct(41); #ok

Perl::Critic::Policy::ValuesAndExpressions::ProhibitNoisyQuotes

Don't use quotes for one or two-character strings of non-alphanumeric characters (i.e. noise). These tend to be hard to read. For legibility, use q{} or a named value. However, braces, parens, and brackets tend do to look better in quotes, so those are allowed.

1~2文字の非英数字(これすなわち雑音)にクォートを使用しないように。だって読みにくいんだもん。q{}を使うか名前をつけて変数にしちゃおう。

でも、brace {},paren (),bracket []はクォートの中の方が読みやすいから特別に許しちゃおう。

  $str = join ',', @list;     #not ok
  $str = join ",", @list;     #not ok
  $str = join q{,}, @list;    #better

  $COMMA = q{,};
  $str = join $COMMA, @list;  #best

  $lbrace = '(';          #ok
  $rbrace = ')';          #ok
  print '(', @list, ')';  #ok

Perl::Critic::Policy::ValuesAndExpressions::RequireInterpolationOfMetachars

This policy warns you if you use single-quotes or q// with a string that has unescaped metacharacters that may need interpoation. Its hard to know for sure if a string really should be interpolated without looking into the symbol table. This policy just makes an educated guess by looking for metachars and sigils which usually indicate that the string should be interpolated.

このポリシーは展開しそうなエスケープされていないメタキャラシングルクォートやq//の中にあった際に警告するよ。

シンボルテーブルを調べないで文字列が展開されるべきかどうか知る事は難しいよね。このポリシーは文字列が展開されるべきであることを示すメタキャラやsigilsを探す事でそれを推測するよ。

Perl::Critic::Policy::ValuesAndExpressions::RequireNumberSeparators

Long numbers are be hard to read. To improve legibility, Perl allows numbers to be split into groups of digits separated by underscores. This policy requires numbers sequences of more than three digits to be separated.

長い数字は読みにくいよね。可読性のため、Perlはアンスコで数字をわけるのを許しているよ。このポリシーは3桁以上の数字がアンスコでわけられているのを要求するよ。

 $long_int = 123456789;   #not ok
 $long_int = 123_456_789; #ok

 $long_float = 12345678.001;   #not ok
 $long_float = 12_345_678.001; #ok

Perl::Critic::Policy::ValuesAndExpressions::RequireQuotedHeredocTerminator

Putting single or double-quotes around your HEREDOC terminator make it obvious to the reader whether the content is going to be interpolated or not.

ヒアドキュメントのターミネータシングルクォートかダブルクォートで囲もう。

中身が展開されるかどうかに関係なく、コードを読む人にわかりやすいもんね。

  print <<END_MESSAGE;    #not ok
  Hello World
  END_MESSAGE

  print <<'END_MESSAGE';  #ok
  Hello World
  END_MESSAGE

  print <<"END_MESSAGE";  #ok
  $greeting
  END_MESSAGE

Perl::Critic::Policy::ValuesAndExpressions::RequireUpperCaseHeredocTerminator

For legibility, HEREDOC terminators should be all UPPER CASE letters, without any whitespace. Conway also recommends using a standard prefix like "END_" but this policy doesn't enforce that.

読みなすさのため、ヒアドキュメントのターミネータは空白のない大文字であるべきだよ。コンウェイは "END_"のような標準の接頭語を勧めているけど、このポリシーではそれは強制しないよ。

  print <<'the End';  #not ok
  Hello World
  the End

  print <<'THE_END';  #ok
  Hello World
  THE_END

Perl::Critic::Policy::Variables::ProhibitLocalVars

Since Perl 5, there are very few reasons to declare local variables. The only reasonable exceptions are Perl's magical global variables. If you do need to modify one of those global variables, you should localize it first. You should also use the English module to give those variables more meaningful names.

Perl5以来、local変数を宣言する理由はほとんどないよ。唯一の例外はPerlのmagicalなグローバル変数だけだよ。

これらのグローバル変数を使いたいときは、最初にlocal宣言してね。あと、Englishモジュールを使って、より意味のある名前にした方がいいよ。

  local $foo;   #not ok
  my $foo;      #ok

  use English qw(-no_match_vars);
  local $INPUT_RECORD_SEPARATOR    #ok
  local $RS                        #ok
  local $/;                        #not ok

Perl::Critic::Policy::Variables::ProhibitPackageVars

Conway suggests avoiding package variables completely, because they expose your internals to other packages. Never use a package variable when a lexical variable will suffice. If your package needs to keep some dynamic state, consider using an object or closures to keep the state private.

This policy assumes that you're using strict vars so that naked variable declarations are not package variables by default. Thus, it complains you declare a variable with our or use vars, or if you make reference to variable with a fully-qualified package name.

コンウェイパッケージ変数は徹底的に避けるべきだと提案してるよ。なぜなら内部変数が他のpackageに露出しちゃうから。

レキシカル変数で十分な場合、パッケージ変数は使わないようにしよう。packageが動的な内容を保持したい場合、オブジェクトかクロージャを使ってパッケージプライベートに保つことを考えてね。

  $Some::Package::foo = 1;    #not ok
  our $foo            = 1;    #not ok
  use vars '$foo';            #not ok
  $foo = 1;                   #not allowed by 'strict'
  local $foo = 1;             #bad taste, but ok.
  my $foo = 1;                #ok

In practice though, its not really practical prohibit all package variables. Common variables like $VERSION and @EXPORT need to be global, as do any variables that you want to Export. To work around this, the Policy overlooks any variables that are in ALL_CAPS. This forces you to put all your expored variables in ALL_CAPS too, which seems to be the usual practice anyway.

とはいえ、これは実際には現実的ではない。$VERSIONや@EXPORTはグローバルである必要があるから。

ということでこのポリシーは全て大文字変数については見逃す事にしています。

Perl::Critic::Policy::Variables::ProhibitPunctuationVars

Perl's vocabulary of punctuation variables such as $!, $., and $^ are perhaps the leading cause of its repuation as inscrutable line noise. The simple alternative is to use the English module to give them clear names.

Perlの$!や、$.や、$^などの変数ボキャブラリーは恐らく計り知れないノイズの原因だよね。

シンプルな代替手段として、Englishモジュールをつかってそれらに明確な名前を与えよう。

  $| = undef;                      #not ok

  use English qw(-no_match_vars);
  local $OUTPUT_AUTOFLUSH = undef;        #ok
Englishモジュールについて
大西注

perlvarによると

Due to an unfortunate accident of Perl’s implementation, "use English" imposes a considerable performance penalty on all regu-lar expression matches in a program, regardless of whether they occur in the scope of "use English".

Perl の実装における不幸な事故により、 use English はプログラム中の全ての正規表現マッチングにおいてかなりの性能低下を引き起こします。これは use English のスコープ内かどうかに関わりません。この理由により、ライブラリで use English を使うのはできるだけ避けてください。

って書いてあるYO!

|