カテゴリー: WEB

CSS Nite in KYOTO, Vol.3「Web制作業界最前線」に参加してきました!(その1)

11月14日(金)に開催された、CSS Nite in KYOTO, Vol.3「Web制作業界最前線」に参加してきたのでご紹介します。

CSS Nite in KYOTO, Vol.3「Web制作作業最前線」

タイムテーブル

セッション1:
ディレクションが苦手な人のための、「Webディレクション」の処方箋(Webデザイナーだったら編)
高田 信宏さん(クリエイター育成協会)

セッション2:
コンテンツマーケティングは恋のライセンス
成田 幸久さん(インフォバーン

セッション3:
Webプログラミングの今とこれから 〜最新Web技術の紹介とそこから考えるWebクリエイターの可能性〜
村岡 正和さん(バスタイムフィッシュ)

セッション4:
Evernoteでも採用されたMaterial Designの概要と導入方法
阿部 正幸さん(KDDIウェブコミュニケーションズ)

セッション5:
UIデザイナーとは何者なのか?
土屋 尚史さん(グッドパッチ)

Session1:
ディレクションが苦手な人のための、「Webディレクション」の処方箋(Webデザイナーだったら編)

講師:高田 信宏さん(クリエイター育成協会

まさかの信号の故障により、電車が大幅に遅れて途中からの参加。
そのため全部聞くことが出来なかったのですが、サンプルのヒアリングシートを紹介して、その重要性を説明されてました。
詳細は、Webディレクション教科書(通称「黒本」)で確認してね!とのことwww

実際の業務に一番近い内容だったのですが、残念。。。
また機会があれば参加します!

Session2:
コンテンツマーケティングは恋のライセンス

講師:成田 幸久さん(インフォバーン

とてもいい響きのナイスなセッションタイトル。

京都にも支社を置かれてから、業務でもお世話になっているインフォバーンさんですが、企業紹介の中で、「GIZMODO(ギズモード・ジャパン)」や、「lifehacker(ライフハッカー)」、「roomie(ルーミー)」といった、メディアも運用されているとのことを(今更?)知りました。
すみません。いつもお世話になっているのに、全く知りませんでしたw

(正確には、グループ会社「メディアシーン」が運営)

コンテンツマーケティング=恋愛戦略

コンテンツマーケティングとは、「顧客にとって価値のあるコンテンツを提供していくこ­とで、興味を惹き、共感をしてもらい、結果として売上げにつなげる」というマーケティング戦­略とのこと。
この戦略を、恋愛に例えて分かりやすく紹介してくださいました。

5つのメリット

1.あなたに恋を持った人だけが訪れる
2.アプローチしたい人だけに絞れる
3.あなたの優位性をアピールできる
4.あなたの評判が拡散する
5.あなたをどう思っているのか分かる

戦争の時代から、恋愛の時代へ

これまでのコンテンツは、ターゲットに向けてどのように情報を発信していくか、コンテンツを届けるかというSEOをベースとした一方通行の奪い合い(戦争)のようなものだったが、もうそんな時代が終焉を迎えようとしている。
これからは、ターゲットに届けることはもちろんだが、双方向に「愛」が芽生えない限りそのコンテンツに成功は望めない。
そう、これからは「恋愛」の時代なんだ。

--まとめると、こんな感じの設定でした。うん、分かりやすい。

地道な努力と、「愛」が求められる

とはいっても、恋愛はそうはかんたんに成就するものではありませんよね。
「恋愛は一日にして成らず」
愛を持った、地道な努力が必要なのだそうです。

「恋というのは一つの芝居なんだから、筋を考えなきゃだめだよ」by 谷崎潤一郎

そこで、次のような「成功に導く7つのステップ」を紹介してくださいました。

1.目標設定(KPIとKGI)

・KPI(重要業績評価指標)を明確化し、各プロセスごとのKGI(重要目標達成指標)を設定することで、顧客とのつながりを長期的に維持

2.状況分析とトピックの設定

・情報なくして戦略なし
SWOT分析(強み、弱み、機会、脅威)

3.ペルソナ設定と購買ファネル

・ターゲットは1人!
30%ではなく、「30倍」!インフォバーン総研)

4.コンテンツの編集計画

・コンテンツカレンダーを作成し、PDCAをスケジュール化して管理

5.心を動かすコンテンツの制作

アリストテレスの「ストーリー三幕」(状況設定 > 葛藤 > 解決)インフォバーン総研)
・「変化」、「対比」が重要!
インパクトを与え、自分ゴト化させる!

6.コミュニケーションの管理
7.達成度の測定(SMART goal)

・Specific(具体的に)
・Measurable(測定可能な)
・Achievable(達成可能な)
・Related(経営目標に関連した)
・Time-bound(時間制約がある)

日々やっていることだったり、なんとなく分かっていることなんですが、「恋愛」という状況に照らしあわせて考えていくことが出来るため、ペルソナを設定することと同じように、チーム内でその重要性を共有しやすくなりそうだと感じました。
楽しく、とてもためになるお話をありがとうございました!


(長くなってしまったので、セッション3移行は次回に紹介しようと思いまーす。興味ある方はお楽しみに!)

WebSocketでルータ越しの通信を行う

概要

弊社ではコミュニケーションツールとして、
チャットサービスの「Slack」を使用しています。

https://slack.com/

Slackでは、
チャット内で動作するBotを簡単に作成できるような仕組みが用意されています。

とても簡単なので、色々とBotを作成していますが、
今回はその中でも「Kanasanコマンド」を作成した時に行ったテクニックをご紹介します。

Kanasan-API

社内には、Mac miniにつながっている大きなスピーカーがあります。


参考:http://seeds-std-pr.blogspot.jp/2014/09/kana-san.html

このMac miniで再生すると、
スピーカーから音が出て社内全体に響き渡るようになっています。

普段は、朝礼の時間にラジオ体操を流したり、
がんばるタイムの始めと終わりに学校のチャイムを鳴らしたりしています。

また、SayKana (http://www.a-quest.com/quickware/saykana/)というソフトを使用して、
任意の日本語文字列を喋らせたりもしてます。
単純なものですが、このシステムを「Kanasan」と名づけました。

先日、このツールと連携するKanasan-APIというWebAPIも作りました。
https://github.com/memememomo/p5-KanaSan-API

このKanasan-APIをSlackと連携させたいなと考えました。

Kanasanコマンド

Slackは、(噂では)バックエンドがIRCということもあり、
メッセージの最初にスラッシュ(/)をつけると、コマンドとして認識されます。

Slackには、新しくコマンドを作成できる仕組みも用意されています。

ということで、「/kanasan ほげほげ」とSlack上で入力したら、
社内のスピーカーに「ほげほげ」と喋らせることができるKanasanコマンドを作成しようと考えました。

メッセージ反応系botの仕組みと問題点

任意のURLを設定すると、Slack上でメッセージが投稿されたタイミングで、
設定したURLにリクエストを飛ばすことができます。

メッセージ反応系botでは、
このリクエストを処理して反応を返します。

Kanasanコマンドもこの仕組を利用します。
しかし、今回のKanasan-APIはオフィスのルータ下にあるため、
Slackに直接叩いてもらうことができません。

Websocketでルータ越しの通信

上記の問題点を解消するため、
まずはSlackに叩いてもらうエンドポイントをHeroku上に置くことにしました。
そして、Heroku上のエンドポイントとオフィス内のサーバをWebsocketでつなぎ、
なるべくリアルタイムに反応できるようにしました。

Heroku上のエンドポイントのソースは以下のようになります。

heroku.coffee
HTTP_PORT = process.env.PORT || 8000
app = require("express")()
socketio = require 'socket.io'
server = require('http').Server(app)
io = socketio.listen(server)
# 社内サーバにデータを送るWebSocket
s = undefined
io.sockets.on 'connection', (socket) ->
  s = socket
  console.log 'connected'
# Slackからのリクエストを処理
app.get "/api", (req, res) ->
  t = req.param 'text'
param =
    text:t
if s != undefined
    s.emit 'news', param
    res.send 'ok'
  else
    res.send 'ng'
server.listen(process.env.PORT)
console.log HTTP_PORT

express と Socket.io を使用しています。
expressでSlackからのリクエストを受け付ける処理を記述し、
Socket.ioで社内サーバにWebsocket経由でデータを送る処理を記述しています。
expressとSocket.ioを連携させる機能があったので比較的簡単に書けました。

社内のサーバのソースは以下のようになります。

local.coffee
WEBSOCKET_URL = 'http://hogehoge.herokuapp.com/'
API_URL = 'http://local-kanasan.net/api'
request = require('request')
io = require('socket.io-client')(WEBSOCKET_URL)
# Heroku上のサーバにWebSocketで接続する
socket = io.connect WEBSOCKET_URL
# Herokuからのデータを受信するWebSocket
socket.on 'news', (data) ->
try
# Kanasan-APIを叩く
options =
      uri: API_URL,
      form: {text: data.text}
request.post options, (error, response, body) ->
console.log body
catch e
console.log 'error'

Socket.io と request を使用しています。
Socket.ioでHeroku上からのデータを受け付る処理を記述し、
requestでKanasanAPIを叩く処理を記述しています。

以上で、Kanasanコマンドを動作させることができました。

まとめ

WebSocketでルータ越しの通信を実現しました。
Node.jsを使用すると、今回のように双方向通信処理をカジュアルに書けていいですね。
ブラウザとの双方向通信以外の用途で色々使えそうな可能性が見えてきました。

phpPgAdminにログインできない時

サーバーインフラエンジニアの葉です。
今日は、phpPgAdminについて少しお話します。

phpPgAdminとは何か?

phpPgAdminは、ウェブブラウザから PostgreSQL データベースを管理・操作する為のツールで、テーブルの作成や参照、
データのバックアップやリストア等の操作を行うことができる、とても便利なウェブブラウザです。

管理画面

インストールが完了すると、管理画面が下の画面ようになります。

早速ログインしましょう!

あれ?ログインできなかった・・・>_<

解決方法

こんなとき、conf/config.inc.phpで修正しなければいけない箇所が2つがあります。

ポイント1

[code]
$conf[‘servers’][0][‘slony_support’] = true; → falseを変更
[/code]

ポイント2

[code]
$conf[‘servers’][0][‘sslmode’] = ‘disable’;
[/code]
コメントアウトします。

以上、2点を修正してみました。
それでは気を取り直して、もう一度ログインしてみましょう!

できました\^0^/


ばっちりログインしました。

ぜひ、参考にしてみてください。

よくできるIT技術者がもつ3つの特性とは?

最近になって、本格的にこのブログから弊社をアピールしていこうとしているみたいだ。

 

しかし、技術者でありながら、Web上どこにでもあるような記事しか書けない。というのが私の現状。

そして、無限に広がるWebスペースを同じような記事で汚すようなことはしたくないし、

他のメンバーがそれらしい事を書いてくれるだろうから私はもういいだろうと思う。

とはいえど、ノルマ?いや、愛着?がある弊社のため記事を考えてみる。

管理者が激怒しそうな内容。。

 

今回は「仕事ができるIT技術者」についてを考える。

 

冒頭の経緯から「弊社のメンバーは技術力すごいんです」という結論に持って行くんだろ?

など思われた方もいらっしゃると思うが、そのような内容は下記には無い。

10年近く、いろいろな技術者、システム屋と接する機会があり、

私なりに分析したことが書かれている。

 

私の考えるところ「仕事ができるIT技術者」が持っている特性は、

 

1)真摯である

2)向上心がある

