Adways Engineers' Blog

(株)アドウェイズのエンジニアが日々学習したことや作った物などをアウトプットするブログ

KPTよりやるべき作業を明確にできる、【KPTT】のススメ

こんにちは。
他愛のないサービスであればあるほど魅力を感じる、モバイル担当の渋谷です(。・x・)ゝ


みなさんはKPT法というものを行ったことがあるでしょうか?

KPT法とは、プロジェクトなどの【ふりかえり】を行うための手法であり、
  •     Keep     :次回も実践したい
  •     Problem  :改善したい問題点
  •     Try      :次回は挑戦したい
の三つの視点からプロジェクトを整理します。


●KPT法のメリット
  •     問題点が可視化でき、誰でも理解しやすい
  •     やることがシンプルなので誰でもできる
  •     付箋に書くので、口下手や控えめな人からも意見を引き出しやすい。
  •     ホワイトボードなどに全員の視線が集中するので、人vs人ではなく、仲間vs問題、の構図になる
  •     参加者が、良かった点と悪かった点で共通認識を持てる


KPT法のやり方や利点などは、下記のサイトが素晴らしくまとまっております。
@IT:初めてのプロジェクトリーダー(6)



今回は、実際に 当社で行われたあるサーバ移設作業のKPT法を例にして解説してみます。


サーバの移設は約2ヶ月前から準備をしており、インフラ側SEとサービス側SEがそれぞれ2〜4人ほど関わりました。
移設当日は深夜作業となり、予定より移設自体には時間がかかったものの、大きな問題はなく終えることができました。
そして、7月27日弊社会議室にて、サーバ移設作業の振り返り作業を行いました。

●Keep
【Keepは次回も実践したい事】
プロジェクトでうまく行ったことを挙げていきます。
今回はこんな意見が出ました。

  •     『ドキュメント類が早い段階で充実していた』
  •     『IRC(※1)に専用チャンネルがあり、情報共有がスムーズだった』
  •     『週一で行った定例会で認識が統一できた』
  •     『作業メンバ間のコミュニケーションが良かった』


●Problem
【Problemは次回には改善したい事】
プロジェクトで失敗したことや、不備などを挙げていきます。
大事なことは原因を追究することです。
責任を追及するのはやめましょう。
今回はこんな意見がでました。

  •     『Proxyの検証が不十分だった』
  •     『インフラ側とサービス側のエンジニアで、お互いに相手の分野の知識が不足していた』
  •     『作業時間が見積もりよりも長くなってしまった』
  •     『プロジェクト期間が予定よりも長くなってしまった』

●Try
【Tryは次回に行ってみたい事】
今回は出来なかったけど、次回は挑戦してみたいことや、Problemで上がった問題の改善案を書き出してみましょう。
今回はこんな意見が出ました。

  •     『インフラ側とサービス側のエンジニアで、互いの分野の勉強会』
  •     『作業日前日は十分な休息を取る』



KPTを洗い出してみました。
さて、この次は何をすればいいのでしょう?

実は、KPTを洗い出したあと何をすべきか、を解説しているサイトは多くありません。
そのため、KPTをやること自体に満足感を得てしまいがちですが、KPT法を行う本当の目的は、今回のプロジェクトの経験を次回のプロジェクトに生かすことのはずです。


●KPTで良く陥る現象
  •     ・KPTを出したあと、部屋が静まり返る
  •         (KPTを出したはいいが、それをどうすればいいのか分からない)
  •     ・毎回KPTに出てくる Problem が同じ
  •         (問題点が次回に生かされてない)
  •     ・改善案はでるが実行されない
  •     ・KPTをやったことに満足し、終わった後に行動が伴わない
  •     ・Keep Problem Try の項目が多すぎて、結局何をすればいいのか分からない


もし、上記の【良く陥る現象】に該当する項目が一つでもある人は、KPTT法を試されてはいかがでしょうか?


■KPTT法の実践

KPTT法とは、
  •     Keep     :次回も実践したい事
  •     Problem  :改善したい問題点
  •     Try      :次回は挑戦したい事
  •     To Do    :次回までに行う事
の4つの頭文字から成り立つ言葉です。

KPT法に、T (To Do) が追加されてます。


KPT法の問題点として、【具体的な行動を伴わない】というものがありました。
KPTT法は、次回までに行う事 (To Do) が追加されたことにより、【次に行うべき具体的な行動】が明確化でき、参加者全員で共有することができます。


