だ。ログ。

開発とかスノボとかやきうとか。

curlのデフォルト表示

apijsonデータを送信してレスポンスコードを取る。と言う部分でcurlで~なんて言うだったので軽い気持ちで

$curl = curl_init("apiのurl");
curl_setopt($curl, CURLOPT_POST, TRUE);
curl_setopt($curl, CURLOPT_POSTFIELDS, http_build_query($data));
$output = curl_exec($curl);

ってな具合で書くと

{Responcecode: hoge}
と言うレスポンスコードが出てしまう。
これを明示的に消すためには、setoptに

curl_setopt($curl, CURLOPT_RETURNTRANSFER, TRUE);

上記を明示しないとだめ。
明示してレスポンスコードを表示する なら納得出来るんだけど、明示して表示しないにする。と言うPHPの意図はなんだろう。。

PHPでS3のデータ取得

IAMの設定とかS3のバケットの設定とかはが終わっている前提で、aws-sdk-phpを突っ込んで開発準備を行う。
公開ディレクトリトップにて実行

$ composer require aws/aws-sdk-php
$ curl -sS https://getcomposer.org/intaller | php
$ php -d memory_limit=1 composer.phar require aws/aws-sdk-php

上記でaws-sdkを利用できるようにする。
このコンポーネント一覧を利用してS3と通信する。後述するuseするだけなのでそんなに難しい事はない。

一覧を取得する

require '../vendor/autoload.php';
use Aws\S3\S3Client;
use Aws\S3\Exception\S3Exception;

$key = "S3に設定したIAMのキー";
$secret = "上記のキーのsecret";
# リージョンは利用しているリージョン名を記述。自分は東京なので以下
$region = "ap-northeast-1";
$bucket = "S3バケット名";
# prefixは閲覧したいディレクトリ(概念)のデータ一覧を取得する。
# なければ上から全部取得してくる
# サンプルは /hoge/fuga/ 以下のファイル全てを取得してくるようになる。
$prefix = "hoge/fuga/";

      $S3 = S3Client::factory([
        'credentials' => [
            'key' => $key,
            'secret' => $secret
          ],
          'region' => $region,
          'version' => 'latest'
      ]);

      $list = $S3->listObjects([
          'Bucket' => $bucket,
          'Prefix' => $prefix,
          'Delimiter' => "/"
      ]);

      foreach ($list['Contents'] as $img) {
            if($i > 0){
		echo "画像:<img width=\"300\" src=\"https://s3-ap-northeast-1.amazonaws.com/".$bucket."/".$img['key']."\" /><br />";
            }
            $i++;
      }

単純にデータを取得する場合はこんな感じで取れる。
概念の違いでディレクトリと言う物はコンソールからは確認できるが、いわばタグのような物なので厳密にはディレクトリ分けにはなっていない。
第一弾として取る事に関してはコレでいけたので、次回はアップロードを作ってみる。

丸投げる限界点

丸投げる限界点

わからないんで~
ちょっと技術的に難しいんで~

と言う言葉から色々と頼まれる事が多い。
まあ、おっさんだからしゃーない。出来る事と言うよりは、やった事がある。そのナレッジがあるから相談される。
依頼の仕方もそうだし、作業させる人間が居て依頼をする訳だから、まず何をしたけど出来ない。と言う事がないままに丸投げられる。

例えば全く知らないツール導入の仕方がわからない。
この一文だけ送られてきてお願いします。と言われる。

俺もわからない。

それは同じスタートラインだが「○○日までに使えるようにならないと困ります」と返される。
困るのは勝手だ、何をどうしたが出来ない。この部分が使えるようになりたい。
だったらこちらも対処のしようがあるが、まず操作すらロクにしていない。
設定が難しいから丸投げる。

そこまででもストレスになるが、今度は他の不具合が出ると自分が一番理解出来ているからと調査を依頼される。

いや知らんがな。

