社内で新卒向けに講義をしました。社内固有の情報を削除した上で、下記に講義資料を公開します。

ソフトウェア開発における開発者の仕事を理解してもらうために話をしました。

講義対象者の半数以上が開発志望ではなかったので、開発者でない人が、今後、IT業界の中でどう開発者と向き合っていくかを主眼にして話しました。IT業界にいながら、開発者のことを理解できない人たち、あるいは何をしているのか分からない、と偏見を持つ人がいるからです。彼らにそうなって欲しくないからです。共感できるかは別です。考え方や価値観が違うなら違うでもいいと思います。はじめから理解を拒否していたら、いつまでもコミュニケーションが生まれません。

ついでに、半数以上が女性だったので、裏の意図として、プログラマがモテるようになって欲しいと思って話しました。プログラマがモテる世界にしたいと思っているからです。若い女性の前で話す機会を得られた今、プログラマの世界で育てられた自分にとって果たさなければいけない責務だと思っています。

==========================================================
新卒向けの講義:

ソフトウェア開発という仕事

* この講義の目的

- ソフトウェアの開発者の生態の理解

(原則)開発者志望ではない人を想定します

* 目次

- ソフトウェア開発にはどんな職種があるのか?(世間一般)
- 開発者は普段何をしているのか?
- ソフトウェア開発とは?

* ソフトウェア開発にはどんな職種があるのか?(世間一般)

** IPAのITスキル標準(ITSS)

- http://www.ipa.go.jp/jinzai/itss/index.html
- 職種名、必要スキル、業務内容を整理した一覧
- 職種と専門分野が横軸、スキルレベル(7段階)が縦軸
- 資格ではなく、スキルの指標

** ITSSの特徴

- 単線キャリアパス(PG=>SE=>PM)から、複線キャリアパス(下級PG=>上級PG、下級SE=>上級SE、下級PM=>上級PM)へ転換

** ITSSの職種

- マーケティング
- セールス
- コンサルタント
- ITアーキテクト
- プロジェクトマネジメント
- ITスペシャリスト
- アプリケーションスペシャリスト
- ソフトウェアデベロップメント
- カスタマサービス
- ITサービスマネジメント
- エデュケーション

詳細は

http://www.ipa.go.jp/jinzai/itss/download_V3_2011.html

「2部 キャリア編の補足A」を参照

** ITSSのスキルレベル

- レベル7: 世界で通用するプレーヤ
- レベル6: 国内のハイエンドプレーヤ
- レベル5: 企業内のハイエンドプレーヤ
- レベル4: 社内においてプロフェッショナルとして認められる
- レベル3: 要求された作業を全て独力で遂行
- レベル2: 上位者の指導の下に、要求された作業を担当
- レベル1: 最低限必要な基礎知識を有す

** スキルのジレンマ

- 固有の知識(特定の製品・サービスや特定のプログラミング言語)だけでは、いずれ古びるリスク
- 固有の知識を伴わない知識や技能だけでは単なる評論家

古びないように自分のスキルを常に見直す必要

** ITSSの使い方

- 「普通の人」は、ITSSの知識体系から自分に必要なスキルを具体化する
- 「普通でない人」は、自分のスキルを抽象化して、ITSSの知識体系のどこに位置するか知る

- 職種の分類にこだわる必要はない

* 開発者は普段何をしているのか?

** 開発部内の主な職種

- プログラマ: ソフトウェアを書く人
- テスト担当者: ソフトウェアの正しさを検証する人
- インフラ担当者: ソフトウェアが正しく動く環境を整備する人

** プログラマが普段していること

- コードを書く(新機能開発、バグ修正)
- コードを読む(壊れないようにするため)
- テストする
- 調べる(どうやって実現するか調べる)
- 考える(どうやって実現するか考える)
- 新機能を提案する
- 技術の先行調査(知識のストック)
- 情報伝達(成果を披露)
- 営業協力(実現可能性の相談)
- 製品サポート(トラブル対応)