具体的に今回の会議で出てきた ToDo は下記のようなものです。
●To Do
【Keep】の中から、実行可能で次回も絶対に行うべき作業を選び、【ToDo】に追加します。
  •     『早い時期にドキュメントを作成する』
  •     『IRCに専用チャンネルを作る』
  •     『週一の定例会』
【Problem】の中からは、実行可能な改善案を選び、【ToDo】に追加します。
  •     『今回の作業時間を、次回の見積もりに適用する』
【Try】の中からは、実行可能で次回こそは挑戦したい作業を選び、【ToDo】に追加します。
  •     『プロジェクト開始時に、お互いの分野の勉強会を開く』

※KPTTには、【Tryの中からすぐに実行可能なタスク】だけを洗い出して、ToDoへと入れる方法もありますが、今回はふりかえり間隔が長いプロジェクトを想定しているので、この方法を取ります。



ここで大事なことは『実行可能で具体的』な事を選択することです。
あれもこれも、と欲張りすぎると、作業量が多すぎて負担が増え、結局すべて実現できなかった、なんて事態になりかねません。
また、
  •     ・開発期間を長く取る
  •     ・個々の技術力を向上させる
  •     ・人為ミスがないように注意する
こういった意見は、抽象的かつ実現できるとは限りません。
このような抽象的な意見は、具体的な行動に置き換えてみましょう。
    【人為ミスがないように注意する】
        ↓      ↓      ↓
    【今回起きた人為ミスをドキュメントにまとめ、みんなに共有する】


図で表してみると、図1のような感じになります。

図1
0001




ToDoを見てみましょう。
ToDoには今、『次回やればいい』事が全て書いてあります。
言い換えれば、『次回のプロジェクトでは、【ToDo】に書いてあることだけをすればいい』のです。


このように KPTT法を用いると、やるべき作業が明確化されます。



一度お試しあれ〜(。・x・)ゝ


※1 IRCについては、下記参考URLをご覧ください。
    IRC普及委員会 HOME
    LimeChat


Mooseを使ってコマンドライン引数を処理する

最近、Moose の素晴らしさに気付いて使い始めた sasata299 です。こんにちわ。(=゚ω゚)ノ

Moose ってとても便利だと思うんですが、どう使ったらいいものかよくわからない・・・。そんな人も多いのではないかと思ったので、今日は Moose を使う一例を紹介してみます。

そもそも Moose の利点って何?という話ですが、Moose にはこのような利点があります。
  • use strict; use warnings; しなくていい。自動でやってくれる
  • Perl5 で OOP をより簡単にできる
  • 型チェックしてくれるので、本質的な部分に集中できる。可読性も(慣れれば)上がる
素晴らしいじゃないですかぁ〜

ただ依存モジュールが多かったり、コンストラクタの処理に時間がかかるという欠点もあります。でもその欠点を補って余りある便利さです。

例えば、以下のような仕様でスクリプトを作る場合を考えてみましょう。

スクリプトの仕様
  • コマンドライン引数として、--fromオプション、--toオプション、--typeオプションがある
  • --fromオプション、--toオプションは必須。YYYY-MM-DD形式で指定する
  • --typeオプションは 1〜5 のいずれかの整数値をとる(指定しない場合 1 がセットされる)

コマンドライン引数の処理って値のチェックが面倒くさいですよね。。これを Moose を使わずに実現するとなると、こんな感じでしょうか?

#!/usr/bin/perl

use strict;
use warnings;
use Getopt::Long;
use DateTime;

GetOptions( my %config, 'type=i', 'from=s', 'to=s' );
$config{type} ||= 1;

# --fromオプション、--toオプションが指定されていなかったらエラー
die "not defined error" unless defined $config{from} and defined $config{to};

# 存在しない日付だったり、日付の形式がおかしかったらエラー
for ( @config{qw/from to/} ) {
    my @date = split /-/, $_;
    DateTime->new(
        year  => $date[0],
        month => $date[1],
        day   => $date[2],
    );
}

# --typeオプションの値が1〜5じゃなかったらエラー
die "invalid value error" unless $config{type} > 0 and $config{type} < 6;

# -----
# 以下で様々な処理を行う

値のチェックが多くて、あまり本質的じゃない部分に時間が掛かってしまいます。。。