結局属人化する、それも誰も調べようとも知ろうともしない。
ただ吊るしで使えれば良いだけで、それ以上の事を考えない。
それが他社の金を貰ってる依頼ならまだしも社内の違う部署。質問内容を辟易として眺める午後の昼下がり。

LambdaでGoogleHangoutsChatにメッセージを送る

https://dev.classmethod.jp/cloud/aws/google-hangouts-chat-integration-with-aws-lambda/dev.classmethod.jp

ここにあるソースコードの通りで動く。
なのでソースコード部分に関しては上記のリンクを観た方が早い。

ただLambdaド素人の自分はソースコードだけでは動かず右往左往。
要点としては

・自分で環境を整えて利用するライブラリをソースコードに包括しておく
・ファイルをzip形式で圧縮してLambdaにアップロードする

この2点が理解出来ればLambdaでの自動化の部分が身近になってくると思う。

自分で環境を整える

何が言いたいかと言うと、上記のリンクだとrequestsで必要なファイルを実際に送信するソースコードと一緒にアップする必要があると言うところ。

	$pip3.6 install requests -t.

requestsの後ろの -t.が必要で、現在のディレクトリにライブラリ実体をファイルとして利用できるようにする。と。

zipで上げる

整えた環境のディレクトリをPCに一旦保存した後にzipに圧縮する際の注意として、ダウンロードしてきたディレクトリを圧縮すると
lambdaにアップロード後、ディレクトリが親ディレクトリとなってしまう。

[ プロジェクト名 ]
└[圧縮したディレクトリ]
├ファイル1
├ファイル2
├ファイル3

と言う事になってしまう。圧縮したディレクトリが邪魔。
なので、ファイル全体を選択して圧縮をすること。

あとはソースコードが正しく書けていれば動作確認が取れる。
ChatWorkにも送信事態は出来たが、GSuiteを使っているのでどちらにするか迷い中。
個人的にはWebhookが簡単につくれるhangoutChatの方が手間が掛からないなと。

python3.6をインストールした際にpipが使えない

lambdaを使う為にpython3.6でソースコードを書かねばならずcentos7にてpythonをインストール

	$yum install -y https://centos7.iuscommunity.org/ius-release.rpm

これでpython3.6のリポジトリを取得。
んでインストール

	$yum install python36u python36u-libs python36u-devel python36u-pip

サクっと完了。
動作確認のために、hello.pyを作る。

	print("hello")

これを実行する。

	$python3.6 hello.py
>hello

出た。

んで、lambdaで動かしたいのでpipを使ってrequiresをインストールする

	$pip install requests

ここで問題発生。
コマンドが見つかりませんと出る。

pip3もダメ。
じゃあ何ならと調べたら

	$pip3.6 install requests

これで動いた。
結局の所はインストールした物を明示的に指定しなきゃダメなのね。と。

はじめてのLambda

AWSのサーバーのアラートをChatworkに飛ばしたい
ってのが前提で、あまり手付かずだったLambdaに着手。

まず手始めに
https://qiita.com/don_hanabi/items/3bd729bf0458d10b8d5e
qiita.com


上記のサンプルコードをそのままコピペする。
利用するランタイムはNode.js 6.10

ここで間違えてはいけないのは、ファイル名は index.js にしておく。
意図的に自分のテストですって事をファイル名につけていたら

Cannnot find module 'index'

と出てしまい、テストが実行できなかった。
とりあえず、テスト実行からチャットワークへの投稿自体は出来るよになったが
メッセージが途中で切れちゃうのは自分が悪いのか。。

この辺はいまのところ手探り。

オフショアと言う夢。

コスト削減をしたいと言う会社の意向は分かる。
エンジニアが正しい金額で働いているかと言う事は、尺度で測る術があまりないからだ。
そこで出てくるのは、これ以上部隊を強化するよりも安い金額でお願いする。

オフショアと言う事になる。

