狛ログ

こんにちは、オフィス狛デザイン部のSatoです。

先日、アイコンをSVGで作成した際に、マウスオーバーすると色が変わったりするようなことがしたいなぁ……と思うことがありました。
普段なら商用フリーでCDNのアイコンフォントをアイコンにしてしまったりするのですが、今回は少し特殊なアイコンでそれもできず……。
SVGの色をテキストのようにCSSで変えたりできないものかと思って調べたらできる様子！
試してみた所、なんとか自分でもできたのでやり方をメモしたいと思います。

やり方は簡単。<svg>か親要素のCSSにfill: カラーコード;を追加するだけです。
ちなみに値を「currentColor」にするとなんとcolor設定されている色になります。

HTML
<a href="#"><svg>(本来はここにインラインで記載)</svg>Button</a>

CSS
a{color: #3ab28f;}
a:active{color: #3ddaa3;}
svg{fill: currentColor;}

こんな感じですね。
ただし、<img>タグや<object>タグではこの方法では色を読み込んでくれないようです。
最初自分はそこで躓いたのでご注意ください。

正直、自分は今までSVGのことを「どんなに拡大しても画像が荒れないすごい画像形式」くらいにしか思っていなかったのですがこんな事もできるんですね！びっくりしました。

オフィス狛 技術部のKoma（Twitterアカウントの中の人＆CEO）です。

前回は、Webサイトの問い合わせフォームから問い合わせされた内容をS3バケットへテキスト形式で保存するところまで行いました。
今回は、S3に保存されたら、その内容をメールで送信したいと思います。

※メールを送信する為のAWS SES(Simple Email Service)については説明を省きます。SESの設定が終わった状態で下記の手順を行って下さい。

１）ポリシー（Policy）の作成

まずは、AWSコンソール上のIAMのページへ遷移し、左側のメニューから「Policies」を選択。
その後、左上の「Create policy」をクリックします。


Serviceは、「CloudWatch Logs」
Actionは、「CreateLogStream」、「CreateLogGroup」、「PutLogEvents」
Resourceは「all resources」を選択して、
右下の「Review policy」をクリックします。


最後にNameとDescriptionを入力し、「Create policy」を選択します。


作成に成功しました。

２）ロール（Role）の作成

続いてロールを作成していきます。先程と同じくAWSコンソール上のIAMのページへ遷移し、
左側のメニューから「Roles」を選択します。


Select type of trusted entityは「AWS service」を選択。
Choose the service that will use this roleは「Lambda」を選択して、
右下の「Next: Permissions」をクリックします。


まずはFilterで「Policy type」を選択します。
続いてAttach permissions policiesでは「AmazonSESFullAccess」をチェックします。
（検索ボックスで「SES」と入力すると、フィルターが掛かって選択が楽です）


次にFilterで「Customer managed」を選択し、先程作成したポリシーにチェックを入れます。
（検索ボックスの中身を消さないと一覧に出て来ないのでご注意を）
右下の「Next: Review」をクリックします。


最後、Role nameを入力して、右下の「Create role」をクリックします。


作成に成功しました。

３）Lambda Functionの作成

AWSコンソール上のLambdaのページへ遷移し、「Create a function」を選択。


「Author from scratch」を選択し、Name等の必要な情報を入力します。
Runtimeは「Node.js」を選択して下さい。
Roleは「Choose an existing role」を選択し、Existing roleは、先程作成したロールを選択します。


作成直後の状態です。
ここで、左側の「Add triggers」から、「S3」を選択します。


対象のバケットを選択し、Event typeは「PUT」を選択します。 「Add」をクリックします。

続いて、Node.jsのプログラムを貼り付けます。


貼り付けるプログラムは以下の通りです。

'use strict';

console.log('Loading function');

const aws = require('aws-sdk');
const s3 = new aws.S3({ apiVersion: '2006-03-01' });
const ses = new aws.SES({ apiVersion: '2010-12-01', region: 'us-east-1' });

exports.handler = (event, context, callback) => {
    const bucket = event.Records[0].s3.bucket.name;
    const key = decodeURIComponent(event.Records[0].s3.object.key.replace(/\+/g, ' '));
    const params = {
        Bucket: bucket,
        Key: key
    };

    s3.getObject(params, (err, data) => {
        if (err) {
            console.log(err);
            const message = `Error getting object ${key} from bucket ${bucket}. Make sure they exist and your bucket is in the same region as this function.`;
            console.log(message);
            callback(message);
        } else {
            const json = JSON.parse(data.Body.toString());
            const message = `
                名前： ${json.name}           
                MAIL： ${json.email}
                問い合わせ日時：
                ${json.date}
                問い合わせ内容：
                ${json.comments}
                `
            const params = {
                Destination: {
                    ToAddresses: [process.env.TOADDRESS]
                },
                Message: {
                    Body: {
                        Text: {
                            Charset: "UTF-8",
                            Data: message
                        }
                    },
                    Subject: {
                        Charset: "UTF-8",
                        Data: "フォームからのお問い合わせ"
                    }
                },
                Source: process.env.SOURCEADDRESS
            };
            ses.sendEmail(params, function (err, data) {
                if (err) console.log(err, err.stack);
                else console.log(data);
            });
        }
    });
};

プログラムに環境変数を使っているので、値を設定します。
SOURCEADDRESSが送信元（＝from）アドレスで、
TOADDRESSが送信先（＝to）アドレスです。


以上でLambdaの設定が完了となります。
Lambda作成後、前回作成した問い合わせフォームから、問い合わせを行うと・・・
この後、S3側のトリガー設定などが残っているのですが、以降は、独自ドメインの設定を行った後にやって行こうと思います。
と言う事で、WebサイトへのアクセスはS3のURLを利用しているので、 次回はRoute53を使用して、独自ドメインでの運用を可能にしていきたいと思います。

次回：Amazon S3 で サイト公開（HTTPS）する。（４）Route 53を使用した独自ドメイン運用
前回：Amazon S3 で サイト公開（HTTPS）する。（３）問い合わせフォーム準備編その１

オフィス狛 技術部のKoma（Twitterアカウントの中の人＆CEO）です。

前回からだいぶ時間が経ってしまいました。
さて、前回までで、S3へサイトを移管する事が出来ましたが、サイトによっては問題が発生します。
そう、S3は単にストレージに過ぎないので、サーバサイドのプログラム（PHPなど）は動かすことが出来ません。
弊社のホームページですと、「問い合わせフォーム」が該当します。

旧サイトでは、「問い合わせフォーム」から問い合わせ内容をPOSTし、Webサーバ側のPHPファイルを実行し、メール送信処理を行っていました。
けれど、S3ではPHPを実行する事は出来ません。

という事で、代替案として、以下の方法を取ろうと思います。
・問い合わせフォームにて入力された内容を専用のS3バケットへテキストファイルとして保存
・S3バケットへの保存をトリガーに、Lambdaファンクションでメール送信

早速、実施して行きましょう。

１）identity poolの作成

まずは、AWSコンソール上のAmazon Cognitoのページへ。

・Step 1:Create identity pool
「Identity pool name」に適当な名前を設定し、「Enable access to unauthenticated identities」にチェックを付け、「Create Pool」を押します。

・Step 2:Set permissions
IAM Roleを選択します。
このタイミングで作成する事も可能なので、今回は、「Create a new IAM Role」を選択し、
Roleの名前を付けて、「Allow」を押します。

※Cognitoについては、こちらを参照。

そうすると、identity pool id が発行されるので、メモっておきます。

ここでやっている事は、『S3へファイルをアップロードする為の認証情報を作成している』、と思って頂ければ良いと思います。

2）IAM Roleへ権限付与

AWSコンソールで、IAM　Roleを見ると、先程新規で作ったRoleが見れると思います。

次はこのRoleにS3へのファイルアップロード権限を付与します。
先程の画面でRoleをクリックすると、下記の画面に遷移しますので、
「Add inline policy」をクリックします。

・Visual editorでポリシー作成
JSONを直接貼り付けて説明しているサイトが多いのですが、それだと意味を理解しないで使ってしまうと思うんですよね。
と、言う訳で、視覚的にポリシー作成を行なって行きます。
「Choose a service」をクリックします。

まずはサービスの選択ですが、S3と検索ボックスに入力すると、S3が選べるので、クリックします。

続いてアクションですが、S3にファイルを格納（Put）する必要があるので、
「PutObject」と「PutObjectAcl」をチェックします。
（他にもたくさんのアクションがあるので、ここでも検索ボックスに「PutObject」と入力しておくと楽です。）

次に、対象となるバケットを選択します。
「Specific」を選択してから、「Add ARN」をクリックします。

表示されたポップアップでバケット名をします。（バケットは前もって作っておいて下さい）
バケット内のオブジェクトは全てを対象とします。

バケットを選んだ後はこんな感じになります。
確認後、「Review policy」をクリックします。

最後、ポリシーに名前を付けて、「Create policy」でポリシーを作成します。

出来上がったポリシーのjsonはこんな感じです。
結構な手順記載しましたが、内容自体はこれだけ。

3）CORSの設定

サイトがあるドメイン(S3バケット)と問い合わせ内容を保持するドメイン(S3バケット)は違うので、
CORS(Cross-Origin Resource Sharing)を設定する必要があります。
これを設定しないと、後に用意するjavascriptプログラムから問い合わせファイルをアップロードすることが出来ません。

では、AWSコンソール上で、問い合わせ内容を保存するS3バケットを選択し、
Permissionsタブから、「CORS configuration」を選択し、編集を行います。

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>http://officekoma.co.jp.xxxxxxxxxxxxxxxxxx</AllowedOrigin>
    <AllowedMethod>PUT</AllowedMethod>
    <MaxAgeSeconds>3000</MaxAgeSeconds>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>

「AllowedOrigin」には、問い合わせフォームがあるサイトのドメイン(S3バケットURL)を指定します。
これを「*」にしてしまうと、先程のidentity pool idを知っていれば、そこら中のドメインからファイルがアップロード出来てしまうので要注意です。

4）問い合わせフォームとアップロードプログラムの作成

後は問い合わせフォーム(html)とアップロードプログラム(javascript)の作成です。

弊社サイトの問い合わせフォームは以下のようになっています。

・問い合わせフォーム(html)

<!doctype html>
<html lang="ja">
<head>
  <!-- 中略 -->
  <script src="https://sdk.amazonaws.com/js/aws-sdk-2.200.0.min.js"></script>
  <script src="../js/s3Upload.js"></script>
  <!-- 中略 -->
</head>
<body>
  <!-- 中略 -->
  <h1>お問い合わせはこちらからお願いします。</h1>
  <p>フォームからの送信に失敗する場合、お手数ですが <a href="mailto:info@officekoma.co.jp">info@officekoma.co.jp</a> まで直接ご連絡ください。<br>
  ※商品・サービスの売り込み、その他営業活動・勧誘などには返信できかねますのでご遠慮ください</p>
  <script type="text/javascript" src="../js/form-validation.js"></script>
  <div class="form_control setting_center">
    <form id="contactForm" action="#">
      <fieldset>
        <p>お名前または会社名(Name)<span class="required">※必須</span></p> <input name="name"  id="name" type="text" class="form_box" autocomplete="name" required />
        <p>メールアドレス(Email)<span class="required">※必須</span></p><input name="email"  id="email" type="text" class="form_box" autocomplete="email" required />
        <p>問い合わせ内容(Comments)<span class="required">※必須</span></p>
        <textarea name="comments" id="comments" class="form_box" rows="4" cols="40" ></textarea>
        <div class="input_submit"><input type="button" value="送信　" name="submit" id="submit"  /></div>
      </fieldset>
      <p id="error" class="warning">送信に失敗しました。恐れ入りますが、再度入力をお願いします。</p>
    </form>
    <p id="success" class="success">お問合わせを送信いたしました。ありがとうございました。内容を確認後、早急にご返信させていただきます。もし数日中に返事が無い場合は、正しく受信できなかった可能性がありますので、恐れ入りますが再度のご連絡をお願いします。</p>
  </div>
  <!-- 中略 -->
</body>
</html>

・アップロードプログラム(javascript)
「contactBucketName」、「bucketRegion」、「IdentityPoolId」をそれぞれの環境に合わせて変更して下さい。

jQuery(document).ready(function($) {
    var contactBucketName = 'homepage-contact';
    var bucketRegion = 'hogehoge';
    var IdentityPoolId = 'hogehoge:xxxxxxxxxxxxxxxxxxxxxxxxxxx';

    AWS.config.update({
        region: bucketRegion,
        credentials: new AWS.CognitoIdentityCredentials({
            IdentityPoolId: IdentityPoolId
        })
    });

    var s3 = new AWS.S3({
        params: {Bucket: contactBucketName},
    });

    // hide messages 
    $("#error").hide();
    $("#success").hide();

    // on submit...
    $("#contactForm #submit").click(function() {
        $("#error").hide();
        
        //name
        var name = $("input#name").val();
        if(name == ""){
            $("#error").fadeIn().text("名前を入力してください。(Name required.)");
            $("input#name").focus();
            return false;
        }
        
        // email
        var email = $("input#email").val();
        if(email == ""){
            $("#error").fadeIn().text("メールアドレスを入力してください。(Email required.)");
            $("input#email").focus();
            return false;
        }

        var now = new Date();
        var obj = {"name":$("input#name").val(), "email":$("input#email").val() ,"comments":$("#comments").val(), "date": now.toLocaleString()};
        var blob = new Blob([JSON.stringify(obj, null, 2)], {type:'text/plain'});
        s3.putObject({Key: now.getTime() + ".txt", ContentType: "text/plain", Body: blob, ACL: "public-read"},
        function(err, data){
            if(err !== null){
                $("#error").fadeIn();
            }
            else{
                $("#success").fadeIn();
                $("#contactForm").fadeOut();
            }
        });
    });

    return false;
});

5）動作確認

実際に問い合わせを行うと、下記のようにファイルがアップロードされます。


ちょっと長くなってしまいましたが、これでPHP無しでも、サイトからの問い合わせの内容を確認する事が出来るようになりました。

とは言うものの、これだと、毎回能動的にS3のバケットを確認しないと問い合わせが確認出来ないので、現実的はありません。
次回は、問い合わせ内容をメールで送信する方法を記事にします。
（なんだか本質とは離れていっていますが、一応「サイトのhttps化」の一環です。）

次回：Amazon S3 で サイト公開（HTTPS）する。（３）問い合わせフォーム準備編その２
前回：Amazon S3 で サイト公開（HTTPS）する。（２）S3での公開準備編

オフィス狛 技術部のHammarです。

node.js、Postgresqlという開発環境で、knexというSQLライブラリを利用して開発をしているのですが、今回はIN句でプレースホルダを使って配列をセットしてクエリを作成した時にハマったことを書いてみようと思います。

通常knexライブラリでIN句を使ってクエリを作成するとこんな感じになると思います。
■出力SQL

そして上記を応用してIN句にプレースホルダを使うとするとこのような感じになります。
■出力SQL

で、実際のプログラムではこのIN句の中を配列の変数で扱ってクエリを作ることが多いと思いますが、その場合はこんな感じになると思います。

このクエリでも基本的に問題なく動きますが、このクエリだと配列の中の値をすべて文字列として認識してしまい、数値項目に対してこのクエリを実行するとsyntaxエラーとなってしまうんです。
上記のクエリの場合、idというカラムがint型の場合は下記のようなクエリがながれてしまい値が取れません。
■出力SQL

いろいろと調べてみてようやくたどり着いたのが、プレースホルダを??にするという対応でした。
https://github.com/tgriesser/knex/issues/1537

でこんな感じになります。単純に?を2つにしただけ。
■出力SQL

これで意図する値の取得ができるようになりました。

この事象はpostgresqlだけ？なのか、ほかのmysql等のRDBではどうなのかはわかりませんが、posgresqlでknexライブラリを使う際には上記を参考にしてみてください。

オフィス狛 技術部 CTOの Taka-yamです。

あるJavaのプロジェクトでSpring Frameworkの脆弱性問題により
SpringBoot1.31から1.51へアップデートする必要がありました。

その際に、やはり思った通りにはいかず、いくつかハマった点がありましたので、
ここで情報共有します。

まず最初のエラーです。

ServletContext resource [/hoge] defined by 'spring.datasource.schema' does not exist

このエラーは「datasource.schemaが存在しない」と出ています。
どうやら Spring Boot1.5 から、デフォルトでDBの初期化処理を行おうとし、schema.sqlやdata.sqlというファイルをクラスパスのルートから探しに行くようです。
今ままではこのような処理を行っていなかったため、当然ファイルは存在せずエラーとなっていました。

対策としては、下記のプロパティをapplication.ymlに追加します。

spring:datasource:initialize: false

次は下記のエラーが出ました。

java.lang.ClassNotFoundException: org.springframework.session.hazelcast.HazelcastFlushMode

これはspring-sessionのバージョンを間違えており、2系のバージョンを指定していたため、
SpringBoot1.51では依存関係が解決できないことが原因でした。
バージョンを変更し、無事に解決できました。

最後に下記のエラーが出ました。

No Spring Session store is configured: set the 'spring.session.store-type'

これもSpringBoot1.5からの特徴でspring.session.store-typeを指定しないとエラーになるように変わりました。
今回は何も使用していないため、何も指定しないように設定します。

spring:session:store-type: none

以上でエラーが解決され、無事に動作も確認ができました。
計画的ではなく、突発的なアップデートの際には色々と調査が必要ですね。

オフィス狛 技術部 CTOの Taka-yamです。
Node.js のアプリケーションを開発していて、
SQLを構築するためにknexというライブラリを活用しています。
http://knexjs.org

素のSQLに近い形でfluentにSQLを構築できるので大変便利なのですが、
動的パラメータでlike検索を行うとした際に値の設定方法ではまったので共有します。

下記のようなユーザテーブルがあるとします。

User
id: String
name: String

textという変数に入力された値が格納されているとして
ユーザテーブルのnameカラムにあいまい検索を行うとします。

まず最初に思いついたのが、

knex(‘user’).whereRaw(“name like ‘%?%’”, text);

これはエラーとなります。

type \"like\" does not exist"

次に思いついたのが、

knex(‘user’).where('name', 'like', knex.raw('%?%', text));

これもエラーになります。

syntax error at or near \"%\""

次に思いついたのが、

knex(‘user’).whereRaw(‘name like %' + text + '%');

これもエラーになります。

syntax error at or near \"%\""

次に思いついたのが、

knex(‘user’).whereRaw("name like '%" + text + "%'");

これはうまくいきました。

ですが、このような文字列連結をすると弊社で使用している Lint に怒られてgit commitさえ出来ません。（lint-stagedでcommit制限掛けているので）

なので、最終的に、

knex(‘user’).where(‘name’, 'like', `%${text}%`);

となりました。

結論を見ればすごい単純なことなのですが、
結構はまったので、もし同じようなことで困っている人の助けになれば幸いです。

オフィス狛 技術部のHammarです。

よくデータベースを操作する処理で、あるキーでデータがあればUPDATE、なければINSERTするーというような場面が多々あると思います。
通常はまずはそのキーで件数をSELECTして、件数が０件ならINSERT処理へ、0件以上ならUPDATE処理へ分岐させるというような感じの処理の流れが、まあよくある感じかなと思います。

じつはこれを１回のクエリで行うことができるのですが、PostgresqlやMysql等でやり方がそれぞれ違います。
今回はPostgresqlでのやり方で、自分が少しハマった部分や注意点も含めて書こうと思います。

■UPSERT

「データがあればUPDATE、なければINSERTする」という処理はUPSERTと呼ばれています。INSERT（追加）とUPDATE（更新）の両方の機能を併せ持っていることから、UPDATE + INSERTで、UPSERTということのようです。

PostgresqlはバージョンによってこのUPSERTのやり方が変わってきます。
Postgresql 9.5以上でCONFLICTというUPSERTができる機能が備わりましたが、それより前のバージョンではこの機能が使えないので、CTE（共通テーブル式）という構文を利用して下記のようなクエリでUPSERT的なことが可能です。
（ちなみにCTEとはこちらに詳しく書かれています）

■CTEを使ったUPSERT的なクエリ

上記のクエリでUPSERT的な動きとなり、自分もこの方法で処理を書いていたのですが、この方法で１つハマったことが起きました。
通常テーブルにレコードが何件かある状態で上記のクエリは問題ないのですが、テーブルにレコードが１件もない（初期状態）の場合、「なければINSERT」となるので本来ならレコードが登録されるはずなのですが、なぜか上記のクエリではレコードが登録されず、テーブルは空のままでした。
原因は不明なのですが、恐らくSELECT句でNULL判定できずに登録するものがないと判断されるようです。（ただ、試しにNOT NULLでやってもうまくいきませんでした）
ということで上記の方法は厳密には使えないことがわかったので、どうしようかとちょっと悩みましたが自分の開発環境がPostgresql 9.5以上であることがわかり、ならばあたらしく備わったCONFLICTという機能を使ってみようということで、下記のようなクエリを作成します。

■CONFLICT機能を利用したクエリ

短くていいですね！
ON CONFLICTにキーを指定して存在確認し、レコードがあればUPDATE、なければINSERTというようになっています。ただこのクエリにも１つ注意点があり、ON CONFLICTに指定する項目はUNIQUE制約がある項目でないとこのクエリはエラーとなってしまいます。なので、テーブルの指定の項目にUNIQUE制約をつけて使うようにしてください（複数項目でUNIQUEとなる場合は複合UNIQUE制約をつける）

CTEを使ったクエリでも本来ならうまくできると思うんですが、自分の環境が悪いのかそもそもの問題なのかは今のところわかっていません。ただCONFLICT機能のほうがクエリ的にもすっきりですし、かなり使えると思うのでPostgresql 9.5以上の環境があればこちらを使ったほうがいいと思います。