一つのスクリプトならまだ我慢できますが、このようなスクリプトをたくさん作る場合はどうでしょうか?値のチェックの部分を再利用しようにもあるスクリプトでは start と end で日付を指定したり、あるスクリプトでは type の取る値として 0 と 1 のみが許可されていたり・・・。何とかやれないことはないですが、かなりカオスです。

そこでこのように Moose を使ってみるのはどうでしょうか。

package MySample;

use Moose;
use MyTypes ':all';
with 'MooseX::Getopt';
 
has 'from' => ( is => 'rw', isa => 'ValidDate', required => 1 );
has 'to'   => ( is => 'rw', isa => 'ValidDate', required => 1 );
has 'type' => ( is => 'rw', isa => 'OnetoFive', default => 1 );
 
__PACKAGE__->meta->make_immutable; # おまじない
 
no Moose;
 
1;

これはコマンドライン引数について定義したクラスです。Moose を使う場合、has というメソッドを使って、is で ro(read only), rw(read and write) を指定したり、isa で Str(文字列), Int(整数) など、型を指定することが出来ます。例えば型として Int を指定した場合、「整数かどうか?」のチェックが行われ、文字列や小数を指定したときにはエラーが出力されます。

これだけでも便利ですが、isa には組み込みの型に加えて、自分で作ったものを利用することも出来ます。実は ValidDate や OnetoFive というのは自作の型だったりします。自作の型の定義は再利用できるようにするため、別クラスに切り分けました。

また、MySample では with というものを宣言しています。これは Moose の Role という便利な機能です。Role について今回は詳しくは説明しませんが、こちらに詳しく説明されているので良ければご覧ください。

package MyTypes;

use DateTime;
use MooseX::Types -declare => [ qw/ValidDate OnetoFive/ ];
use Moose::Util::TypeConstraints;

# YYYY-MM-DD形式で、存在する日付じゃなければエラー
subtype 'ValidDate'
    => as 'Str'
    => where {
        my @date = split /-/, $_;
        DateTime->new(
            year  => $date[0],
            month => $date[1],
            day   => $date[2],
        );
    };

# 整数で、1〜5じゃなければエラー
subtype 'OnetoFive'
    => as 'Int'
    => where {
        $_ > 0 and $_ < 6;
    };

no Moose::Util::TypeConstraints;

1;

これは自作の型を定義したクラスです。例えば、ValidDate という型はまず as で指定した型である Str(文字列) を継承します(文字列かどうかのチェックを行います)。その後、where で指定したチェックを行います。これらのチェックで問題があればエラーメッセージが表示されるわけです。

#!/usr/bin/perl
use MySample;
my $config = MySample->new_with_options();
 
# -----
# 以下で様々な処理を行う

これがメインのスクリプトです。とてもすっきりしました!! MySample を use して、new_with_opitonsメソッドを呼ぶだけです。必要な値のチェックは MySample クラスで定義済みなので自動でやってくれます。オプションの名前や条件が違う場合は、別クラスを作って、その中で任意の引数名や isa を指定してあげて、それを use すればOKです。

ちなみに 以下のように MySample を少し変更することでyamlファイルの設定を同時に読み込んだりも可能です。yamlファイルとコマンドライン引数で同じオプションを指定した場合、コマンドライン引数が優先されます。デフォルトの設定をyamlファイルに書いておくと便利そうですね!

package MySample;

use Config::Any; # 追加
use Moose;
use MyTypes ':all';
with 'MooseX::Getopt';
with 'MooseX::ConfigFromFile'; # 追加

has 'from' => ( is => 'rw', isa => 'ValidDate', required => 1 );
has 'to'   => ( is => 'rw', isa => 'ValidDate', required => 1 );
has 'type' => ( is => 'rw', isa => 'OnetoFive', default => 1 );
has '+configfile' => ( default => '/etc/foo.yaml' ); # 追加

__PACKAGE__->meta->make_immutable; # おまじない

no Moose;

# 追加
sub get_config_from_file {
    my ($self, $file) = @_;
    my $config = Config::Any->load_files({
        files   => [ $file ],
        use_ext => 1,
    });
    return $config->[0]->{$file};
};

1;

Moose はとっつきにくいかもしれませんが、慣れればとても便利ですので、是非使ってみてください。でわでわ〜ヾ(o゚ω゚o)ノ゙

新人後輩SEに業務に入る前に読んで欲しい記事 15選