じゃあ具体的にオフショアってどうすれば良いと言うナレッジが一般の企業にはない。
新たに持ち込まれたコスト削減策をどうすればコスト削減になるかと言う具体的な部分の議論がないのである。
全てが全てではないが、オフショアの紹介先から言われるがままに部隊の確保が完了したと言う話が降りてくる。

「じゃ、あとは現場がうまく使ってね」

この一言で現場は混乱がはじまる。
そもそも現地のコーディネイターとも会話した事がない。
しかも部隊が使える技術力の把握が出来ていない。紹介者もサイトの上辺だけを見て大丈夫ですとしか言っていない。

まずは仕方なしに小さな改修をお願いする。
まーこの位なら。と言う気持ちで経験の浅めの人間に仕事を依頼する。
1日後返ってきたメールには烈火の如く怒りに満ちたモノである。

・詳細に練られた設計
・正常時の最終的な完成イメージ
・異常時の対処方法


そして先方からこのフォーマットに合わせろと言う指示の元に書く。
たかだか2,3行の修正の為に、結果まで全て包括した設計が必要となる。
仕方なしに仕様理解と変更に伴う結果が分かる人間が仕様書のレビューをする。
そのレビューを通ると今度はオフショア様側にお伺いを立てる。

オフショア様側は分かりました。と返答とともにシステムを完成させる。

ところがだ、この数行の変更で済むはずのシステムが何故か外部プラグインを取込み仰々しいまでの変更が加えられている。
確かに満たす所の動作は出来ているが、動作させる為に様々な所に変更が掛かる。
トレンドを追った結果、言葉で伝えれば最初に烈火に怒られた人間が30分もあれば出来る事に半日以上を費やした。


さて、これが簡単なシステムであればまだしもである。
複雑なシステムになってくると、今度はコーディネイターとの信頼構築が必須となってくる。
提示されたドキュメントに沿ってドキュメントを作成する。
提出して返ってくる言葉は意外とあっさりと「分かりました」と返ってくる。

結局この納品で地獄を見たのは何あろう発注側である。
何が間違いだったか。

そもそもオフショアなんて使うこと

現場の結論としてはそれが全てである。
具体的に言えば、仕様に関しての大枠を組めば「ある程度」のモノは出せるので「ある程度」の大枠をこちらは提示した。
提示して出てきたモノは、そもそも論バグで動かない状態が「仕様だから」と言う事で作成されている。
そして一番の問題は、現状のモノを見てテストをしながら軌道修正が出来ないので、テスト仕様を決める事ができない。
勝手にUI部分を変更していたり、動的な要素が意図せぬ動きをしてくる。
そこまで含めて仕様に盛り込んで書けと言われる。

ぶっちゃけて言えば、自分が作った方が早い。
と言う事なのだ。

目の前で依頼者と話をしながら方向性やデザイン、内容のブラッシュが出来ない。
完全なるウォーターフォール型でウェブ開発を行わねばならない。
と言う事は

・視覚的要素のフィックス
・動的要素のフィックス
・システム仕様のフィックス
・テスト仕様のフィックス

ここまで出来て、はじめて「オフショア」が成立する。
一つでも欠けると、依頼者側が全てを担保する。それも現地コーディネイターは○○できてないから。○☓ではないから。
と言う理由で全てが動かなくなる。

最終的にどうなるか。
「もういい、俺が書く」

自分が使いこなせない事が悪い。確かにそれは事実だ。
しかし、上手く行く為にはどうすべきかと言う議論もなしに海外を使う事で開発力を国内より安価ですぐに用意する事ができる。
と言う具体例がないままに使うと、簡単に出来る事すらも簡単にならなくなる。
体制だけ豪華になり、ボトルネックが生まれる。

開発メンバーがディレクションとコミュニケーションに大半の時間を取られドキュメントを書かれ。
結局はそれにつきっきりになり「とりあえず作る」金額は抑えられたが完成までにはメンバーが対処するのでむしろコストフルになる。

と言う夢を見た。フィクション。