** 製品開発の段階とプログラマの役割

1. 要求を聞き出す or 発見する
2. 何を作るか考える(いわゆる要件定義)
3. どう実現するか考える(いわゆる設計)
4. コードで実現する(いわゆる実装)
5. 要求を満たす品質にする

- アリエルの多くのプログラマ: 3と4を担当
- アリエルの一部のプログラマ: 2と3と4を担当
- アリエルの古老プログラマ: 1から4まで担当
- アリエルの伝説的プログラマ: 1から5まで担当

** テスト担当者が普段していること

- 製品のテストをする
- バグを報告する
- 機能提案をする
- 修正されたバグを検証する
- 製品の品質を見える化する(リリース判断の情報提供)
- テストを効率化する
- プログラマの情報を翻訳して情報伝達
- プログラマにプレッシャーをかける
- プログラマを励ます
- 製品サポート(トラブル対応)

** プログラマとテスト担当者のまじわり(新機能開発編)

1. プログラマが機能について課題管理システムにチケットを作成して仕様を記載
2. プログラマが自分の手元でコードを書く
3. プログラマが自分の手元で動作を確認する
4. プログラマがソースコード管理システム(SCM)にコードをコミットする
5. プログラマがチケットの仕様を最終確認してステータスをfixedにする
6. 自動で単体テストなどのチェックが走る
7. 毎日、自動でビルド(コードから完成物を生成)が走る
8. できたソフトウェアを動かす(一部のテスト環境は自動デプロイ、一部は手動デプロイ)
9. テスト担当者がソフトウェアが想定どおりに動くか確認(verify)
10. 想定どおりの動きをしない場合、チケットをreopenする
(reopenされたチケットはプログラマに戻る)
11. 動作およびチケットに記載された仕様に問題がなければチケットを閉じる

** プログラマとテスト担当者のまじわり(バグ修正編)

1. 毎日、自動でビルド(コードから完成物を生成)が走る
2. できたソフトウェアを動かす(一部のテスト環境は自動デプロイ、一部は手動デプロイ)
3. テスト担当者がテスト仕様書をもとに、ソフトウェアが想定どおりに動くか確認する(システムテスト)
4. 想定どおりの動きをしない場合、チケットを作成してバグ報告する
(作成されたチケットはプログラマに行く)
5. プログラマがチケットに記載されたバグを修正する
6. 以下、略

** インフラ担当者が普段していること

- パフォーマンス計測
- 営業協力(実現可能性の相談)
- 導入支援(キャパシティプラニング)
- 情報伝達(導入や運用のマニュアル化)
- 技術の先行調査(知識のストック)
- 製品サポート(トラブル対応)
- 管理コスト軽減の側面での機能提案

* ソフトウェア開発とは?

** 様々な見方

- 製造?
- 設計?
- サービス?

業界での完全なコンセンサスをまだ得ていない
ソフトウェア開発が未成熟な証

** 製造業アプローチ

建築や製造業のようにソフトウェアの故障率の予測可能を目指す考え方

- プロセスモデル(cf. CMMI)
- ウォーターフォール
- クリーンルーム手法
- ソフトウェアファクトリー
- ハッカー気質や職人の否定

周期的に盛り上がっては消えていくソフトウェア業界の青い鳥

** 設計業アプローチ

建築や製造業と比較した時、コードは設計図に当たるという考え方(故障率という発想そのものの否定)

- 設計図なので試行錯誤は必然と見なす
- 製造に相当する工程はコンパイルやビルド(自動化済み)
- プロセスよりツールや技法(職人)を重視
- ハッカー気質の肯定

現実にもっとも適合したアプローチ。あるがままを受け入れる禅の世界

** サービス業アプローチ

ソフトウェア故障率の予測ではなく、使う人の満足度の向上の予測可能を目指す考え方

- プロセスより顧客との対話を重視
- アジャイル(cf. スクラム、XP)