こんにちは。
モバイルを担当している、渋谷です。


4月から約2ヶ月がたちました。
そろそろ多くの企業で新社会人が研修期間を終え、各チームに配属される時期ではないでしょうか?

今年唯一モバイルチームに配属された新人の子も、6月から実務がスタートしました。
期待の新人!


さてさて、そんな【新・技術者の卵】の可愛い後輩たちに是非立派に成長してもらいたい。
というのが、先輩たちみなさんの思いだと思います。

そこで自分が今まで読んで、『これは読んでためになった!』『考え方が変わった』『是非他の人にもおすすめしたい』と思った記事をまとめてみました。


■効率・仕事術
ITmedia Biz.ID:Wordのお節介をなくす10の方法
社会人になると、ドキュメントを書く機会が増えます。
技術の仕事でも、それは残念ながら同じですね。
会社によっては、プログラマなのにプログラム言語よりドキュメントのほうが書いてる時間が長い。なんて所もあるかもしれません。
技術は凄く高いのに、ドキュメントの製作に時間がかかっては、会社のためにも本人のためにもなりません。
『Word のドキュメント作成を少し助けてくれる、豆知識』  を丁寧に教えてくれるので、一度目を通すことをオススメします。


3分LifeHacking:入力の手間を省く、10のExcelショートカット - ITmedia Biz.ID
社会人は Excel もよく使いますね。
仕様書の作成や、実行速度のベンチをグラフで可視化したり。
報告書のテンプレートが Excel の会社も多いと思います。
そんな『 Excel の作業を手助けするショートカット』が10個紹介されてます。
Excel を使う機会があるなら、読んで損はないですよ。


ちょっと覚えておくと便利なExcelのショートカット5つ | POP*POP
こちらも Excel 関係の記事。
簡単なショートカット5つなんだけど、知っていると知らないじゃ大きな差が出る。
Excel を使う機会が多ければ多いほど、効果的。


はじめてのGTD - ITmedia Biz.ID
これはやや lifehack よりなネタではありますが、GTDの説明ページです。
GTDの入門としては、最良のページではないかと思います。

そもそも、GTDって??
何が便利になるの??
始めるためには何をすればいいの??

そんな素朴な疑問に全て答えてくれます。


Becky!を快適に操作するための10の設定 - livedoor ディレクター Blog(ブログ)
これは、各社で使っているメーラーに依存するので、Becky を使っていない会社では必要ないですが、Becky を使っている会社なら、かなり便利になると思います。
メールを見やすくする方法や、自分宛のメールを見逃さない方法など。

Becky快適生活は、これを読んだ時点から開始されます。


■新人技術者として
「アウトプット重要」――エンジニアたちの必勝勉強法 − @IT自分戦略研究所
社会人としての勉強法ってなんでしょう?
エンジニアとしての勉強法ってなんでしょう?

学生時代の、単位を取れば完了、という勉強とは違い、社会人になってからの勉強は、自分のキャリアプランに直接的な影響を与える重要なものです。

【20代にどんな知識をどれだけ勉強できたか】
それはエンジニアにとって、かけがえのない、非常に重要な、そして、取り返しのつかない事です。
この記事は、そんな不安と期待を胸に抱いている新人SEの疑問を少し解いてくれるかもしれません。

先輩エンジニアの勉強法とは・・・?


新人プログラマーがプロのプログラマーとして独り立ちするための7つの条件 - ハックルベリーに会いに行く
プログラマーとして必要な物とは何なのか。
その4「身辺を整理しておく」
その3「リソースが足りないと言わない」
すみませんm(_ _)m
その2「常に手抜きを考える」
その7「忘却力を備える」
共感しました。


勉強が苦手な人向けの「遅延評価勉強法」 : ロケスタ社長日記
「必要になったら、必要なところだけ勉強する」

社会人になると、時間の大切さが身にしみます。
特にエンジニアという職業は、覚える事に終わりはなく、先を見れば見るほど絶望感に襲われるほど多くの知識を必要とされます。
ただ闇雲に勉強ばかりしていても、時間を無駄に過ごすだけになりがちです。


スケジュールを作るプログラマが一番効率が良い。 - 山本大@クロノスの日記
期限が厳しければ厳しいほど、何よりも早くコーディングしたくなりませんか?
早く動くものを作って、とりあえず完成のめどを立てたい。
じゃないと不安で不安でいられなくなる。