3)素直

 

の3点。うーん普通だ、プログラマーとかSEってデータベースが詳しい?とか・・

もっと「技術力」にフォーカスされるのではないのか!?

 

これはなぜかと言うと「技術力」というのは移り変わりが激しい。すぐ陳腐化する。

飛び抜けて技術力が高い方も世の中には存在はするが、感覚的に1000人に1人ぐらいだろう。

この資料では2011年の時点で、日本には102万人技術者が存在するようなので、約1000人。

 

一般的に「個人の技術力」の差は、「どんぐりのせくらべ」と表現すると想像がつくと思う。

 

「技術力」があるというのは、システム屋であれば、普通でありアピールポイントでも何でもない。

結局、上記のような人間のコアな要素が問われるのだと思う。

私のように、技術力も人間性も無いようなのは先も長くないだろうし最悪だ。

 

システムはグループで開発するので、これを組織のレベルに引き上げて考えてみると、

組織だと技術力は補完しあえるので、結局、A社、B社、C社・・・似たり寄ったりの構図になる。

そう考えると「技術力」が仮に同じ前提として・・、いや少し劣っていたとしても、

上記の特性をもつメンバーが多く集まる企業がシステムを開発した方が

失敗も少なく良い結果がでていると思う。

 

システム開発をお考えの際は、そのような基準でご判断されれば良いと思う。

 

