第６回目 2013.12.13
漢とはなんぞや…。
かつて万針房で三号生の独眼鉄先輩は問いかけました。
全ての漢がこの問いかけに明確な回答を見いだせないまま、時は流れ、草食系等という言葉も最早、定着してしまった2013年冬…。
我がTBKにて、漢のDB講座 〜設計編〜 が開催されるに至りました。
今回参加した精鋭は３名（>_<）
う〜ん…。師走の寒さが身にしみます…。
ただ、この寒さも吹き飛ばすほど、熱く、汗臭いプレゼンが開始されるのでありました。
プレゼンの概要は以下
1.データベースとは
2.リレーションとは
3.設計手法とは
4.キーとは
5.正規形とは
6.質疑応答
7.演習
データベースはデータを格納するものって目線であれば、どんな形態でも良いんですが、
無駄なく効率的にかつ効果的に格納する場合、正しいルールに則って行わないと、
後々、問題が発生します。
時間が経てば、そのBADノウハウがローカルルールになり、
そのローカルルールしか知らないモンスターが産み落とされ、
さらに悪循環に陥ることもしばしば…。
そんな不幸の連鎖を断ち切るそんな大義名分を抱えながら、
会は進んでいきました（？）
そして、86枚のスライドが漢を感じる資料のもと
活発な（？）意見も多くいただき、
レゼン資料にも沢山突っ込みをいただきました。
感謝です。
アップしたファイルはその辺は修正したものを配置しております。
質疑や意見が出たものをチョイスします。
Q1.
キーの値が変わる場合が多々ありますが、こういう場合はどうしたら良いでしょうか？
A1.
リレーショナルモデルの厳密性から言えば、変化しうる値をキーとした時点で、設計の誤りです。
数値など変化がないものをキーとして設定しましょう。
Q2.
マテリアライズドビューをは何でしょうか？
A2.
ビューが実体を伴わない仮想的なテーブルであるのに対して、マテリアライズドビューはテーブルを保持するものです。
自動作成されるワークテーブルと考えると分かりやすいかもしれません。
更新されるタイミングは任意で変更可能です。
Q3.
クエリーリライト機能とは何でしょうか？
A3.
Oeacle Enterprise Editionに搭載されている、SQL（クエリー）の読み替え機能です。
設定しておく事で、Oracleのオプティマイザがより高速な実行になる、有効なマテリアライズドビューがあれば、
プログラムのSQLを修正する事なく自動的にそのマテリアライズドビューを参照してくれます。
（補足）
クエリー・リライト - オラクル・Oracleをマスターするための基本と仕組み
Q4.
NoSQLって何ですか？
A4.
（サンプルとしてキーバリューストア型で）
行指向とも言われますが、キーとなる項目を特定して、CSVのようなカンマ区切りで残りの項目が入っているイメージです。
これは大量データを取り扱うときにRDBでは速度に難があるため、作られたモノです。
※リレーショナルモデルでは非正規形
高速に表示される反面、リレーショナルモデルにあるAトランザクションACID特性を犠牲にしている場合があります。
…説明下手のため、以下に補足
演習については、皆さん業務でDB操作経験も豊富なため、割とすんなり…。
一応、スーパータイプ／サブタイプ問題をチョイスしたのですが、簡単すぎたかもしれませんね。
と言った感じで、漢臭い会は終了しました。
今回一番言いたかったのは
『引き出しを多く持つ！』
ってことです。
独眼鉄先輩こんな回答でいかがでしょうかｗｗｗ
次回は１月１０日かも…。
第５回目
みなさんこんばんは。前回に引き続き、Ｆ田です。
前回は「色々なWeb APIを利用して、地図に印をつけてみよう」という宿題が出て終了しました。
さぁ、みなさん、ちゃんと宿題をやってきましたか？
因みに、Ｆ田は挫折しました・・・
「ダメだ・・・考えることを放棄している・・・」
正解その通り！だって「考えることが・・・怖いんだ！」もの。
という、どうでもいい言い訳は置いておきまして、宿題をきちんとやってきたのは、ボスも含めて２名！
しかし、さすが御両方！PHPに関して「echo」しか知らないＦ田とは違って、とても勉強になるソースを書いてきて下さいました。
そのサンプルソースを使って、具体的な処理の解説。その前に、生意気にもＦ田が「xmlHttpRequestとは、Levelが二つありまして・・・」なんて、偉そうに説明をしましたが、その部分は割愛！『xmlHttpRequest クロスドメイン』などで検索すると、より分かり易く説明してくれている方々があふれているので、そちらをご覧頂ければ、と思います。
というわけで、お二方のサンプルソースを見ながら、ご本人に解説して頂きました。結果は同じなのに、そこに至るまでの処理の記述が微妙に異なる。これがプログラミングの醍醐味ですね！
そんな中、ちょっと話題に挙がったのが、いわゆる「アフィリエイト」！日本語で言うと「成果報酬型広告」だそうです。直接TBKと関連は無いのですが、Ｆ田は今回初めて知りました。そんなおいしい物があるんですね。
そして、「Mashup Awards」について。様々なWebAPIを駆使して作成したWebアプリのコンテストです。今回は９回目だそうで、作品の応募は既に締め切られています。次回の開催時に、応募できたらいいですね。こうした目標があると、モチベーションも上がります！！
と、色々話が盛り上がって今回は終了。プログラムのソースとかが出てくると、一気に勉強会っぽくなった気がします。
また、Ｆ田は今回も世の中の凄さに驚かされました。本当に勉強になります。
さ～て、次回のTBKは・・・
「ボスによる『漢のＤＢ講座』」です！
全３部作（予定）の第１部です！果たして、物語はどのような幕開けを迎えるのか、乞うご期待！というわけで次回も、サービスサービス～！
最後に、今回のTBKで使用させて頂いたプログラムのソースはウプして頂きましたので、勉強の参考に是非活用しましょう！
以上、Ｆ田でした！！
第4回目
こんにちわ！今回のブログはわたくし「F田」が書かせていただきます！
21013年10月11日、わたくしを司会者として、第四回の勉強会を開催致しました。
当日は、業務の都合などにより参加者が激減！
いつもとは違う会場に一人で向かうことになってしまいました。こんなこと全く想定していなかったので、かなり焦りましたよ！
いきなり路線を間違えたり(正確には誤情報を流されたのですが・・・)しながらも、どうにか会場に到着！結局、5分程の遅刻をしてしまいました。
さてさて、そんな感じで始まった今回の勉強会。参加者は五名。
テーマは「Webシステムのレイアウトを決めよう！」
正直、ほとんど前準備らしい準備を行わずに行き当たりばったり的な感じでしたので、のっけからぼろぼろ。
しかし、参加者の皆様のお力添えによりどうにかこうにか進行。
というわけで、「レイアウトを決めよう！」から、「色んなWebページが提供しているAPIを知ろう！」てな感じの話へ。
本当に驚きました！世の中には便利なサービスがあふれているんですね。もう材料は揃いきっているので、あとはそれをどう組み合わせて物を作るかだけ、って感じです。
今回使ってみましょ、という話になったのは
・駅の位置情報を教えてくれるサービス
・位置情報を入れると周辺のお店情報を提供してくれるサービス
・指定の位置にマークを付けて地図を表示してくれるサービス
これらを組み合わせれば・・・おぅ！なかなかいい感じのが出来そうではないですか！
更に、見た目のいいページを作るためのCSS集とかも世の中にはごろごろ存在しているようですし、もう自分で考えるというより、そういった情報をどこまでうまく使いこなせるかにかかっている感じですね。情報化社会恐るべし・・・
というわけで、なんだかんだで時は過ぎ、今回の勉強会は無事に終了。
次回までに、上記のサービスを使って、実際に動くページを作ってみましょうよ、という話になりました。駅を指定すると、周辺のお店の位置を地図上に表示してくれる、みたいなページですね。
駅名のチェックや曖昧検索は置いといて、とりあえずはドロップダウンリストから駅を選択させるインターウェースで実現を試みてみましょう！
そんな訳で、次回までの宿題が出されて第四回の勉強会は閉幕！
次回の司会者は・・・
因に、たいへん私事ですが、昨日「iPad2」を購入いたしました。
正規整備品でけっこうお得な感じでゲットです。で、このブログもそれで書き込もうとしたのですが・・・なんか色々手こずって入力不可！！結局諦めて、最近ご機嫌斜めのiMac君をどうにかなだめて、そちらで書き込みました。やっぱり新しいPCを購入しないとな・・・
PHPカンファレンスに行ってきた
さて、このたび、PHPカンファレンス2013に初参加してきました。
PHPカンファレンスは国内最大規模のPHPイベントで、Word PressのイベントWord Camp2013とも共同で行われてて、メイン会場入り口にはたくさんのブースが立ち並び、飲料水の提供やら書籍紹介やらプレゼントなんかもありました。
この日は、安全なWebアプリケーションの作り方の著者の徳丸 浩氏の講演をメインに他の講演を聞いて回ろうかなとのプランを立てていました。
最初はメインステージでPHP基調講演PHPの「今とこれかから」を拝聴。
Webスクリプト言語としてのPHPの人気ぶりや改めてWord Pressの影響の高さを感じました。Word Pressというキラーコンテンツの出現により身近になりましたので、暫くはWebの界隈ではPHPが主流であり続けるかもしれませんね。
そして、会場を移動し、PHP初心者セッションを聞きました。
若い方々が多いなか、おっさん一生懸命聞き入ってます。
PHPのフレームワークは豊富なので、自分のインスピレーションで決めればいいって言っていたのはなるほどって感じですね。
まず、やってみないとどれが良いか、自分に合うかって基準が出来ないと思うんですよね。基準を作ってそれよりよいモノがあればそれを使えば良いんですよね。
って間に、徳丸講演の時間に…。
かなりの人気講演で立ち見の人も多かったです。
PHPのライフサイクルとの向き合い方やPHPでのセッションフィクセイションやパスワードの防衛方法、そしてHTML５でのセキュリティ対策等をデモを交えての講演になり、最後は駆け足になってしまっていましたが、改めて、ただ作っておしまいってのでは無く、セキュリティ対策も含めた運用面が大事だなと気づかされました。
他に、JavaScriptMVCやPHPで稼ぐにはとかGoogleを交えたパネルディスカッションとかを聞いていましたが、Web APIの活用の講演があり、そこで色々なWeb APIの紹介があり、ちょっとTwilioというKDDIが提供しているサービスが気になっています。
このTwilioはWeb経由で簡単に電話をかけたり、SMSだったりってのができるようで、なにか面白いサービスが出来そうですね。
専門の講演もあったようで、ここら辺のUstreamにのってますので、
近々、勉強会でも取り上げてみたいですね。
てか、知っていれば見に行きたかったっす…orz
そんなこんなで、最後のライトニングトークは聞かずに撤収。
事前にもうちょっと調べていけば良かったかなってのと、もうちょっと技術的な面の講演を聞けば良かったかなと反省。
聞きたい講演がバッティングしてる場合もあったし…。
でも、初参戦でしたが、なかなか楽しめたと思います。
来年も可能な限り参加しようっと。
第三回目 2013.09.13
三回目となった勉強会。
今回は趣向を変えてというか、司会を変えて行いました。
もともと、持ち回り性で行いたいなって思ってましたしね。
今回のテーマ、議題は司会者の方におましました。
んで、議題は
「OAuth認証について」
「見積、契約で失敗しないために…」
になりました。
まず、OAuth認証について。
最近のWebサービスやログインを伴うアプリケーションにはほとんど実装されていますし、大規模なサービスを提供しているサービスにはOAuth認証APIを提供しています。
ユーザ管理の煩わしさが軽減されるのと、ユーザにとってもいちいちユーザ情報を入力する必要も無く便利になりますね。
実装の方法等の説明を交えながら、質疑へ…。
質疑では、便利さの裏側にあるいわゆるセキュリティの問題が議論になりました。
…てか、問題にしちゃいました（笑）
一時期OAuth認証での漏洩なんかも問題になりましたしね。
まあ、漏洩が発生したのはOAuth1.0ってバージョンで2.0ではだいぶ強化されていること、トークンっていう認証情報は有効期限が決められるっていうことのようで、セキュリティ面も年々強化されているみたいですね。
またひとつ勉強になりました。
続いて、見積、契約で失敗しないために…というテーマで何個か事例を出して、ディスカッションを行いました。
【事例１】
Accessの生産管理システム
・バージョンアップ
・SQLServerリプレイス
・新機能追加
・一部不具合修正
旧システムの仕様をさらっと確認したSEが見積もりを出し受注。納期ぎりぎりになり要員がいない状況。仕方がないので、設計書なしで製造したが、テスト時に旧システムがバグだらけ！と気づく。旧システムのバグも修正するはめになったが、納期が迫り、必須機能を先に段階的に納品し、一方で新規機能を平行開発する。納品後に追加要望あり軽微であったため、修正を行ったが、新規機能の開発が遅れ、検収されずグダグダ。
結果、大赤字。
う〜ん、よくある炎上プロジェクトですな（笑）
どこに問題があったのでしょうか？
司会者氏は設計を端折ったのと期間が短かったのが敗因とおっしゃりました。
はい、ここで私がいつも通り噛み付きます（笑）
期間が短いのが失敗の原因であり、期間が長ければ炎上せずに済んだか？
期間が長ければそれだけ人件費がかかりますね。納期というスケジュールは守れたかもしれませんが、赤字を回避出来たかは…。
私も含め、エンジニアってのは見積もりって言えば工数、スケジュールに視点が行きがちではありますが、会社やプロジェクトとしては見積もり工数をオーバーしていても、損益分岐点を下回っていなければ、まあ、赤字ではないですよね。
１エンジニアにはなかなか難しいことかもしれませんが、やはり原価をある程度把握出来ることって大事じゃないのかなと思ってます。
単価って原価＋マージンですよね。通常はその単価にそって工数を算出します。
もちろん、非生産部門給与や会社の備品のような経費も関わってくるので、こういった単価について考えるのは経営部門の話なんですけど…。
でも、仮に１人月（１６０時間）の仕事を、１ヶ月定時内で終わらせたのと、残業や休日出勤で半月で仕上げた場合、エンジニア的には後者の方をよくやったって言いがちですが、儲けとしては時間外手当分、損してますよね。
ここら辺くらいは考えても良いのではないかと思ってます。
さてさて、ここらで議論は工数についてのお話になっていきました。
工数を見積もる場合、みなさんどうしてますか？
通常は順調にいった場合の工数＋リスクって言うので出していると思うんっすよね。
ただ、こういったのって、経験則に基づくってのが多いじゃないですか。
仕様が大雑把な場合は経験則ってのでしか工数を出しようがないのは事実ですね。
リスクがどこにあるのか、この顧客はコロコロ仕様を変更があるとか、この技術はこういった箇所がネックになるとか…
経験でしか分かりません。それを定量的に把握するためには、キックオフ、進捗会議、反省会ってのが大事ではないかと思ってます。こういった場で、予定オーバーした要因を把握することで次ぎに活かせるのではないかなと。
ただ、そのPMやPLの頭にだけあるのではなく、しっかりドキュメント化していくことで、次のPM、PLの失敗を軽減できると思ってます。
【事例２】
AccessからWebシステムへのリプレイス。
要件定義を作成する。この工数は最終的に製造見積もりに乗せるし、 失注時は要件分は請求可 （何と！！）。
ユーザは「金額高杉ワロタwww」って状態。
契約もままならなくなったので、次回からの案件では要件定義って内容で契約することって上司から言われた。
要件定義の工数ってどう出せばいいでしょうかね？
ここら辺で時間がなくなったので、だいぶ駆け足になりました。
わたしも、とりあえず意見だけ述べるに集中（笑）
要件定義の工数って確かに難しいですよね。
製造のような積み上げるべき具体的なものもないですし。
個人的にはプロジェクト全体のスケジュールから割ける時間を割り出すしかないと思うんですよね。
そんなこんなで時間が来て終了。
う〜ん、ちょっと不完全燃焼ぎみ。
わたくしが自分の意見を述べすぎたかと反省…。
でも、見積もりって様々な人間模様が入り交じったものですし、
もっと深く掘り下げても良いかもしれませんね。
また題材としても面白いと思います。
司会者氏の感想
人の意見を引き出すことが難しかった。もうちょっと人の意見を引き出せるような発表を出来るようにしたい。
との事でした。
さて次回は誰かやりたいって人いないっすかね？
第二回目 2013.08.09
勉強会も第２回目を無事迎えることができました。
なかなか、業務とか家庭の事情でフェードアウトしちゃいがちでなので、継続性が何より難しい。
だから、毎月第二金曜日にしたのもスケジュールを合わせやすいためで、来れない人にはこういうブログで開催報告をすることでフォローしていこうとしてます。読んでる人少ないですけど…。
さてさて、第２回目の内容としては、前回の宿題と開発環境の統一、サービス内容のディスカッションって感じで進んでいきました。
前回の宿題になっていた、今後の進め方はアンケートを取ってみて少ない回答数ながら、『役割分担を決めないで、全員で同時にやっていこう』ってことになりました。
そこで、大事なのは、開発していく環境を揃えないとってこと。
まあ、バージョンが違えば動きがかわってくるし、各々バラバラに環境作っていっても最終的なリリース時にトラブルになりますからね。
独断と偏見でPHP5.4とMySQL5.6を選択し、そしてIDEはEclipse PDTに決定しました。
EclipseやMySQLをデモを交えて紹介をして、導入は各自実施することにしました。
誰か導入で躓いてくれると、そこからナレッジが溜まったりするんですけどね（笑）
各自ノートPCとかを持ってきて、その場で手を動かしながら作業出来れば理想なんだけどなあ…。
んで、続いてはサービス内容を決めましょってことでディスカッションを始めました。
うーん…。
なかなか皆さん具体的なものが見えていないのか最初のうちは私に質問をする流れ。
いやいや、みんなで決めるんだから「こうしたい」「こういうのを作りたい」って意見が欲しいんだけどって思ってたけど…。
でも、時間が経つにつれて皆さん色々意見が出てきました。
こうした仕様を決めたりってのが、皆さん好きなんでしょうか？
飲み屋だけじゃなくてもとか、グループはこういう単位がとか…
最後の方は多いに盛り上がりましたね。
決まったサービス内容は↓こんな感じ。
・ログイン機能
・アカウント作成：匿名性、メアド程度で登録、アイコン設定、よく行く場所（生息地）を登録
・グループ作成：オーナー承認、グループメンバー承認、フリー
・コメント：パブリック、グループ、プライベートのカテゴリわけ、そこに「いきたい」「いかれた」のステータス分け
・地図表示：地域単位でコメント件数表示、詳細にすればコメント内容が分かる（大島てるのイメージ）
・評価制度
・ランキング制度
なかなか面白いかもしれません。
こういった流れから、スマートフォンアプリとかデータ解析（ビッグデータ）とかの技術を学んでいけたら楽しいでしょうね。（自分だけかもしれませんが…）
次回は具体的な仕様を決めていこうかと思ってますが、技術的なことも織り交ぜた方が勉強会的かな？とも思いつつ。
次回の司会は別の人にしようっと（笑）
AWSハンズオンに行ってきた
AWSのハンズオン（体験学習）に２名で参加してきました。
場所は目黒のAmazon Japan本社…
いや〜、外観、内観とも小洒落てます。
雰囲気に飲まれそうですが、こういった体験をできるのも貴重ですね。
飲みの席でのネタにもなります（笑）
さてさて、今回受講してきたのは「セキュア＆スケーラブルウェブサービス構築」
セミナーは、WordPressを題材にして、閉じられたネットワークと外部からのアクセス（早い話がファイアーウォール）の設定方法やトラフィックが増えた場合の拡張の仕方…
（WordPressはphp+MySQLがセットなので）アプリケーションとデータベースを分離させたり、アプリケーションサーバを増設し、ロードバランサーを設定する方法などなど
…を、実際に自分の手で構築していく流れで進んで行きました。
具体的なサービスを題材にしながら、シナリオに沿って行っていったので実運用も想定できて非常に有意義でした。
が、時間はちょっと足りなかったかな？？って感じもしました（笑）
改めてクラウド（と言うか、AWS）って便利だなと実感したし、また、システムアーキテクチャの学習にもなるかなとも思いました。
こう見えて？、一応、SIer的なこともやってるので、今後こういった技術や手法を知っているか否かでお客さんに提案する内容も違ってくるのかなと…。
改めて、AWSを勉強会の題材にして良かったなと痛感した、そんな雨上がりの目黒の夜でした…。
う〜ん。AWS恐るべし・・・。
この体験を踏まえて、次回の会のアジェンダを考えようっと。