しかし、そんな状況のときこそ、じっくりとスケジュールを立てることが重要です。
人間は未来が見えないと不安です。
正体不明な物事に恐怖を覚えます。
問題がわかり、状況がわかり、見通しがつけば、それだけ安定した心でコーディングをスタートできます。

そんな事を教えてくれる記事です。


■社会人として
新人におくる、怠惰な社会人になるための7の方法 : ロケスタ社長日記
タイトルだけ読むと誤解してしまうかもしれないですが、新人の方にこそ是非読んでいただきたい。
プログラマの三大美徳に【怠惰】が含まれているほど、怠惰とは大事なこと。
1:やたらと努力でカバーしない
4:自己満足に気をつける
上記の二つは特に新人の頃に陥りそうですね。


フィンランドの5年生がまとめた議論のルールが凄い - タケルンバ卿日記
本当に五年生がまとめたんでしょうか。凄いです。
社会人としてそのまま使えるルールばかりです。
そして、現在の会議でできてないルールも多いのではないでしょうか?
またタケルンバさんの独自の解釈も載ってます。
『4:わからないことがあったら、すぐに質問する』
『9:どのような意見であっても、間違いと決めつけない』
このあたり共感。


社会人なら押さえておきたいフレームワーク思考 - livedoor ディレクター Blog(ブログ)
有名な livedoor ディレクターBlog の中でも特に有名な記事ですね。
lifehack にも、仕事の効率にも、つながると思います。
  • 多すぎるタスクに振り回され、どのタスクを優先すればいいか、分からなくなっていませんか?
  • 何が悪かったかも分からないまま、次の仕事に進んでいませんか?
  • ただ上司や顧客から言われた物を作る毎日になっていませんか?
後輩だけじゃなく、上記のようなことに悩んでいる先輩SEの方々にも役立つと思います。


知らないと損するフレームワーク思考活用法 - GoTheDistance
この記事は、『社会人なら押さえておきたいフレームワーク思考 - livedoor ディレクター Blog(ブログ)』こちらの記事を読んだ、id:gothedistanceさんが、自分が使用しているチャートのサンプルを紹介してくれています。

分かりやすくまとめてあるので、livedoor ディレクター Blog の記事を読んで、『実践してみたい!』と思った方がいましたら、是非見てみてください。


■考え方
最後は lifehack です。
lifehack は押し付けるものではなく、自分が必要だと思ったときに自主的に学ぶべきものだと思うので、紹介するかどうか迷ったのですが、もし興味がある後輩の方がいらしたら、下記のような記事を教えてあげてはいかがでしょうか?

週に一度、日曜日に自問すべき20の質問 - IDEA*IDEA 〜 百式管理人のライフハックブログ 〜
いわずと知れた百式さんのサイトです。

業務が始まると、『次々と降りてくる仕事』  『わからない事だらけの毎日』  『終わることのない勉強』   と日々の忙しさに追われて、自分が一体どこに向かっているのか、わからなくなってきます。
そんなときに、見てほしい記事です。
  • あなたは何のために働いてますか?
  • あなたにとって大切なものとは?
忙しい日々の中に、ちょっとだけでも自分を振り返る時間を作ってみてはいかがですか?


1ヶ月間だけ、思い切りがんばれば。 - Attribute=51
最後は個人的に好きな記事なのでご紹介。

くじけそうな時、読んでみてください。
後輩が落ち込んでいたら、教えてあげてください。

この記事で励まされた人はたくさんいると思います。



■まとめ
PMやディレクターに必要な3つのマネジメント - GoTheDistance
こちらの記事で紹介されている Twitter の発言にこんなのがあります。
エンジニアを Final Fantasy で表すと、
戦士からナイトを経て最終的には黒魔導師を目指してください」
と言ってるようなもんだと思うんだけどな。
これは、エンジニアというキャリアパスを的確に捉えていると思います。

新人の頃はプログラムに明け暮れ、技術を磨いていったと思ったら、ある日突然会社から『技術はもういいからマネジメントをやれ』と命令される、『プログラマ35歳定年説』を皮肉ったものです。

後輩は、まだ 『ナイト』 を目指すのか 『黒魔術師』 を目指すのかも分からない状態です。
いわば 『すっぴん』。
屈強な最強の技術者 『グラディエーター』 になるかもしれません。
みんなをまとめ上げる 『大賢者』 になるかもしれません。
バランスのとれた 『魔法剣士』 かもしれません。
人のマネしかしない 『モノマネ士』 の可能性だってあるし、会社に害しかもたらさない 『ラスボス』 になる可能性もあります。