弊社がそのような会社なのかは、私の方からアピールする必要はない。

お電話をいただいて担当者とお話をされれば、おそらく直ぐに判定できるだろう。

→でも、もしご興味がございましたら弊社実績もご参照ください・・。

 

参考にならないとは思いますが、書きました。

isucon3 予選で敗退しました(うさぎ工房)

isuconは初回からずっと出ているのでこれで3回目。

いつもは同僚の@shokiri @memememomo (Uchiko) 、僕、の3人で出場するのですが
お互いの予定の折り合いがつかず、僕は出場できない可能性が出てきました。
でも僕はどうしても出場したい・・・!

そこで、いつもの社内メンバーは「進撃の超大型パティスリー兄弟」
僕は一人ソロ活動で社外の友人(@gom_oh)や元社員(ttoz)を誘って「うさぎ工房」として予選登録しました。

僕自身がOps側である所や、メンバーのプログラマPerlPSGI/Plackは初めて触る二人だったので
集まって過去ISUCONで自家製ISUCONしたり、クエリ最適化について勉強したりといった準備をしました。

結果はスコア的には5300でfinish。見事敗退となりました。

ちなみに弊社の本チームである「進撃の超大型パティスリー兄弟」チーム側は
なんと総合4位で予選通過!さすがです!
若干悔しさもあるけど、弊社から本戦にいく人がいて、本当に嬉しかったです。おめでとうございます!
そちら側の詳細はきっと彼らが記事にしてくれるはず。本戦でもばっちり頑張ってください!