コミュニケーションや顧客満足度を出されると誰も反論できない最強兵器
(熟考の末ここにたどりつく玄人と、歴史を知らず雰囲気だけでここに飛びつく素人が共存する世界)

** 開発プロセスと用語

- 要求(wish or desire)とは?
利用者の願い
(本当の要求は言語化されるとは限らない。マーケティングの領域に近い)
- 要件(requirement)とは?
技術的な裏付け(実現可能性:feasibility)をもとに要求を定義したもの(広義)
かつ関係者で合意したもの(狭義)
- 仕様(specification/spec.)とは?
ソフトウェア動作を記述したもの
完全な仕様はコード以外に存在しえないジレンマ
- コード(code)とは?
ソフトウェアの記述そのもの
- 設計(design)とは?
広義には、仕様作成からコード記述まですべての行為を指す用語
狭義には人それぞれ(仕様書とコードの中間生成物の設計書を書く行為など)
語源に忠実になれば、概念を記述(コトバ、コード、図など)して伝達すること
- 実装(implementation)とは?
一般にコードを書く行為のこと
- ビルド(build)とは?
コードから動くプログラムを生成する工程(一般に自動化される)
==========================================================

関連文書:

• 関連文書は見つからんがな

「Emacsのトラノマキ」の原稿を公開します。画面上のメニュー「ドキュメント」からたどれます。

佐藤さんによる「怠惰なプログラマのためのドキュメント作成実践」です。Software Design 2010年9月号の掲載記事です。連載の中でも人気のあった記事です。org-modeの話ですが、みんなorg-modeが好きなんですね。

最近のEmacs界隈(なんてものがあるか知りませんが)の最大のニュースは松山(m2ym)さんのGoogle Summer of Code採択です。松山さんがいればたとえストールマンが死んでもEmacsは安泰です。

関連文書:

• 関連文書は見つからんがな

最近の社内の新卒第1期生ブームを受けて、第ゼロ期生が本気を出し始めました。

もともと才能は一級品と言われてきた逸材です。そんな第ゼロ期生のレポートを本人了承を得た上で掲載します。トラフィック制限の話です。

iptablesのhashlimitでトラフィック制限

参考サイト

• http://c-heart.sakura.ne.jp/mt/archives/2009/10/iptables.html
• http://kfujio.blog78.fc2.com/blog-entry-72.html

設定

• 特定のIPアドレスとの通信のhashlimitを1666パケット/secに設定
  (mtu = 1500の場合
  1666 (packets/sec) * 1500 (byte/packets) /1024/1024 = 2.38MByte/sec
  となる事を意図)
• それ以外の通信については all pass

とします。

以下の例で通信相手のIPアドレスをAAA.BBB.CCC.DDDと表記します。

1. iptablesの起動/終了スクリプトを作成

/usr/local/bin/iptables-up.sh
------------------------------------------------------------------
#!/bin/sh
iptables -F
iptables -X

RESTRICTED_IPADDRESS1=AAA.BBB.CCC.DDD

# INPUT
iptables -N FW-INPUT
iptables -A FW-INPUT -i lo -j ACCEPT
iptables -A FW-INPUT -p tcp -s $RESTRICTED_IPADDRESS1 -m hashlimit --hashlimit 1666/sec --hashlimit-mode srcip --hashlimit-burst 2500 --hashlimit-name prot_limit_in -j ACCEPT
iptables -A FW-INPUT -p tcp -s $RESTRICTED_IPADDRESS1 -j REJECT
iptables -A FW-INPUT -i eth0 -j ACCEPT

# OUTPUT
iptables -N FW-OUTPUT
iptables -A FW-OUTPUT -i lo -j ACCEPT
iptables -A FW-OUTPUT -p tcp -d $RESTRICTED_IPADDRESS1 -m hashlimit --hashlimit 1666/sec --hashlimit-mode dstip --hashlimit-burst 2500 --hashlimit-name prot_limit_out -j ACCEPT
iptables -A FW-OUTPUT -p tcp -d $RESTRICTED_IPADDRESS1 -j REJECT
iptables -A FW-OUTPUT -i eth0 -j ACCEPT

