Planet EZO
コンピュータやソフトウェアのあれこれ＠道民（＆元道民）
第11回北海道情報セキュリティ勉強会に参加しました
5月 21st
5月18日（土）に開催された、第11回北海道情報セキュリティ勉強会（せきゅぽろ）に参加しました。
今回のテーマは「クラウドのセキュリティ」。
当日朝まで参加を迷っていたのですが（寝だめしたくて…）、セキュリティについての根本的なところの話が聞け、参加して良かったと思えました。
セキュリティとは科学である
株式会社ディアイティの河野省⼆さんがいらっしゃり、3部構成でセキュリティのお話を聞きました。
- 情報セキュリティの現場力・使えるスキルと⼈材像
- クラウドサービスにおけるセキュリティ
- 最近のいろいろなセキュリティの話題
「情報セキュリティは目的ではなく手段である」「ISMSを取得するための情報セキュリティ対策ではなく、真に会社に必要な対策を考えるべき」「利用者の意識を向上させるのではなく、システムで何ができるかを考えるべき」・・・などなど、出てくることが目から鱗の言葉ばかりでした。
特に今まで勘違いしていた（というかそういうもんだと思っていた）ことで、ハッとなったのは次の3つ。
- 社で許可されたUSB以外の外部メディアをPCに接続するのを禁止するのはウィルスが入り込まないようにするため？
→ 否。ウィルスからの保護はウィルスソフトがやればいい。本来の目的は残存データが漏れないようにするため
（USB上のデータは初期化しても消しきれない、復元できる可能性がある） - 大事な書類をメールに添付する危うさ
→ 上司があるファイルに必要事項を入力して返信するよう、5人の部下に書類を添付してメールを出したとする。
この場合最終的に、マスタファイル（1）、上司の送信フォルダ(1)、各部下の受信フォルダ（5）、各部下のマシン（5）、各部下の送信フォルダ（5）、上司の受信フォルダ（5）、上司のマシン（5）合計27ファイル、つまり26ファイルものデータコピーができる。
データコピーができればできるほど、漏洩のリスクが高まるわけなので、共有サーバーやクラウドの利用などで適切に管理するべき。 - メールで重要書類を送る時は、ファイルを圧縮して暗号化し、送信メールとは別便でパスワードを送りましょう
→ 別便でパスワードを送ることに何の意味もない。だって同じNW上じゃない？POPメールなら1つのデータになることもあるよ。（金庫を盗まれた道を鍵を持って歩くようなもの。泥棒は待ち伏せしているだけでよい。）
この場合、パスワードはメール以外の手段で伝えたり、送り先と共通の認識（相手先の会社の電話番号など）をパスワードにするよう取り決めておく方が有効。
どれもやっていることだなあと。しかも何も疑問に思っていなかった。
特に2番目。クラウドなど外部にデータを預けることは危険・禁止となる風潮が多いけれど、ファイルが大量にコピーされるという脆弱性がメールにはあるのだということを恥ずかしながら意識したことがなかったなあ。
適切にログが取れて、管理権限も調整できる共有サーバーやクラウドの方が脆弱性は少ないのですね。
禁止は何も生み出さない
「○○してはいけない」というルールを生み出すことが情報セキュリティではない。これも目から鱗。
どうしても「あれもできない」「これもできない」「これも禁止された」「セキュリティって面倒」となってしまう事が多いので…。
これは「情報活用のための情報セキュリティ」について考えられていないから。
ISMS取得のためであれば、禁止を増やし続ければよいのだろうけれど、新しい事をはじめる・次の時代の事を考えるときに禁止は足かせにしかならない（「一つでも禁止事項があればそれに足を引っ張られて新しい事が導入できない」）。
「してはいけない からの脱却」のために、正しい知識を持った情報セキュリティマネジメントができる人が必要なのですね。（SSCPという資格があるよ！）
クラウドのセキュリティ
「クラウドを利用してリスクがないわけがないじゃないか、でも、リスクがあるからと言って利用を禁止するのはもっと馬鹿」
という最初の言葉が印象的でした。
大事な事は「免疫力を高める」こと（風邪をひくからどこへも行かない？体力つけてどこかへ出かける方がよくない？）。
そのためにはクラウドの特徴を知って、メリットデメリットをきちんと把握する事が大切。
どのようなリスクマネジメントをするかは、その会社・組織に応じた適切な方法や範囲を選択する事になる。
だから資料を参考にしてどーんとは決めきれない事も多い。
そのために中小企業向けのチェックリストなどを作って配布しているようです。
また、ガイドラインは参考程度にとどめておく事も重要。ガイドラインを丸写ししてもリスク対策はできない（「知識を集約するだけではよいものは作れない」）、現場に合わせて息を吹き込む事が大事。
この辺りはプロジェクトマネジメントなどとも似ているなあと思いました。
どちらも人間が関わる、組織によって文化的背景が違う、生のもの。
最近のセキュリティ色々
興味深かったことを箇条書きに。（3部は力尽きていてメモも少なかった・・・）
- アンチウイルスソリューション
クラウド型(ソーシャル型)であれば、ゼロデイ攻撃にも対応できる可能性があるかも？！集合知。 - 標的型攻撃の判定にクラウドを使う
クラウド型(ソーシャル型)であれば、自社が狙われているのか皆狙われているかわかる。 - 結局スマートフォンもガラパゴス化している
Androidのバージョンだけじゃなく、各機種にデフォルトアプリが色々入ってるー。 - スマートフォン対策が大変だけど重要になる
クラウド系のアプリってブラウザだけじゃなくAPIもあるよね？つまりAPIやアプリのレベルでの対策を講じる必要がある。
技術が高度になった分、その辺りの対策は大事になる。
—-
自分のメモ＋当日配布いただいた資料で思い出しながら書いてみました。
こうやって、まとめてみると濃いですね。
冒頭に書いたセキュリティについての意識、これが変わったのが一番大きいです。
普段の行動の目的を考える事ができるようになった。
例示がわかりやすい
全体を通して、途中途中で出てくる例示がとてもわかりやすかったです。
例えば
「今財布の中に入っているお金が1円／10円／100円／1000円単位でわかる人？」（それぞれに手を挙げる）
「お財布の中身を1000円単位でしか把握できていない人は10円、100円がなくなってもたぶん気がつきません」
「＝セキュリティを高めるには、きちんと管理できている事が重要になります。」
という例。なるほどー！！と思いました。
おやつ
和菓子、和菓子たっぷり。
お団子も柔らかくて素敵でしたが、ここの豆大福、美味！
IT勉強会スタンプラリー
全国規模で行われている勉強会のスタンプラリー、IT勉強会スタンプラリーにせきゅぽろが参加している、ということで、記念すべき1つ目のスタンプを押しました。
北海道では、せきゅぽろ、CLR/H、LOCAL PHP部がスタンプ対象の勉強会です。
「違う勉強会に3回」か「同じ勉強会に3回」で何かもらえるみたいです。
行ったことのない勉強会ばかりだけど、スタンプを押すために参加してみようかなぁ。
面白そうな内容の勉強会があったら飛び込んでみよう、と思いました。
2012年3月31日から1年間で始まっているこの試み、次回はもっと北海道でも参加する勉強会が増えたら上位を狙えて楽しいですね！
実践アジャイルテスト読書会06 に参加しました
5月 21st
5月15日（火）に行われた、実践アジャイルテスト読書会06 に参加しました。
あっという間に2回お休みしていてびっくりした。
前々回は業務多忙で参加できず、前回はゴールデンウィーク中の開催だったため札幌にいませんでした。
（このブログを書く前になんとか休みの範囲も読み終えました。読書会があって良かった。）
気を取り直しての参加です。
今回からいよいよテストについての章に入りました。
テストの目的ごとに分類した「アジャイルテストの4象限」についての話がメインです。
アジャイルテストの4象限
テストの目的を
- チームを支援する⇔製品を批評する
- 技術面⇔ビジネス面
という2つの側面から分類し、4つに分けた物がアジャイルテストの4象限になります。
それぞれの特徴が書かれていたのをざくっとまとめてみる。
第1象限
（チームを支援する・技術面）
単体テスト。主にTDDなどで作ることになるテスト。コードに対するテスト。
コードの品質を高める、プログラマのためのテスト。
基本的にテスト実行は自動化されてなければいけない。
第2象限
（チームを支援する・ビジネス面）
機能テスト。ストーリーに対するテスト。第1象限より粒度が大きくなり、1つ1つがビジネス的な意味のかたまりになる。
ストーリーの開発が完了することを保証する、開発チームのためのテスト。
継続的ビルドの対象として自動化されているべき。
第3象限
（製品を批評する・ビジネス面）
ソフトウェアが顧客の求めるものになっているかをテストする。
ユーザー受け入れテスト、ユーザビリティテスト、探索的テスト。
創造能力と直感力が必要になる、基本的に手動で行われるテスト。
※これは実際にテストの質を（数値的に）保証するのが難しいテストだね、という話が出ました。
第4象限
（製品を批評する・技術面）
パフォーマンス、堅牢性、セキュリティなどの評価を行うテスト。
非機能要求テスト。専用のツールを使用してテストする。
アジャイルテストの4象限をチームにどのように適用するか
もちろん、全ての象限のテストを十分に実行できることが望ましいのですが、それが叶わない場合もある（時間や予算）。
その時に、何を選んでいくべきかという話。
大事なことは
「ストーリーごとに検討する前にやらないという選択をするのではなく、
全ての象限のテストについて検討した後にやらないことを決める」
こと。そのためには全象限のテストに関するスキルは必要。
また、ここで「（必要なのはわかっているけれど）やらない」という選択をするということは、技術的な負債を積み上げることになるわけです。
実際に負債が積上っていった経験談などを交えて、どうするのがよいのかなあという話をしました。
製品を長期にわたって開発、メンテナンスするかなどとの兼ね合いも考えないといけない。
コンテキストのテスト
「それぞれの組織、製品、そしてチームはそれぞれの状況があり、それぞれ必要なことがある」ということを忘れてはいけない。
コンテキスト（組織、製品、チームの流れや空気、慣習のようなもの？）意識したテスト設計が必要。
この章はなるほどなあと思いました。
製品に対するテストを機械的に行うだけではなく、プロジェクトやチームメンバーのことを考えたテストを作っていこう、とする気持ちも大事なのですね。
導入部分の読書会に参加できて良かったです。
次回からはそれぞれの象限のテストを掘り下げていきます。参加できますように！
Hokkaido.pm#7に行ってきました
5月 13th
今回はJPA様のご協力で、riywoさんが来てくれました。
まずは、みなさんお疲れまでした！
JPA++
riywoさん++
WAF再入門ということで、個人的にうれしい内容でした。
あと、捗る系（運用系）の話は新鮮でした。
Amon2（akiymさん）
相変わらず、高校生とは思えない内容でした。
最終的に、KENT WEBのBBSがplackupで動いてました。
Dancer（aloelightさん）
use Dancer;するだけ！とか、ファイルの最後にdance;とか、
オシャレだなーって思いました。
Deploymentに関するドキュメントがあるのは、個人的にありがたいです。
Mojolicious（jamadamさん）
Mojoは、ほんとにお手軽なんですね。
モジュール群をuseするとか、いろいろ便利ですね。
Ops Tools with Perl（riywoさん）
捗る系（運用系）のお話でした。
オペレーションエンジニアが抱えている作業だったり、
運用に関するお話が聴けて、すごくありがたかったです。
まとめ
WAFについては、あまりしっかりとした知識を持っていなかったので、
今回の勉強会はとてもありがたかったです。
あと、VPSを借りている以上、運用周りに関する知識は必須なので、
そういった意味で、運用系のお話はとてもありがたかったです。
あとは、手を動かして、デプロイしてですかね。
この辺は、Hokkaido.pm Casualでカバーしたいですね。
あと、自分もLTをして、音を出しました。
スライドはこちら。
それから、スープカレーですが、
最近だと、Chutta（チュッタ）かなー。
GARAKUもYellowも捨てがたいですけどね！
という訳で、今回もどうもありがとうございました！
おしまい。
釧路OSS ミニセミナー vol.2 開催します！
5月 11th
いけだです
釧路OSSコミュニティ の第2回公開ミニセミナー(無料)を行います。
当コミュニティメンバーが、
定期的に行っている勉強会の内容をベースにしたものや、
旬な題材を使って発表します。
日時：2012/05/19(土)15:00-18:00
会場：釧路市民活動センターわっと (釧路市末広町3丁目1番１号)
会費：無料
申し込み：会場に来て頂ければそれでOK！
初心者の方にもわかりやすい内容になっていますので、
ぜひ会場の わっと まで足をお運びくださいませ。
セッション内容
・15:00 – 15:45「OSSの話を何か」（仮） : さいとう(@kazuyoshi)
・15:55 – 16:35 インターネットを楽しむ為のセキュリティについて :いけだ(@tenyawanya)
・16:45 – 17:25 「スマフォとOSSを使い人生を楽しく過す７つの方法」 : おがわ
・17:35 – 18:00 LT(ライトニングトーク)＆閉会 : 釧路OSSコミュニティ参加メンバー
@T_akms @APA_Diver @yatch3455 @ya8
興味の対象の幅を広げたり、
同好の仲間を増やす機会としてもどうぞ。
懇親会も開催します。(18:30から)
懇親会への参加をご希望の方は、下記 atnd にて事前申し込みを
お願い致します。(懇親会会費：4000円)
以下はvol.1の動画アーカイブです。
http://blog.kushi.ro/kushirooss/2011/05/78/
第20回アジャイルサムライ読書会 @札幌道場 開催
5月 10th
5月8日（火）、第20回アジャイルサムライ読書会 札幌道場を開催しました。
参加者は6名。14章 TDD（テスト駆動開発）がテーマです。
ページ数が少ないので15章に入れるかなーなんて思ったけれど、関連することを話し合っていたらあっという間に時間は過ぎるものですね。
充実した時間となりました。
今回の範囲で「グっときた」ところ
意図を伝えるためにテストを書く
勉強会として
TDDはTDDBCが札幌で何度も開催されているのもあり、プラクティスとしてはかなり浸透していると思います（業務で実践できているかはともかく）。
実際に実践している人も多く、ディスカッションではTDDを実践する時の悩みや壁など具体的な問題についての話がたくさん出てきました。
特に繰り返し出てきた話題としては
- テストコードの品質を上げたい
- TDDを適用しづらい部分がある
- テストコードを書く技術がないとTDDは難しい
このあたりでした。
TDDは設計手法かどうか
本書では「TDDは設計手法として実にうまい方法じゃないか」と書かれていますが、TDDは「設計手法」として本当に有用なのかどうかという話も盛り上がりました。
- TDDを実践すれば良い設計のコードが書ける
ではなく
- TDDを実践し続けることで良い設計の仕方が身に付く・設計力が上がる
ではないかという話になりました。
TDDを実践すればすぐにうまい設計ができるわけではなく、TDDは設計の力を上げるのによい訓練方法であるという考えは忘れないようにしたいです。繰り返し身につけていくことが大事ですね。
実際に体験してみて感じるのは、ちょっとTDDをやらなくなると一気に力が落ちること。
継続していかないとすぐに衰えてしまう気がします。
TDDとBDD
「TDDとBDDの根本的な違いって何？」という話も出てきました。
色々な解釈はあるのですが
- TDD: テストコードを書くタイミングと設計するタイミングが同じ => インターフェースを決めないとテストが書けない
- BDD: 最初に振る舞い（ストーリー）だけを考え、その後コードを書く => ソースコードを書くまでにワンクッションある
という区別の仕方がしっくり来ました。
そしてその分類で考えると、RSpecはどちらかというとTDD寄りのテスティングフレームワークなのかなーという話になりました。
BDDとしても使うことができるけど（テストが自然な文章になっているから）、検証したい目的からするとTDD用のフレームワークなのかなぁと。
RSpecのサイトには以下のように書いてありました。
—–
RSpec is testing tool for the Ruby programming language. Born under the banner of Behaviour-Driven Development, it is designed to make Test-Driven Development a productive and enjoyable experience with features.
—–
(RSpecはBDDの旗印のもとに生まれたテストツールであり、TDDが生産的で楽しい経験となるような特徴を持つよう設計されています） — 翻訳はirasally
RSpecよりもさらにBDDに特化したテスティングフレームワークがCucumberであるという位置づけの理解です。
詳しいディスカッションの内容はwikiを見ていただきたいと思います。
運営の立場で
いやー、20回ですよ、20回。
途中で挫折せず、読書会を20回続けてこれたということに驚きつつほっとしています。
（20回で本書が終わっていないというのはおいておく）
これも、各回に皆様が時間を見つけて参加してくださっているからこそです。感謝。
残りあと数回ですが、ラストスパート、良い時間となるようにしていきたいと思います。
今回のディスカッションは以下のページにまとめてあります。
https://github.com/agile-samurai-ja/support/wiki/Readingagilesamuraiinsapporo20120508
いつも会場を提供していただいている弊社、今回もありがとうございます。
残り数回ですが、よろしくお願いします。
Head First JavaScript読書会 06に参加しました
5月 10th
5月7日（月）に開催されたHead First JavaScript読書会 06に参加しました。
GW明けの月曜日というハードな日程でしたが、無事、乗り切ることができました。
今回はFormのバリデーションと正規表現についてです。
Formのバリデーション
Formとは何ぞや？というところから、httpリクエストの話、httpメソッドの種類(GET, POST, PUT, DELETE, OPTIONなど)について一通りざくっとおさらいしました。
その後、Formデータの取得の仕方、バリデーションが大事な理由などについて話しました。
バリデーションの意義について、313ページには「本当に検討なアプリケーションになるとサーバー上でもデータ検証を行います」と書いてあるけれど、安全のためにはむしろサーバーサイドでデータ検証を行うべきだよなあという話をしました。
何度もサーバーとやり取りをするのもイライラするからちょっとした入力ミスを防ぐことができるよう、Javascriptの制御を入れておく、本当のデータチェックはサーバーサイドでやる、のが良い形なんじゃないだろうか。
安全のためのチェックはサーバー上で行い、クライアントサイドのバリデーションはユーザービリティ向上のために行う、というように目的を分けるという観点はとてもしっくりきました。
正規表現
本書では
- 必須チェックをしたい
- 桁数チェックもしたい
- 数字以外は入力してほしくない
- メールアドレスの形式じゃないものは受け付けたくない
というように、バリデーションのケースがだんだん複雑になってきたところで、正規表現が登場しました。
（よりによって、メールアドレスの正規表現を例に出さなくてもという話はちょっとでましたが）
Javascriptの正規表現は//で囲んで書きます。
"Hello World".match(/^\w{5}\s\w{5}$/)
---
[ 'Hello World', //マッチした
index: 0,
input: 'Hello World' ]
"Hello World".match(/^\w{7}\s\d{5}$/)
---
null // マッチしない場合はnullが返る
グルーピングは()で行うことができます
"Hello World".match(/^(\w{5})\s(\w{5})$/)
---
[ 'Hello World', // マッチした文字列
'Hello', // グループ1番目
'World', // グループ2番目
index: 0,
input: 'Hello World' ]
match関数ではなくRegExpオブジェクトを生成することもできます。
本書では自動的に生成されたRegExpオブジェクトを使う方法が載っていました。
var regex = /^\d{5}/
regex.test("12345")
正規表現はとても便利で、ある程度はできるようになっておきたいし、読めるようにしておきたい。
便利さを感じるようになってから読んだり書いたりを積極的にするようになった。
（正規表現使うたびにgoogleで量化子やメタ文字のリファレンスを探しているので、まだまだですが）
だけど、使いすぎると自分自身も後からメンテナンスが辛くなってくることがあるから、どこまで厳密にチェックするかも含めてさじ加減が大事かもしれないなぁ。
Hokkaido.cap #10 に参加してきました
4月 30th
4月27日（金）に行われたHokkaido.cap #10 に参加しました。
今回は実践パケット解析学習編・最終回。
参考文献のところに載っている他の解析ツールについて勉強しました。
知らないツールばかりだったので新しい発見がたくさんありました。
様々な解析ツール
パケットを解析することができるツールは、使い方によってはクラッキングツールになる、とても危険な道具です。諸刃の剣。
なので、参考文献に載っているツール群も、ウイルス対策ソフトによって「危険なサイト」としてダウンロードページがブロックされることも多いようです。
たしかに、強力なことができるほど便利だけど、その分、悪用した時にも便利に使えるのですよね。
もちろん、クラッキングツールだけではなく、疑似パケットを作成するパケットジェネレーターや、動かしていると”なんかかっこいい”ツールなどもありました。
標準的なネットワークモニタ
よく使用するネットワークモニタツールとしてtcpdump、Microsoft Network Monitor 3、TCPView、NetworkMinorが紹介されました。tcpdumpはギリギリしっていたけれど、他は使ったことはなかったです。
こういうツールを業務で使うことはあまりないけれど、こういうツールがあると知っておくことは大事だなと思いました。
ネットワークは解析すれば簡単に見える物であるということを忘れないようにしないと。
とても大事なこと
許可なく他人の通信をキャプチャしたらダメ、絶対。 犯罪です。（有線電気通信法、電波法）
また、パケット解析の技術は、トラブルシューティングなどを通じて、自分の経験として身につけることが大事であるという話もありました。
この辺りは「コードを書かないとプログラミングの技術は向上しない」のととても似ているなー。
何事も手を動かして、体験して身につけていく物なのですよね。
CTF
パケット解析を題材にしたクイズにチャレンジしました。北海道で有名なあの人のプライベート写真がゲットできるチャンスです。
張り切って挑戦したものの、Hokkaido.capへの参加が2回空いてしまっていたというのもあり、Wiresharkの使い方をすっかり忘れていました・・・ぐぬぬ・・・
しかし、それでもなんとかそれっぽいキーワードを探して、時間内に画像をゲットすることができました。
最後に答え合わせをしたところ、やっぱり無駄なことをたくさんやっていたなあ。
そして答えの近くでグルグル回っていたなあ。
Wiresharkを使いこなせばもう少し楽にできたところを、力技で解いてしまった感は否めない。
Hokkaido.cap は実践パケット解析が一段落したということで、今後は不定期開催になります。
普段の業務で直接的に使うことはあまりないのだけど、いろんな知識を広げるためにも、また次回参加したいと思います 
第19回アジャイルサムライ読書会 @札幌道場 開催
4月 26th
4月24日（火）、第19回アジャイルサムライ読書会 札幌道場を開催しました。
参加者は5名。リファクタリングについてです。
今回は、会場に「リファクタリング―プログラムの体質改善テクニック」を持ってきていただき(@shuji_w6eさんありがとうございます！）一部はこの本を使って内容を補いながら進めていきました。
今回の範囲で「グっときた」ところ
コードを書くことは、良い文章を書くことにとてもよく似ている
一日を通じてたゆまず、継続的にリファクタリングする
「コードを書くことは、良い文章を書くことにとてもよく似ている」は、すごく自分のなかでしっくり来た文章でした。
ちゃんと説明できないことはちゃんとコードに落とせない、だからまず、きちんと人に説明できるようになりたい、そう思います。
勉強会として
この辺りは、本のページ数が少なくエッセンスしか載っていないので、文中でも「読むべき」とされている本と一緒に読み進めるというのはとてもよい試みだったなと思いました。
「リファクタリング―プログラムの体質改善テクニック」はまだ持っておらず、きちんと読んだことがありません。
今回の話を聞いて「優先度：最高」になりました。
また、そこから発展して、押さえておくべき・読んでおくべき本というのをみんなで話すことができたのも、とても良かったです。
リファクタリングについては、コードを良くしたいという気持ちを持ち続けることが大切だなあと思いました。「継続的に」「たゆまず」です。
楽をしようとしてさぼると後が辛くなる。きちんと書いておくと後で劇的に楽になることがある。
そういう経験も含めて、使い捨てにならないコードを書いていきたいです。
今回、実際にリファクタリングを行っているページのコードをみんなで追いながら話をしたのですが、これが結構楽しかったです。
ぐちゃぐちゃのコードをペアプロしながらリファクタリングするようなワークショップ、面白そうだなあ。
運営の立場で
この部になってからページ数が少なめなので、1回1章と決めて進めています。
テーマが明確になっているので、話がしやすいなと感じます。
脱線しても大きなテーマから外れることがなく、また、脱線よりもさらに深い話をする方が増えてきたような気がします。
（ディスカッションのwikiをみてもその辺りがわかると思います）
プラクティスに関するところはこの進め方が適しているような気がしてます。
個人的にも別の本を一緒に読みながら深くを知りつつ進めていける今回の方法はとても勉強になりました。（今後の課題がよく見える）
残り少ないですがプラクティスの部はこの感じで進めていこう。
今回のディスカッションのwikiは以下にまとめてあります。
https://github.com/agile-samurai-ja/support/wiki/Readingagilesamuraiinsapporo20120424
話題になった著書は全てリンク付きで載せておきました。
忘れているのあったら追記お願いします。
最後に、いつもいつも場所を提供してくれる弊社に感謝。
次回もよろしくお願いします。
Head First JavaScript読書会 05に参加しました
4月 26th
4月23日（月）に開催されたHead First JavaScript読書会 05に参加しました。
04は旅の疲れからお休みし、1回あけての参加。
毎回進むページ数は多いのですが、本自体がとても読みやすいので、追いつくことができました。よかった。
今回は「関数」です。
Javascriptの関数は、知れば知るほど奥が深いのですが、この本ではその導入編を扱っています。
スクリプトから関数へ
ただのコード行を関数にしようとするとき、最初は結構つまづいたなあと思い出しました。
コードから関数を抽出できない、というのには色々段階があると思います。
- そもそも、何をする処理なのかわかっていない
- コードを理解していない
という、「もっとがんばりましょう」という段階。
- 重複や同じ処理をしている、というのが見えない
- 処理をかたまりに分けて考えることができない
という、「がんばりましょう」という段階。
読書会の時にも話をしたのですが、この段階の時に大事になるのは「IN/OUT」を意識することじゃないかな、と思います。
何かをもらって、何かを返す。
もらうもの、返すものの値が違っても種類が同じであれば同じ働きをしている -> 関数として抜き出すことができる！ と形が見えやすくなってくると思います。
ここを乗り越えて感覚をつかめてきたら、その先の成長曲線は一気に上がるのではないかなー。
関数定義の方法いろいろ
次のコードはどちらも関数を定義しています。
＜functionで定義＞
hoge(); // ---(1)
function hoge() {
alert('hoge');
}
＜変数に無名関数を代入＞
huga(); // ---(2)
var huga = function(){
alert('hoge');
}
どちらも関数なのですが、定義されるタイミングが異なります。
なので(1)は実行できるけど、(2)はエラーになる（関数の巻き上げ）。
あと、無名関数として定義しておく（huga) と他の変数で参照できたりできる。
読書会で出てきたよい例示を忘れてしまいました・・・・ここ苦手。
コールバック関数
Ajax関連のコールバックは後半で出でくるのでここは主にwindowのイベント処理の話。
イベントハンドラを使うか、windowsオブジェクトのイベントに関数参照をさせるか、どっちをよく使うか、という話をしました。
＜jsファイル＞
var changeHoge = function{ alser('change!');}
window.getElemntById('huga').onclick = changeHoge
＜htmlファイル＞
<button id='huga' onclick='changeHoge()'>
これは、こっちであるべき、というよりは作っているプロダクトによって適した方があるのではないかなーと思いました。
あとはどのイベントか。onloadなどであればjsファイルに書いてあってもいいけど、onclickなどはhtmlソースから追えた方が便利かなと思いました。
こんな感じで初学者向けの本ですが突然深い話をしたりしています。
家で復習をする時に、読書会で出てきたサンプルコードを参照したいのでPCを持参しようと思うのですが、本が重すぎて実行に至っていません。
次回も楽しみです。
Hokkaido.pm Casual#0に行ってきました
4月 19th
はじめて勉強会を開催しました。
みなさん、おつかれさまでした！
とりあえず、懇親会が行えたのでホッとしております。
せっかく、小銭を多く用意したはずだったのですが、
最初の会場の支払いで使ってしまったのが敗因でした。
という訳で、Hokkaido.pm Casual#0を開催しました。
みんなでLT大会をした訳ですが、どうだったでしょうか？
ビギナーズセッションとか、あんな感じですかね。
ぶっちゃけ、メンツ相応の内容だった気がします。
次回は、もっとカジュアルにと考えていますが、
カジュアルな課題を出すところから考える必要がありそうです。
まず、これを読むところから。
はてな教科書
それと、今回作ったスライド。
5分で作るLT資料
参加して頂いた皆様には、感謝しております。
ありがとうございました！！
あと、飛行機に乗って、@Yappoさんが来てくれました。
遠方から、ありがとうございました！！
スープカレーですが、以下の通り。
プルプルで納豆スープカレー
レゴンでふわふわオムレツとスープカレー
奥芝商店でエビスープ
あとは、GARAKU, yellow, ZORAあたりがオーソドックスでオススメです。
個人的には、レゴンのオムレツ（オプションでライスに卵を乗せる）がオススメです。
おしまい。