こちらの記事は点数の低い僕らがやった事なので、
アンチパターンとして楽しんでいただければ。

最終構成

最終的には varnish perl mysql とちょっとだけmemcached の構成でした。

phpMyAdminを立ち上げる

まず、MySQL関連の操作でphpMyAdminしか使えない僕はphp5.5をソースコンパイル
ビルドインサーバーとして立ち上げました。これ便利ですね

/usr/local/lib/php -S 0.0.0.0:3000

my.cnfを設定

APIキー登録して初回ベンチが確認する。たしか800くらいでした。
初回ベンチですぐにDBボトルネックとわかったので、my.cnfを以下に変更。
(ええ、もちろん find / -name my.cnf しました。)

key_buffer = 512M
max_allowed_packet = 10M
table_open_cache = 10240
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 1M
thread_cache_size = 128
query_cache_type= ON
query_cache_size= 16M
thread_concurrency = 8
innodb_flush_log_at_trx_commit = 0
innodb_file_per_table
innodb_additional_mem_pool_size=40M
innodb_log_buffer_size=32M
innodb_log_file_size=256M
innodb_buffer_pool_size=8000M
max_connections = 2048
max_connect_errors = 10000
tmp_table_size=1342177280
max_heap_table_size = 1342177280

インデックスを張りました

最終的にはcreated_atとか使ってなかったので無駄だった。

ALTER TABLE `memos` ADD INDEX ( `created_at` ) ;
ALTER TABLE `memos` ADD INDEX ( `user` ) ;

ここらへんで1500くらいだったかな。

フロントエンドはVarnish

フロントエンドはVarnishを使用。
編集や削除はされないようだったので、なんとかリクエストヘッダの値から「ログインしているか否か」を判別して全体キャッシュできないか考えてましたが、リクエストヘッダで判断できる材料がなく、また、Plackとか全然わからないのでヘッダーの修正とかはできませんでした。

結局フロントエンド側での大規模なキャッシュは僕の力では厳しそうだったので
静的ファイルだけvarnishでキャッシュ。設定の主要部分だけだけど以下のような感じ。

backend web1 {
.host = "127.0.0.1";
.port = "5000";
}
sub vcl_recv {
set req.backend = web1;
if (req.url ~ "\.(jpg|png|gif|css|js|ico)$") {
return (lookup);
}
return (pass);
}
sub vcl_fetch {
set beresp.ttl = 86000s;
return (deliver);
}

スキーマとかSQLの改修

ここらへんで2500くらいだったかな。
この時でもDBボトルネックはまだまだ明らかでしたので
ここでメンバーの@gom_ohがDBに以下の改修を行いました。