# apply
iptables -A INPUT -j FW-INPUT
iptables -A FORWARD -j FW-INPUT
iptables -A OUTPUT -j FW-OUTPUT
------------------------------------------------------------------

/usr/local/bin/iptables-down.sh
------------------------------------------------------------------
#!/bin/sh
iptables -F
iptables -X
------------------------------------------------------------------

参考サイト

• iptablesチュートリアル 1.2.2

2. 起動時にこの設定を読ませる(debian系)

# ln -s /usr/local/bin/iptables-up.sh /etc/network/if-pre-up.d/iptables-up
# ln -s /usr/local/bin/iptables-down.sh
/etc/network/if-post-down.d/iptables-down

とした後で/etc/network/interfacesに

pre-up /etc/network/if-pre-up.d/iptables-up
post-down /etc/network/if-post-down.d/iptables-down

を追加

3. 実験

とりあえずscpで実験してみたのですが、

• 受信は大体意図通りに通信量を制限出来る
• 送信は特に制限されているようには見えない

という感じになりました。

shaperdでトラフィック制限

もう少しちゃんと通信量を制御出来、なおかつ簡単そうなものは無いかと検索してみた所、shaperd というもので簡単に制御出来ると出てきました。

参考サイト

• http://semind.github.com/blog/2012/02/24/shaperwoshi-tutepotodan-wei-dezhuan-song-liang-wozhi-xian-suru/
• http://bto.la-terre.co.jp/support/shaperd.html

設定

• 特定のIPアドレス … 送受信共にtcpについて 2000 KByte/secに制限
• その他 … 全ての通信について、6000 KByte/secに制限

とします。

1. iptablesの設定を元に戻す

前回のhashlimit用のiptablesのチェーンを削除します。

# iptables -F
# iptables -X

自動起動の設定をしている場合は
/etc/network/interfacesの
------------------------------------------------------------------
pre-up /etc/network/if-pre-up.d/iptables-up
post-down /etc/network/if-post-down.d/iptables-down
------------------------------------------------------------------
を削除あるいはコメントアウト

2. ip_queueモジュールのロード

# modprobe ip_queue

起動時に自動ロードするように /etc/modules に ip_queue を追加します。
------------------------------------------------------------------
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# Parameters can be specified after the module name.

loop
ip_queue
------------------------------------------------------------------

3. shaperdのインストール

# apt-get install shaperd

4. 設定ファイルの編集

/usr/share/doc/shaperd 以下にある例を見て、/etc/shaperd/shaperd.confを作成。

------------------------------------------------------------------
log level = error
packet forwarding = ipq
daemon = yes
pidfile = /var/run/shaperd.pid
class restricted_in {
        ipv4 classifier proto=tcp saddr=AAA.BBB.CCC.DDD
        bandwidth = 2000 kbyte/s
        queue limits = 1000 kb 1000 packets
}
class restricted_out {
        ipv4 classifier proto=tcp daddr=AAA.BBB.CCC.DDD
        bandwidth = 2000 kbyte/s
        queue limits = 1000 kb 1000 packets
}
class all {
        ipv4 classifier proto=all
        bandwidth = 6000 kbyte/s
        queue limits = 1000 kb 1000 packets
}
------------------------------------------------------------------

最初、class restricted_in と class restricted_out の部分のみ書いて、class all 部分を書かなかった所、unmatched packet となってAAA.BBB.CCC.DDD以外からアクセス出来なくなってしまいました。queue limits の値は何が適当なのか不明です。

5. iptablesの設定スクリプトをコピー

