そんなに難しくなかったけど、英語は不得意なので、備忘録として書いておこう。

準備

下記、URLでSignUpします。

https://developers.google.com/bigquery/

ここの 「Sign Up」をクリック

ここの「Google APIs Console.」をクリック

※私は既に google アカウントがあり、カードも登録していました。

Serviceｓをクリックして、「BigQuery API」を「ON」に変更

Teamは、わからないので飛ばしました。

API Access では、プロジェクト名とか、ロゴを設定してみました。

ここではClientIDを作成します。

• Web application
• Service account
• Installed application

とあるようですが、とりあえずWeb から使ってみたかったので、Web application で作成しました。アプリを作る時には、気にしないといけないですね。

Billingで「Checkout」します。利用するデータサイズにもよるようですが、金額は ＄０ でした。

これで、利用出来るようになったようです。

使ってみる

では、テーブルを作ったり、データを入れてみます。

最初に開いたページに戻ります。 https://developers.google.com/bigquery/

ここの「BigQuery Browser Tool」をクリックします。

※ https://developers.google.com/bigquery/docs/hello_bigquery_gui#setup

ここの「Open the BigQuery browser tool. 」をクリックします。

※ https://bigquery.cloud.google.com/ いきなり、ここをアクセスしても良かった。

テーブルの作り方

「dataset」「table」「schema」の順で作成します。

「API project」右の「▼」をクリックし、「Create dataset」をクリックします。

「Dataset ID」を入力し、OKをクリック。※例 「sample_dataset」としました。

「（Dataset ID)」の右の「＋」をクリックします。

「Table ID」 ※「sampleTable」としました。

「Schema」 ※「id,name,group,flg,count1,count2,money1,money2」としました。複数カラムとする為、カンマで区切ります。

「File upload」※下記のCSVファイルを用意し、選択しました。

「OK」をクリックし、「Job history」を見ると、

上記のように「Load」中である事がわかります。

「sampleTable」を見るとテーブルが作成され、データが入りました。

上部の「Query Table」をクリックすれば、SQL文を実行する事もできます。

とりあえず、提供ツールの使い方でした。

実際はアプリから使用するので、Keyの埋め込みや各APIを使用して、テーブルを作ったり、データの入出力を行う事になります。

例えば、売上データや在庫データ等を連携するアプリを構築し自動連携するのはさほど難しくないでしょう。 あとは、分析担当者が使用するアプリでしょうか、左最近の担当者の中にはSQL文を書ける人もいるので、データ連携だけで事足りるかもしれませんね。

いわゆる、在庫管理、原価管理、検品管理の問題、情報共有と問題点は多岐にわたる。実業務（基幹業務）を考えると、営業と生産からくる短納期の課題や、自社外製造の品質管理（検品）が売上を伸ばすという意味では近い課題だろう。

この辺はITCとして考えるとして、見え隠れするのが、営業、製造の分析業務が気になる。分析業務は中小の場合、Excel、大手の場合はDWHを使用する。コストをかけづらい分野である事と、分析技術やソフトを使用するのに教育が伴う。

在庫管理も隅に追いやれるのは、やりたい事とコストの差が大きいからだろう。在庫管理は全ての単品情報を必要とする。受注（売上）、発注、仕入、出荷（売上）、物流、棚卸とこれらの日付情報を加味して、現在の帳簿在庫を計算する。流通系なら、昨年度の売上実績による傾向、製造系なら今の在庫より、来週や来月の帳簿在庫が必要になる。売上予測を外したら、発注をキャンセルされたら、今、あるいは、来月かかえる不良在庫はどうなるのか。

ながなが書いてしまったが、分析と在庫は安価なクラウドサービスを利用して大量データを如何に集計するか、もう一つ情シスのデータバックアップとして複数業務の隠れた要求として求められているだろう。

※ 開発コストがかかっては本末転倒だが。。。

• 数値は外部、マスタは内部で管理する事により、情報漏えいを防ぐ
• 外部の数値は全て int 型（bigint含む）とする事で、システム的に防ぐ
• データベース名、テーブル名、カラム名は全て自動採番による番号とする事で、何の情報かわからない。

実装方式

• クライアント（利用者PC）では、マスタテーブル、DWHテーブルVIEW、分析用VIEWの３つを管理
• データベースは、UNIX版、Window版を考慮し、mysql を選定
• mysql spider を使用してマルチデータベースを統合
• テーブルはカラム毎に作成し、マルチサーバに分散連携、統合はクライアントのDWHテーブルVIEWで実現する。