後輩が何になるか。
最初の一歩をどの方向に歩き出すのか。

社会人の最初の一歩を、自分の目標に向けて正しく歩みだすために、今回ご紹介した記事たちがお役に立てれば幸いです。


スキャン機能だけじゃない、ここがParosの凄いところ

はじめまして。テストが大好きなSE、"みず"です。
今回は私が使っているペネトレーションテスト(※)&ブラックボックステストの補助ツール「Paros」を紹介します。

※本来は、防弾ベストの銃弾への耐性をチェックするテストのこと。転じて、ソフトウェアやネットワークのテスト時に、"実際に攻撃をするテスト"を指す。今回の場合、対象がWEBのシステムなので、"リクエストに予期せぬデータを入れて攻撃を行うテスト"という意味で使っています


まずParosがどんなツールか説明します。ParosはWebテストツールの一種であり、脆弱性スキャナです。脆弱性スキャナということは、セキュリティ的に脆弱なところはないかどうかチェックしてくれるツールです。Parosの場合は、リクエストデータに様々なPOSTデータやGETデータを持たせ、チェックする仕組みになっています。

Parosのメイン機能は「脆弱性のスキャン」なのですが、実はスキャナとして使ったことはありません。「毎回トークンを発行しているページでは使えない」とか、「ページ単体のチェックしかしないので影響範囲全てをカバー出来る訳ではない(※)」などが理由です。

※【例】入力ページ→入力内容確認ページ→結果ページという遷移を取る場合、結果ページまでカバー出来ない


ではどこが便利なツールなのかというと、「ログの機能」です。
Parosは、プロキシとして動いてURLとURL毎の入力項目を取得し、入力項目にいろいろな値を入れてスキャンするという仕組みなのでログの機能を持っています。
このログ機能、かなりテストに便利なのです(σ'∀')σ*+.*

Parosの使える機能を紹介すると、、、

■リクエストとレスポンスを保存

Parosはリクエストヘッダーとレスポンスヘッダー、レスポンスのコンテンツのデータをログとして保存してくれています。ブラウザのようにタグ通りの表示はしてくれませんが、HTMLタグが見れるので"戻る"を禁止しているシステムで前のページの文言を調べたい時などに重宝します。テストのログとして使ってます。

paros_01

■URL毎にログの履歴が見れる

Parosをプロキシとして立ち上げてログを取らせると、URLの一覧が出てきます。
これが、URL毎のリクエストとレスポンスのログです。
Live HTTP Headersを使っていると、以前のリクエストヘッダーを探すのに非常に困りますがParosだとURLから探せるので便利です。

paros_02

■URL毎にステータスコードが見れる

URL毎のステータスコードが横に表示されるので、異常なステータスコードが返って来るURLやプログラムがすぐに分かります。
200 OK以外が出ていれば気付けるので、画像呼び出しのスペルミスなどが簡単に見つけられます。

paros_03


■リクエストを編集して再送信できる

リクエストを編集して再送信できます。POSTデータも書き換えられるので、プルダウンやチェックボックスを持つフォームの異常値のチェックに使えます。
HTMLを取得してHTMLタグの内容を編集して送る、もしくは、プログラムを作ってリクエストを送信する、こういった面倒な作業をせずにテストが出来ます。
paros_04


■プロキシ認証に対応

「社内から外部への通信には、プロキシ認証があるから無理」とテストツールの導入を諦めていた人に朗報です。Parosはプロキシ認証に対応しています。
(プロキシに対応しているツールはあっても、プロキシ認証に対応しているペネトレーションテストツールはなかなか見つかりません)
ちなみに、プロキシサーバーの指定、プロキシのID・パスワードの設定は、Tools→Option→Conectionから行えます。

paros_05


■Windows環境でも動きます

Javaなのでランタイムが入っていれば、WindowsでもLinuxでも動きます。
OSによらず使えるので、便利です。

英語なので取っ付きにくいかもしれませんが一度使ってみると、いろいろ問題を見つけられて手放せなくなります。是非使って、ご自身のプログラムを可愛がってあげてください。
Parosではなくとも、WebScarabなどこういったプロキシ型のWebアプリケーションテスト補助ツールは幾つか存在します。機能や使い勝手、好みの応じてより良い開発ライフを送ってください^^!