debianのパッケージの場合
/etc/shaperd/up.d にiptablesのチェーンの登録スクリプト、
/etc/shaperd/down.d にiptablesのチェーンの削除スクリプト、
を置くとshaperdの起動/終了時に読み込んでくれるようです。

/usr/share/doc/shaperd/examples/ にスクリプトがあるのでこれをコピーして実行権限を付与

# cp /usr/share/doc/shaperd/examples/up.d /etc/shaperd
# cp /usr/share/doc/shaperd/examples/down.d /etc/shaperd
# chmod +x /etc/shaperd/up.d
# chmod +x /etc/shaperd/down.d

/usr/share/doc/shaperd/example/up.d
------------------------------------------------------------------
#!/bin/sh

iptables -A INPUT -j QUEUE
iptables -A OUTPUT -j QUEUE
------------------------------------------------------------------

/usr/share/doc/shaperd/example/down.d
------------------------------------------------------------------
#!/bin/sh

iptables -D INPUT -j QUEUE
iptables -D OUTPUT -j QUEUE
------------------------------------------------------------------

6. shapedの起動

• /etc/init.d/shaperd start で起動
• /etc/init.d/shaperd stop で終了

自動起動の場合は sysv-rc-conf か update-rc.dあたりで設定

7. 実験

scpで実験すると送受信共に大体設定通りに動いているようです。

起動時に

shaperd: warning: kernel's queue is too short, consider increasing /proc/sys/net/ipv4/ip_queue_maxlen {config.cpp:166}

の警告が出るのが気になる所です。

関連文書:

• 関連文書は見つからんがな

この4月にアリエルに入社した人たちは新卒第1期生と呼ばれています。IT企業らしく第ゼロ期も存在していますが、多くを語らないのが暗黙のルールです。

2013年度の新卒募集が始まりました。入社すると第2期生になります。2進数を使うとイチゼロ世代です。

- アリエル新卒募集ページ

開発者はシャイな人が多いせいか、上記ページの「現職社員ページ」に開発者が出ていません。しかし、開発者も募集しています。ありえるえりあ読者に大学生がどれほどいるかわかりませんが、アリエルに興味があればエントリーしてみてください。エントリーは無料です。無料でエントリーさせてその後課金するようなこともありません。

5月ごろ開発志望者向けの説明会を行う予定です。アリエルが採用したい開発者像や入社後どのようなキャリアパスがあるかについて話します。こっそりD社とG社の悪口も言います。

説明会の主目的はアリエルの魅力を伝えることなので、そこをさぼる気はありません。ただ、美辞麗句を並べてアリエルに是非来てください、というプレゼンもしません。去年の新卒採用向けの説明会でもそうでしたが、もっと広い視野で、IT業界にソフトウェア技術者として就職する心構えを話したいと思います。

特定のスキル(言語、フレームワークなど)の習得は入社した会社で差がでます。しかし、どんなスキルが将来生きてくるかは運次第です。必要になった時に新しい知識を学べる学習スキルのほうが重要です。ただ、学習スキルの獲得は、どこの会社に入るかはあまり関係なく自分次第です。こう書くと、怠惰な人たちに囲まれたら怠惰になる危険があるので入る会社は大事だ、という反論がありそうです。危険はありますが、社外の勉強会で自分を鼓舞する機会は作れるはずです。そういう意味で自分次第です。

ひとつ自己努力だけで容易に学べないものがあると思っています。良い開発プロセスを経験できるかどうかです。良い開発プロセスとはウォーターフォールできっちりやるという意味ではありません。社内の開発者がどれだけ合理的にプロセスを改善しようとしているかが重要です。会社にそういう文化があるかどうかです。開発プロセスは日々の行動の積み重ねなので、勉強会で話を聞いたり本を読むだけでは限界があります(わかった気にはなれますが)。業界経験の浅い技術者であれば、良い開発プロセスがありそうかどうかで会社を選ぶのは良いと思います。学生に使える見極め方を説明会までに考えておきます。

関連文書:

• 関連文書は見つからんがな