create view uriage select a.val as uriage,b.val as kyakusuu from serverA a,severB b where a.id = b.id

• DWHテーブルVIEWを使用して、分析用VIEWは利用者が作成する。
• 性能要件を満たすか確認

課題

• クライアントにmysqlをインストールする必要がある
• CSVアップロードとVIEW作成機能を実装
• 分析用VIEW作成のサポート
• 構築プログラムを何で作成するか。PHP、java、html5(Web SQL Database)、Google Big Queryの選択もありか？

ZABBIXは監視だから社内メールを使用している。一方、社内をGoogle Appsに変えた。

Google Appsは社内のようで、実際は社外にあります。という事は、社外にメールを飛ばす設定が必要です。　特に社内メールサーバを撤去する場合は、なおさらです。

社外にメールを出すには、

①会社のグローバルIPを正規なものにしなくてはならない。

メールはフィッシング詐欺とかあるので、メールを送信するサーバが存在するかとか、誰のものかが、わからなければなりません。

DNSにMXレコードが必要になります。ZABBIXは送信だけなので、AレコードとTXTレコードを設定しました。

②ZABBIXサーバをメール送信サーバ(SMTPサーバ）にする。

Postfixの場合、/etc/postfix/main.cf の下記設定を変更します。

myhostname = smtp.acc-s.com

mydomain = acc-s.com

※うちの acc-s.com の場合で、Aレコード、TXTレコードは、smtp.acc-s.com に対して行います。※これはサンプルです。

DNSと同じ名前を登録します。これで、このサーバは正規のサーバである証明になります。

あと、メールサーバなので、ユーザも登録します。

ZABBIXから送信する送信先アドレスを/etc/aliasに転送として登録しました。

kei1: kei1@acc-s.com
kei2: kei2@ezweb.ne.jp
# postalias /etc/aliases
# newaliases

③GoogleAppsにMXレコードを設定する。

http://support.google.com/a/bin/answer.py?hl=ja&answer=33352

※今回、これはやりませんでした。

違いは、会社のグローバルIPがメールサーバ(smtp)になるか、google Appsがメールサーバ(smtp)になるかです。Google Apps がメールサーバの場合、ユーザ登録はGoogle Appsで行います。ユーザ管理という視点からするとやった方がいいでしょう。

④ZABBIXの設定

③をやらなかったので、ZABBIXのサンプルに近い、下記にしています。

SMTPサーバ：localhost

SNTP helo：localhost

送信元メールアドレス：zabbix@acc-s.com

③をやった場合は、③でgoogle Appsのsmtpサーバがわかるので、そちらにすると思います。

最後に

FWにローカルからグローバルにでる25ポートの穴が開いている必要があります。

FWから外にでる場合、ローカルIPからグローバルIPにNAT変換がされている必要があります。

「ネゴる」ってなんでしょう。

• 時間を短縮
• 手戻りを防ぐ
• 手を抜く
• 後まわし

開発コストって、私の場合だいたいこういう風に考えてます。

• 要件定義　１０％
• 基本設計　２０％
• 詳細、PG、単体テスト　４０％
• 結合テスト　２０％
• 総合テスト　１０％

ひどい、という話もあるかもしれませんね。　そののち、仕様変更はいつまで発生するでしょう。

これも、経験上、総合テストまで！？　総合テストで発生する仕様変更って一番厄介です。どうでも、いいことは捨て去られますが、このタイミングで見つかるのは、大きな問題、インパクトのある問題だからです。企業側も理解していて、初期開発を抑え、仕様変更に予算をとっていたり、総合テストから半年後にリリースするといった方策をとっているところも、あります。

ネゴるは、この総合テストでの仕様変更に備えての方策です。

たいした仕様でない事が重要であったり、総合テストで、もめて余計な時間とコストを掛けない事が肝心だと思います。

信頼関係はどうやって、築くのか。

ネゴるには、もっとも肝心な事ですよね。PMの懐の深さです。深さを出すのに一番簡単な方法は、「NO」と言わない。危険ですね。

もし、その機能が必要ならば、５０００万円かかります。やり方を変えれば５００万でできます。その場合は、これができて、これができない。運用回避であれば、画面に注意書きを入れるだけなので、無償でやります。

もちろん、こんなにすんなり行くとは限りませんけど、少なくとも、案を出すべきだし、できる、できないだけを言うのが仕事だとしたら、その仕事の存在とはなんでしょう。

（他の項目は、また時間があるときに。。。）

という事はPMの仕事を知っている必要があります。

• 顧客や上司、営業、協力会社の力のある人とネゴる。
• ごねる。
• 無視をする。
• 放置する。
• 一人でやる。

というような事は含まれていません。

顧客の要望を全て受け入れていたら、お金がいくらあっても足りません。

コストに合わせてできる事しか書かなかったら、仕事をもらえないか、喧嘩するしかありません。

問題、不具合、障害の定義とはなんでしょう。５年に一度しか使わない機能に重大なバグがあった時にどうするのか。

プロジェクトは可能性のある不具合とその影響度合いから、優先順位、検証の緻密さを決めなければいけません。

開発フェーズで保守フェーズのような事をしなくてはならない場合もある。開発は標準化、共通化、構造化を考え、コストリスクを軽減するものですが、１ヵ所の修正が多岐にわたったり、特別な対応は極力さけるものですが、保守では、変更内容が単純、影響範囲を極力小さくする。

１行の修正で済むが１００本のプログラムから呼ばれている場合、１行を修正するのが開発で１００本直すのが保守です。こんな、わかりやすい例は実際にはありませんが、どこかのタイミングで切り替えなければならない。

工程、スケジュール、要件のずれ、品質という数値から判断する事も大事ですが、PMの指針になってほしいと思ってしまいます。

１億の仕事を６０００万でやれと言われた時、どうしますか？

やらないという選択肢はありますが、もしやるのであれば、必要な５項目だよなあと思うのです。

そんなPMO指針がそろそろ出てきても、いいんじゃないかなあ。

• PHP 5.3.7 (cli) (built: Aug 21 2011 22:54:50)
• CentOS release 5.8 (Final)

au向けが目的ではなかったのだけど、docomo向けにコメント(textarea)と、画像を同時にアップできるように

<form … enctype=’multipart/form-data’>

とすると、コメントが au で化けてしまった。au の画像アップは、癖があるので、断念している人が多いし別ページにするという手もあるけど、ちょっと無理をしてみました。

textarea からアップされてきた情報は「%82%a6%82。。。」でした。

どこかで見たような気がするなあと、悩んだ挙句、urlencode されている事に気づいたので、

$str = urldecode($_REQUEST['aaaa']);

$str = mb_convert_encoding($str, “UTF-8″, “SJIS”);

※実際は絵文字対応もしているので、「HTML_Emoji」の encoding を使っています。

docomoや、PCブラウザでは必要ないので

if ( $str != urldecode($_REQUEST['aaaa']) ) {

$str = urldecode($_REQUEST['aaaa']);

。。。

と、とりあえず回避する事にしました。

• CentOS release 5.7 (Final)
• PostgreSQL 9.1.2 on x86_64-unknown-linux-gnu

エラーの内容は　（/opt/PostgreSQL/9.1/data/pg_log/startup.log）

LOG:  could not bind IPv4 socket: Address already in use
HINT:  Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
WARNING:  could not create listen socket for “localhost”
FATAL:  could not create any TCP/IP sockets
LOG:  database system was shut down at 2012-03-18 17:37:33 JST
FATAL:  the database system is starting up
LOG:  autovacuum launcher started
LOG:  database system is ready to accept connections
FATAL:  database “sample-db” does not exist
FATAL:  database “sample-db” does not exist
FATAL:  database “sample-db” does not exist
FATAL:  database “sample-db” does not exist

。。。

こんな感じ。sample-dbのデータベースが壊れてしまった。

ちなみに create dabase sample-db は実行できた。　とうぜん、中は空っぽ。

データファイルはどうなっているか、確認した。

（/opt/PostgreSQL/9.1/data/base/）

# du -sk *
6120 1
6112 12691
9420 12699
749232 17761　　　　←ここにあったっぽい。
6112 4277958
6112 6364733　　　←create database sample-db でできたディレクトリ

※ファイルの更新日付とデータサイズから、予測してみました。

postgres を止めて、

# mv 6364733 6364733.bk

# cp -rp 17761 6364733

として、postgres を起動したら、復活できた。

構成のみで、データの中身は無事だったみたい。良かったよかった。

先日、前の職場の先輩とたまたま再開した。自分には何があるのか。

甘えた発言では、あったけど、『いいとしとって、今更、プログラマも、ないだろう。業務知ってるんだから、強みを生かさなきゃ』と言われた。

業務を知っているとは、どういう事だろう。

あるIT企業では、若手に業務を教えたいのだが、どうしたらいいか。なんて聞かれた事がある。ふと、思うのだが、人から教わらるものだっけ。。

教わるものだけど、教材があるわけではないな。業務がわからないという人とプログラムがわからないという人は、どこか似た感じがする。かっこよく、仕事したいから、不得意分野には顔を出さない。

それは、なんとなく、カッコ悪い気がする。

私の得意分野は流通である。得意というより、長いだけなのだが、例えば、小売でいうところのリベートと製造メーカーのいうリベートは相対関係にある。同じ言葉だが、業務はまったく違う。

片や、原価管理であり、片や、売上管理になる。それも、一部だ。

小売では、仕入原価だが、特定数を発注したり、売上ると、リベートとしてお金が返ってくる。これをラッキーなお金としてしまったら、そもそも管理はできない。当然、買いすぎて廃棄する事もある。特売にするなど、販売計画をたてて、特定数を仕入る事で、仕入コストを軽減する事ができるという事だ。廃棄したら、次回のリベートに向けて予測しなおすべきだ。

製造メーカーは、売上目標を元にリベートの数量と金額を決める。利益を考えれば、少ない金額でたくさん売上げた方がいいのは明白である。一方で、厳しくしすぎると誰も買ってくれなくなるのだから、競合他社の動向も見なくてはならない。

片や固い原価管理であり、片はマーケティングである。

こういう事を理解するには、顧客と近い位置にいなければ、ならない。そして、全てをシステム化すべきかというと、顧客規模によりまちまちである。

肥大化した組織では、情報量が多く分析するには、ターゲットを決めてシステム化する必要がある。新たなチャレンジであれば、とれる情報量は少なく、システムというよりは、ちょっとしたツールで瞬時にExcel化できればいい。

これも、業務を理解する事である。原理原則と現状把握のバランスをとるという事を、どのように教えるのか。

企業の成長には順番がある。商店が大手スーパーと同じものを求めているわけがないのは分かっているのに、往々にして、場違いな提案をしているSEはいるものだ。

それは、カッコ悪いかも、しれないけど、業務を理解するには、必要な事のように思う。

下記のように投稿画面にウィジェットが追加され、FacebookやTwitterと連動できるようになります。

連動の流れ

①　Status Updater プラグインの追加 (WordPress)

②　Facebook のアプリ追加　(Facebook developper サイト)

③　Twitter のアプリ追加  (Twitter developper サイト)

④　Status Updater の設定 (WordPress)

⑤　投稿を入力すると、連動します。

上記が、大きな流れになります。

「①　Status Updater」

※プラグインの新規追加で「Status Updater」を検索し、一番上にでてきたものを使用しています。

「②　Facebookのアプリ追加」

WEB、Android、iPhoneのアプリからFacebookを接続する為にFacebookにアプリとして追加します。

http://www.facebook.com/developers/ で申請します。

※申請時に携帯メールアドレスを聞かれ、メール内容を入力したりします。

※アプリ登録後の画面

基本データを登録するとAppIDとAｐｐSecretが採番されて、結合する方法にウェブサイトを設定しました。

「③ Twitter のアプリ追加」

https://dev.twitter.com/apps　で申請します。

※続き

※ApplicationTypeが、理解できていないけど、連動なので、「Read, Write and Access direct messages」にしました。

登録するとDetailsタブ画面で、「Consumer key」と「Consumer secret」が採番されます。

「④　Status Updater の設定」

WordPress の設定－StatusUpdater画面で、取得したID（Key)とSecretを設定します。

Loginボタンで認証確認します。下記、メッセージがでれば、OKです。

「Your blog is now linked to your Facebook account. Close this window AND save the WP settings page after filling all the fileds.」 ※Twitterもほぼ同じメッセージ

Saveすると、下記画面が表示されます。

※Facebookの方は癖があって、何回かSaveすると、AccountNameが２行表示にかわる。Push as status か Push as link かは試してみるといいと思います。私はPush as linkにしました。

※中略

オプション設定は、Advanced status commpositionと、Log emailを設定しています。Advanced status …は、投稿毎に連動するか否かを設定できるようにします。

以上で、連動できるようになります。つまづいたところが、いくつかあったように思いますが、思いだ出せない。。。各developper サイトの申請から、WordPressからの接続まではFacebookはすぐに可能になったけど、Twitterは、２０分ほど待たされました。たまたまかもしれませんけど。。。