内容は公開IDの一覧だけのテーブルを作ってtopページやrecentページのDB負荷を削減する、といった感じの修正となります。

CREATE TABLE `public_id` (
`memo_id` int(11) NOT NULL,
PRIMARY KEY (`memo_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;'

public_idというmemosテーブルでパブリックに公開しているだけのmemo_id一覧を入れるテーブルを作成しました。
それから、ベンチ実行後のスクリプトで現在公開中である記事のIDをインサート

INSERT INTO public_id (memo_id) SELECT id FROM memos WHERE is_private = 0 ORDER BY id DESC;

上記は初期スクリプトで実行。

#公開ページの総数
SELECT count(*) FROM memos WHERE is_private=0SELECT count(memo_id) FROM public_id
#TOPページ
SELECT * FROM memos WHERE is_private=0 ORDER BY created_at DESC, id DESC LIMIT 100SELECT m.id, u.username, m.created_at, m.content
FROM memos m
JOIN (
SELECT p.memo_id
FROM public_id p
ORDER BY p.memo_id DESC
LIMIT 100
) t
ON m.id = t.memo_id
JOIN users u
ON u.id = m.user;
#recentページ
SELECT * FROM memos WHERE is_private=0 ORDER BY created_at DESC, id DESC LIMIT 100 OFFSET %d", $page * 100

SELECT m.id, u.username, m.created_at, m.content
        FROM memos m
        JOIN (
          SELECT p.memo_id
          FROM public_id p
          ORDER BY p.memo_id DESC
          LIMIT 100 OFFSET %d
        ) t
        ON m.id = t.memo_id
        JOIN users u
        ON u.id = m.user',
        $page * 100);

これでスコアが5000くらいになりました。

Markdownの結果をmemcacheでキャッシュ

その他はMarkdownの処理が重かったので、ここだけmemcacheでキャッシュとか、ちまちまして5300くらいに。
まんまとポート11211につないでましたが。

あとどこかのタイミングでStarmanからStarletに変更しましたがスコア的に動きはなし。
最終的にはまだまだDBがボトルネックなまま5300でフィニッシュとなりました。

感想

初日に「1位の人とか人間なの?」と思ってたのですが、
2日目の弊社メンバーが1位に輝いてて、出先からの発表見てのけぞった。
どんな事をしたのか聞くのが楽しみです。

競技中も楽しかったのですが、普段なかなか会えない友達や元同僚と集まって
お菓子ほおばりながら共通の目的をもって取り組んだ時間が勉強になったし楽しかった。
特に普段は他の二人にまかせていた所を本腰を入れて取り組まないといけない状態だったので、
今まで以上にソースを見たりDB構造を見たり、という部分に入っていけたのがよかったです。

反省点としては、

[READMEをしっかり読んで意識を共有しておけばよかった]
workloadがAMI提出時のコマンド入力で気づきました。「ただボトルネック調査の為に負荷を大きくできる」くらいの認識しか持ってなくて(んなわけないのに)、、、試せる事はちゃんと試すべきでした。結果、一度もWorkloadを変更してなかった!!

[とりあえずperlだろみたいな雰囲気になってた。]
やりたい事をちゃんとやれる言語でやる道も検討したらよかったと。PHPで着実なボトルネック修正で予選抜けたところもあってそう思いました。「こうしたら早くなりそう!」→「Perl、、というかPlackって奴でどうやんの。」→「わからん」、のコンボが多かった。

ISUCONは参加者は楽しいけど、運営の方々は本当に大変そうで少し申し訳ない気持ちに。
運営の皆様本当にありがとうございました。

そして「進撃の超大型パティスリー兄弟」、本戦がんばれー!

おまけ

終了後に本番ベンチが解放されていたのでWorkload 5くらいでまわした結果

Result:   SUCCESS
RawScore: 8285.3
Fails:    0
Score:    8285.3
[OK] 結果を管理サーバに送信しました

ちょっとあがった。

Perlに関する情報の調べ方・集め方

Perlに関する情報の調べ方や集め方、有益なサイトや書籍などをまとめてみました。

Perl入門に関する情報

サンプルコードによるPerl入門(サイト)

http://d.hatena.ne.jp/perlcodesample/

サンプルコードがたくさんあってとても分かりやすいサイトです。
現代的なPerlの書き方が学べます。

以下の目次ページを上から順番に読めば、すぐにPerlの全体像はつかめると思います。
http://d.hatena.ne.jp/perlcodesample/20091221/1260183022

Perl入学式(勉強会)

http://www.perl-entrance.org/

Perlの基本を学び、Webアプリケーションを作るまでを目標にした勉強会です。
自分で手を動かしながらの勉強会なので身につきやすいです。
2013年は大阪と東京でそれぞれ全6回を予定しているそうです。

Webサービスのつくり方 ~「新しい」を生み出すための33のエッセイ(書籍)

http://yusukebe.com/archives/20121113/091343.html

「ボケて」をPerlで開発した@yusukebeさんの本です。
アイディアを形にする方法が学べます。
Perl中心の本ではないですが、Perlで何ができるかを知ることができます。

Perlの最新情報

Perlの最新情報を得る方法には、次のような方法があります。

Perlをよく使っている人のTwitterやブログを購読する

Perlをよく使っている人たちが発信する情報はとても有益です。
Twitterやブログを購読して読んでいれば、自然とPerlの動向などが分かるようになります。
Perlをよく使っている人たちはPerl関連のイベントで発表していることが多いので、
イベントページなどから見つけましょう。

例えばYAPC::Asiaのページから見つけることができます。
http://yapcasia.org/2012/talk

以下の様なまとめもあります。
■今すぐフォローすべきPerl界のスーパーエンジニア
http://d.hatena.ne.jp/sugyan/20110616/1308203734

Perl関連のイベントに参加する

イベントに参加すると自分が知らないことをたくさん知ることができます。
インターネットや書籍だけだと、自分の興味や問題の範囲のみに無意識的に偏ってしまいます。
イベントだと自分が調べないような分野の話も聞くようになるので、とても勉強になります。

いくつかイベント情報を上げておきます。

YAPC::Asia
http://yapcasia.org/
年に一回日本で開催されるPerlのイベントです。
豪華ゲストが来ます。

■PMグループ
http://www.pm.org/groups/japan.html
地域ごとに集まって定期的(不定期?)に勉強会や情報交換会などを行います。

Perl Begginers
http://www.perl-beginners.org/
参加したことないので雰囲気は知らないですが、質疑応答が多めに取られている勉強会でしょうか。

Perlの書籍

読みやすい本をご紹介します。

Perl CPANモジュールガイド

http://www.amazon.co.jp/dp/486267108X

よく使われていて便利なモジュールが紹介されている本です。
Cpanサイトで検索しても何を使ったらいいのか分からない場合、
この本を参考にすると良いでしょう。

もっと自在にサーバを使い倒す 業務に役立つPerl

http://www.amazon.co.jp/dp/4774150258

Perlの現代的な書き方、ログデータの加工、Webフレームワークの使い方など、
実践的なPerlの使い方を学ぶことができます。

Webサービスのつくり方 ~「新しい」を生み出すための33のエッセイ

http://www.amazon.co.jp/dp/4774154075

PerlでWebAPIを利用したりフレームワークを使ってサービスを作ったりする雰囲気が学べます。

Perlスティング ハンドブック

http://www.amazon.co.jp/dp/B00A5Q6EM2

Perlでテストを書くときのノウハウを知ることができます。
どんなテストモジュールを使ったら良いのか、どのようにテストを書いたら良いのかを学ぶことができます。

Plack Handbook

http://www.amazon.co.jp/dp/B009Z30LRA

PlackベースのWebフレームワークを扱う場合に知っておいたほうが良い内容です。

ググりにくいこと

正規表現について

■実践で役立つPerl正規表現 完全解説
http://d.hatena.ne.jp/perlcodesample/20100827/1278596435

正規表現の解説。

Perl正規表現チュートリアル
http://perldoc.jp/docs/perl/5.16.1/perlretut.pod

長めのチュートリアル

Perl正規表現のリファレンス
http://perldoc.jp/docs/perl/5.16.1/perlreref.pod

記号の意味を知りたいとき。

特殊変数について

$|とか$!とかの意味を知りたい場合。

Perl で定義済みの変数
http://perldoc.jp/docs/perl/5.16.1/perlvar.pod

ブラウザページ内検索をすれば、引っかかるでしょう。

■perldocコマンド
以下のように「-v」オプションで調べることができます。

perldoc -v $.

Page 2 of 2

© SEEDS Co.,Ltd.