最後に、使う際の注意です。
実際に攻撃を行うツールですので、取扱には注意してください。
ご自身の管理しているサーバーに対して使ってください。



ファイルの違い

こんにちは。デザイナーをしています、まつこです。
エンジニアブログなのですが、ちょいと記事を書くことになりました。
どうぞよろしくお願いします。


ちなみに総合テーマは、
「文系WEBデザイナーにだって生きる道はあるはず」

こちらで今後も記事を書いていく予定です。


なんでWEBを選んだんだと言われればそれまでですが、やりたいんです。WEBで生きたいんです。
文系WEBデザイナーはいつもWEBがもっと感覚的になればいいのにと思っています。
なんで英数字で書かないといけないんだと思っています。


そういう視点からWEBデザインに必要な知識を紹介していきます。
文系でWEBデザイナーになりたい方は、参考にしてください。
理系の方は、文系WEBデザイナーと話すときの参考にしてください。


第1回目は「ファイルの違い」です。

------------------------------------

一般的にWEBサイトを作るときには「gif」とか「jpg」を使うことが多いです。

なぜ。

「gif」とか「jpg」を使うことが多いのは、ちょっと前のブラウザは表示に制限があってそれ以外の画像がほとんど使えなかったからです。
最近はそういう制限があまりなくなってきたので他の画像も使えるようになってきました。

じゃあ「psd」は使えるのか。

それはムリです。

なぜ。

そういう「なぜ」を解消するために、よく使われる画像について簡単に説明をします。



■gif

最大256色まで使用可能です。アイコンや単純なイラストなどで使用します。ドット絵作ったらこれで保存します。
パラパラマンガ式のアニメーションが作成できます。アニメバナーはこれで作ります。
背景透明に出来ますが、端がジャキジャキになるのであまり使いません。


■jpg

画像を圧縮して保存します。保存を繰り返すたびに再圧縮して劣化するので繰り返さない方がいいです。一度劣化したものはもう元に戻らないですから。
写真のような複雑な表示のもので使用します。


■png

「png-8」と「png-24」の2種類あります。

「png-8」は、「gif」とよく似ています。最大256色。
しかし!「gif」より容量が軽いのです!IE6を切り捨てるのであれば、「gif」じゃなくて「png」で保存した方が軽いページになります。

「png-24」は、とてもキレイに透明を表現できます。背景透明にしたい画像はこれを使います。
ただ、その分ちょっと容量重いですけどね。


■bmp

無圧縮なので容量が重いです。
私はあんまり使いません。


■tiff

画像を劣化させることなく保存できます。photoshop等で作業中のレイヤーも保持可能。
DTPで扱う写真データはよくこれで保存されてるようです。(今まで見た中では)
とても容量が重ーーい事が多いです。

■psd

「photoshop」で普通に保存したらこれになります。
作業中の全てのデータが保持されます。
ただし、「photoshop」を持っていないと開くことは出来ません。

‥みんなが見れないならwebで使えないですよね。冒頭のギモン解決です。
(もっと簡単に言うとブラウザが「psd」に対応していないだけという答えもありますが)

ソフトについてはまた別の機会に書こうかなあと思います。


■ai

「illustrator」で普通に保存したらこれになります。
「illustrator」を持っていないと開くことは出来ません。持っていてもバージョンの違いによって開かなかったりします。
納品するときはバージョンを10くらいまで落として保存します。(2009年4月現在の最新はCS4)


■eps

「ai」で作ったデータを印刷屋に出すときに、これで保存するよう指定されたりします。
「ai」より互換性が高くて、「illustrator」を持っていなくても対応するソフトを持っていれば開きます。


■fla

「flash」で普通に保存したらこれになります。
作業中の全てのデータが保持されます。
flashを持っていないと開くことが出来ません。


■swf

「flash」で作ったデータをweb表示用に書き出したファイルです。
よくこのファイルを編集してくださいとわたされますが、基本的に出来ません。見るだけです。



普段よく登場するファイルはだいたいこんな感じです。
なんとなく違いが分かったでしょうか?

WEBデザイナーはこんなファイル達と仲良く楽しく仕事をしています。

ではまたお会いしましょう。


matsuko_1



Adways プロフィール
記事検索
  • ライブドアブログ