S3+CloudFront+Route 53を使った静的コンテンツ配信 Part 2 (lambda@edge編)

福岡拠点の野田です。

前回、S3を使った静的コンテンツ配信を実現しましたが、ちょっとカッコ悪い点がありました。

ドメイン直下については、 Default Root Object 設定すると https://サイト名/でアクセスしたときindex.html を参照するようにできます。ただし、サブディレクトリ配下はDefault Root Objectの設定が効きません。サブディレクトリ配下で/news/とアクセスしたとき、/news/index.htmlを参照するためにはlambda@edgeを使う必要があります。

/で終わるuriの場合に/index.htmlを参照する設定について、今回は以下の流れで設定を行います。

  1. lambdaを追加
  2. CloudFrontで使えるようにIAMを修正
  3. lambdaにトリガーを追加し、CloudFrontと関連付け

lambdaを追加

リージョンus-east-1のlambda画面から関数を追加します。ほかのリージョンではCloudFrontへのトリガーを作成できないため、正しいリージョンが選択されているか確認してください。

https://console.aws.amazon.com/lambda/home?region=us-east-1

lambdaは1から作る形で進めます。

・関数名:subdir-redirect (適宜適当な名前を設定してください)
・ランタイム:nodejs (バージョンはデフォルトでOK)
・アクセス権限:AWSポリシーテンプレートから新しいロールを作成
・ロール名:cloudfront-lambda (適宜適当な名前を設定してください)
・ポリシーテンプレート:基本的なlambda@edgeのアクセス権限

関数詳細ページが表示されるので、関数コードに以下を追加します。

'use strict';
exports.handler = (event, context, callback) => {
    var request = event.Records[0].cf.request;
    request.uri = request.uri.replace(/\/$/, '\/index.html');
    return callback(null, request);
};

画面右上の「保存」を押下してコードを保存します。

CloudFrontで使えるようにIAMを修正

そのままでは使うことができないため、関数詳細ページ「アクセス権限」のタブを選択します。実行ロール「 cloudfront-lambda 」を編集し、末尾の「 IAM コンソールで cloudfront-lambda ロールを表示します。」のリンクをクリックします。

ロールの詳細ページから「信頼関係」のタブをクリックします。「信頼関係の編集」ボタンを押下して、以下のようにedgelambdaの設定を追加します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "lambda.amazonaws.com",
          "edgelambda.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

これにより信頼されたエンティティにedgelambdaが追加されます。

信頼されたエンティティ
ID プロバイダー lambda.amazonaws.com
ID プロバイダー edgelambda.amazonaws.com

続いて「アクセス権限」のタブに再度戻ります。+インラインポリシーの追加から以下のポリシーを追加します。

  • Lambda: GetFunction, EnableReplication (対象リソースは、先ほど登録したsubdir-redirect lambda のARNを指定)
  • IAM: CreateServiceLinkedRole(対象リソースはすべて)
  • CloudFront: UpdateDistribution(対象リソースは、展開するCloudFrontのARNを指定)

ここまでやってようやくlambda@edgeが使えるようになります。

lambdaにトリガーを追加し、CloudFrontと関連付け

仕上げにlambdaの関数詳細画面に戻ります。画面上の「アクション」から新しいバージョンを発行します。コメントは必要あれば適宜入力してください。

そののちにデザイナーから「トリガー」を追加します。トリガーの種類は、CloudFrontを選択します。ここでCloudFrontが選択できない場合はlambdaのリージョンが間違っていますので、最初からやり直してください。設定はデフォルトのままで以下のチェックボックスにチェックを入れます。

 Lambda@Edge へのデプロイを確認 
関数のこのバージョンが上記のトリガーと関連付けられ、利用可能なすべての AWS リージョン間でレプリケートされることに同意します。 

追加ボタンを押下するとCloudFrontへの更新が入ります。Distributionの更新が終わるまでしばし待つと、晴れてサブディレクトリのリダイレクト処理を利用することができるようになります。

まとめ

lambdaというと単機能のAPIや軽量サーバーとして使うイメージが強いですが、実はいろいろなところに組み込めます。lambda@edgeを利用することでCloudFrontに対してヘッダーのカスタマイズ、 BASIC認証など多岐にわたって処理を組み込むことができます。静的コンテンツに対してちょっとした動的処理を行いたいな、というときはlambda@edgeの出番です。是非ご活用いただければと思います。

面倒なところもありますが、ひと手間かけるといろいろなことができるのがAWSの良いところ。いろいろエンジニアとしていろいろHackしていければと思います。

S3+CloudFront+Route 53を使った静的コンテンツ配信

福岡拠点の野田です。

WordPressで運用していた個人サイトをメンテしなくなったので、S3とCloudFrontとRoute 53を使って静的コンテンツ配信方式に切り替えてみました。手順の大きな流れは以下のようになります。

  1. S3にコンテンツを配置
  2. CloudFrontを設定
  3. Route53でCloudFrontへ振り分け

S3 にコンテンツを配置

まずは、wget で既存サイトを取得します。

wget --mirror --page-requisites --span-hosts --quiet --show-progress --no-parent --convert-links --no-host-directories --adjust-extension --execute robots=off (サイトURL)

日本向けに配信することを考え、 S3 の東京リージョンにて新規バケットを作成して、上記取得したファイルを配置します。

S3における設定ですが、アクセス権限の設定を行います。静的コンテンツとして公開するため、以下のバケットポリシーのブロックをオフにすることで外部からのアクセスを行えるようにします。

  • 新規のパブリックバケットポリシーまたはアクセスポイントポリシーを介して付与されたバケットとオブジェクトへのパブリックアクセスをブロックするオフ
  • 任意のパブリックバケットポリシーまたはアクセスポイントポリシーを介したバケットとオブジェクトへのパブリックアクセスとクロスアカウントアクセスをブロックするオフ

バケットポリシーは、以下のようなCloudFrontからの接続を許可する設定を行いますが、CloudFront側から設定ができるため、ひとまずスキップで大丈夫です。

{
     "Version": "2012-10-17",
     "Statement": [
         {
             "Sid": "2",
             "Effect": "Allow",
             "Principal": {
                 "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity OAIのID"
             },
             "Action": "s3:GetObject",
             "Resource": "arn:aws:s3:::バケット名/"
         }
     ]
 }

CloudFrontを設定

Create DistributionでCDNを新規作成します。

  1. Web/RTMPの選択でWebを選択
  2. Origin Domain NameにS3のバケットを選択
  3. Origin Pathは空欄でOK
  4. Origin IDは任意のIDを設定(S3-バケット名みたいな感じで設定しました)
  5. Restrict Bucket Accessは、YES
  6. Origin Access Identityは、 Create a New Identity。
  7. Grant Read Permissions on Bucketは Yes, Update Bucket Policy (これが先ほどのS3バケットポリシーに反映されますので、一応S3側でも設定されているか確認)
  8. Viewer Protocol Policyは、Redirect HTTP to HTTPS (httpからhttpsリダイレクト)
  9. Allowed HTTP Methodsは、GET/HEADのみで対応(CORSを考えるとOPTIONSまでやってもいいかもしれません)
  10. Compress Objects Automaticallyは、true(圧縮化。転送量削減)
  11. Price Classはベストパフォーマンス
  12. AWS WAF Web ACLは、None
  13. Alternate Domain Namesは割り当てるドメイン名を改行区切りで入力。
  14. 証明書については、独自ドメインで割り当てる場合、ACMに登録したものを選択。
  15. 残りはデフォルトで登録

Distribution作成後、 GeneralタブでEditボタンを押下して、以下を設定します。

  1. Default Root Objectにindex.htmlを設定

続いて Restrictionsタブを選択して、GeoRestrictionをEditします。

今回は、日本のみを対象とします。全世界を対象とするとコストと直結します。1日1000円以上かかってもいい!どんな攻撃もどんとこい!という方以外は、対象を絞ったほうが良いと思います(私もこれで当初1日放置して1000円かかってしまい冷や汗、急遽制限を追加しました)。

Route53でCloudFrontへ振り分け

仕上げにRoute53からCloudFrontへ振り分けします。A(IPv4アドレス)およびAAAA(IPv6アドレス)のエイリアス指定でCloudFrontにつなげることができます。

まとめ

Cloudは設定をミスると高額な請求が発生してしまうリスクはありますが、うまく使えば個人で使っても安く運用することができます。最近では予算設定や請求が高額になりそうなときにアラートも出せる機能もありますので、そうしたものを組み合わせて、安全に運用すると良いと思います。先月からの運用の感じだとアクセス数次第なところがありますが、100円~300円/月ぐらいで運用できそうな感じでした。

初心者にはおすすめはしませんが、興味ある方は是非チャレンジしてみてください。

Swagger-PHPでOA\PathItem()エラー

福岡拠点の野田です。
OpenAPI(Swagger)の仕様書を使っていますか?

PHPでは、アノテーションでOpenAPIを定義できるSwagger-PHPというものがあります。使うためには以下を実行します。

composer require --dev zircote/swagger-php

対象のコントローラーを指定するとアノテーションで記載したコメントがAPI仕様書になるという素晴らしいライブラリです。swagger.ymlの書き出し方は、以下。

vendor/zircote/swagger-php/bin/openapi app/Http/Controllers/Api/*Controller.php -o swagger.yml

ここで少しはまりどころがあります。
OA\Infoを定義したクラスには必ずOA\GetやOA\PutといったAPIをセットで定義しなければなりません。それをしないと以下のエラーで怒られます。

Required @OA\PathItem() not found

ちょー分かりにくいエラーなので、私もはまりました。そんなときは汎用エラーレスポンスでも定義してしのぎましょう。

    /**
     * @OA\Put(
     *     path="/api/*",
     *     tags={"ErrorCommon"},
     *     description="APIエラー共通",
     *     @OA\Response(
     *          response="default",
     *          description="APIエラー時の返却データ",
     *          @OA\JsonContent(
     *              @OA\Property(property="error", type="integer", description="エラー値(0:正常/1:エラー)"),
     *              @OA\Property(property="errorId", type="string", description="エラーID"),
     *              @OA\Property(property="code", type="string", description="エラーコード"),
     *              @OA\Property(property="message", type="string", description="エラーメッセージ"),
     *          )
     *     )
     * ),
     */
    private function error() {
        throw new UnsupportedOperationException();
    }

これはライブラリ側でなんとかしてほしかったところではありますが、めげずにswaggerを使っていきましょう。

それでは、また!

nuxt.js環境を構築する

福岡拠点の野田です。

サーバーサイドでレンダリングするSSR(Server Side Rendering)を次の案件で使うことにしました。API側は慣れ親しんだLaravel。

最初に悩むのが環境構築。
どうしようか、というところで参考にしたのが、次の記事。

LaravelとNuxt.jsを同一レポジトリで管理するときの構成https://www.wantedly.com/companies/roxx/post_articles/84615

client フォルダ以下に環境を作る例ですが、とても参考になりました。以下おっかけになりますが手順になります。

install -d client/pages/.gitkeep
install -d client/assets/.gitkeep
install -d client/components/.gitkeep
install -d client/layouts/.gitkeep
install -d client/middleware/.gitkeep
install -d client/plugins/.gitkeep
install -d client/static/.gitkeep
install -d client/store/.gitkeep

nuxtは起動フォルダ配下に.nuxtという一時ファイルを作成します。このため設定ファイルをclient以下に配置して、このフォルダを起動フォルダとします。

設定ファイル (nuxt.config.js)

module.exports = {
    srcDir: '../client/',

    server: {
        port: 5000, // デフォルト: 3000
        host: 'localhost', // デフォルト: localhost,
        timing: false
    },
    css: [
        'bootstrap/dist/css/bootstrap.css',
        'bootstrap-vue/dist/bootstrap-vue.css',
    ],
    plugins: [
        '@/plugins/bootstrap',
    ]
}

起動シェル(再起動シェル)は以下のような感じで作ります。

#!/bin/bash

export nuxt_count=`grep -a "" /proc/*/cmdline | xargs -P1 -r -0 | grep -s nuxt.config.js | grep -v -E '(grep|\.sh)' | wc -l`
while [ $nuxt_count -gt 0 ]
do
    ps aux |grep nuxt.config.js | grep -v -E '(grep|\.sh)' | gawk '{print $2}' | xargs -r kill -9
    sleep 1
    export nuxt_count=`grep -a "" /proc/*/cmdline | xargs -P1 -r -0 | grep -s nuxt.config.js | grep -v -E '(grep|\.sh)' | wc -l`
done

echo "" | ../node_modules/.bin/nuxt -c ./nuxt.config.js &

ちなみにecho “” | はjenkinsから呼び出したとき、標準入力を要求されたので、それ対策で入れています。

このシェルを実行することでnuxt.jsサーバーが起動します。

nuxtは素のvueでやるよりも以下の点で優れていると思います。

  • 自動でルーティングしてくれる。
  • レイアウト機構を持っている。
  • API連携の仕組みも実装しやすい形で持っている。

VueやReactやAngularは、マイクロサービスをつなげる糊の役割をしているフレームワークだと思います。これからもっと深く使っていきたいと思います。

JQコマンドをおぼえた

福岡拠点の野田です。久しぶりの投稿です。

ある案件でAWSを扱っており、ELBからインスタンスが切り離されたか確認してほしいと連絡がありました。生憎、AWS Consoleへの接続アカウントをもらっていない状態で調べられない…と思ったのですが、aws-cliがインストールされてあるサーバーがあることに気づき、そちらで確認してみました。

ELBの一覧を表示するコマンドは以下のようなものになります。

 aws --output json --region ap-northeast-1 elb describe-load-balancers

けれども、awsのコマンドで出てくる内容はjsonで縦に長い!必要な情報だけに整理したいときに役立つのがjq(恐らくjson queryの略)コマンドになります。jsonの中からDNSNameと紐づくインスタンスを見たい場合は、以下のようなクエリをjqに投げます。

 aws --output json --region ap-northeast-1 elb describe-load-balancers | jq -r '.LoadBalancerDescriptions[] | {DNSName, Instances}'

jqコマンドの基本は、配列のフィルターと生成。.から始まる要素がフィルターされる内容になります。{}や[]で配列を再構築します。詳しいやり方は以下をご参考ください。

すぐれものなのは、jsonからcsvを作れること。以下のような感じでフィルターと配列の再構築を利用すれば、@csvでcsvの作成も楽々です。

aws --output json --region ap-northeast-1 elb describe-load-balancers | jq -r '.LoadBalancerDescriptions[] | [.DNSName, .Instances[].InstanceId] | @csv'

zabbixと連携させたりとか、 レポート出力を簡易化できないかとか夢が広がりますよね?是非、jqを使ってより良いjsonライフを!

Jmeterログを攻略する

福岡拠点の野田です。
最近ひさしぶりにJmeterを使って負荷テストをしました。

Jmeterから実行結果をログに出力することができますが、XMLかCSVかjmeter.propertiesで選ぶことができます。

XMLは、ページアクセスに起因する問合せをすべて記録することができます。一方、CSVにおいては、画像、CSS、JSなど付随情報は、明示してシナリオを作成していない限りログに記録することができません。そのため、出力はXMLで出力していたほうが広くログを残すことができます。ここは迷わずXMLを指定してください。

付随する関連ログをすべて残すためには、以下のsubresultsをtrueで指定します。

実行コマンドの例を提示します。

HTMLのみのログに残すためには以下のような処理で加工することができます。

※個別ログのtestResult+必要なXMLタグで含まれる範囲で絞り込み。その後、css/jpg/png/js/svg/gif/icoを排除。

ここまでは、XML最高!なのですが、実は大きな欠点があります。実は、XMLログからはHTMLレポートが作成できません。

そんなときどうしたらいいか。

XMLからCSVを作ればオッケーです。そこで使えるのが、XSLT。

jmeter_xml2csv.xslt

XMLからCSVを変換するコマンド例は以下。

XMLからCSVに変換したファイルを使って、以下のコマンドで晴れてレポートを作れるようになりました。

他にもコマンドラインからプラグインを呼び出すことも簡単にできます。
元のログから集計結果を得たいときは以下。

※利用にあたって、標準プラグインと呼ばれるjarライブラリをlib/ext 以下に配置する必要があります。
https://jmeter-plugins.org/downloads/old/

こちらもご参考まで。

[Go] Go言語はじめました (#1):インストール

福岡拠点野田です。
気が付けば涼しい季節になりましたが、いかがお過ごしでしょうか。

Go 言語について動けていなかったため、重い腰を上げて取り組みたいと思います。Go言語でよく使われているのは、WebAPIやメール送信・集計などのバッチ処理だと思います。javaも高速に処理ができますが重量級なイメージがあります。起動もすばやく、軽量で高速に並列処理ができるのは大きな魅力があります。

第1回目となる今回はインストールを行います。

インストール

https://golang.org/dl/

インストールは至って簡単。ダウンロードしたファイルを解凍して配置するだけ。

.bash_profileなどにパスを追加してもらえればOKです。

GOROOT というのがダウンロードして配置したGo自体のインストール先になります。

GOPATH というのが各プロジェクトフォルダに相当します。ここで開発モジュールの配置先となり、コンパイルしてできた実行ファイルが $GOPATH/bin 以下に配置されます。

Go言語初心者に向けてどのように開発を進めていくのがよいかについて深堀していこうと思います。

ちなみに go get してエラーがでるときは OS のモジュールバージョンが古い可能性が高いです。yum upgrade してすべてのモジュールを更新しておきましょう。

[Laravel] 値検査(バリデーション)について

福岡拠点の野田です。
秋雨や台風が気になりますが、過ごしやすい日々が増えてきたと思います。
今日は、Laravel の値検査の仕組みについて取り上げようと思います。

Laravel には値検査を行う設計の方向性として大きく3つの選択肢があります。
・FormRequest を継承してリクエストフォームオブジェクトを作る
・ValidatesRequestsトレイトを使う
・Validator ファサードを使う

FormRequestを作る場合

Controller に対して Illuminate\Foundation\Http\FormRequest 型のメソッドインジェクションを指定しておくとそのメソッドに対応するURLが呼び出された際に値検査がかかるという仕組みになります。バリデーションの結果が false の場合、リクエスト値をセッションに保存して、リクエストを投げた前のページに戻ります。

とても便利な仕組みですが、都度、FormRequestを実装することになります。毎回似たようなコードを書くのは煩わしいですよね。そこで以下のような基底クラスを作成して継承して使いまわすことにします。この基底クラスは、自分のクラス名からバリデーションの設定を読み込んで動作する仕組みで動いています。

以下は、config/validation.php の記述例です。FormRequest実装クラス名をキーに設定を記述するとそれを読み込んでくれる仕掛けになっています。クラスの型を利用しつつ、リクエスト値の検査は設定ファイルを利用してカスタマイズしやすくします。

さらにテンプレート側に目を向けてみましょう。入力フォームのテンプレートは、エラー表示と「戻る」ボタンで遷移の両方を共通で実現している場合がほとんどだと思います。Laravel で用意されている old ヘルパーメソッドで取得できるのは、エラー時のセッションしかありませんので、以下のような記述をすることでエラー時のセッション値があれば、セッション値、なければリクエスト値をとる実装が可能です(old メソッドのデフォルト値にリクエスト値を設定する実装になります)。

エラーを表示する場合は以下で対応できます。

$errors->has(‘email’)や$errors->count()などもよく使うメソッドだと思います。エラーは MessageBag というクラスで定義されていますので、以下を参考にしていただければ幸いです。

https://laravel.com/api/5.6/Illuminate/Support/MessageBag.html

ValidatesRequestsトレイトを使う場合

FormRequest の処理のうち Controller 側の処理を切り出したものが ValidatesRequest になります。
Controller で use ValidatesRequest をすることで Controller 中で $this->validate() メソッドなどが使えるようになります。

以下 Laravel マニュアルページより

値検査に失敗すると Illuminate\Contracts\Validation\ValidationException が発生し、FormRequest 同様、前のページに戻ります。validateをかけるタイミングを調整できるため、リクエスト値の前処理が必要な場面や FormRequest の作成をしたくない場合に使われると思いますが、Validator ファサードの選択肢もあるため、相対的に利用する場面は少ないと思われます。

Validatorファサードを使う場合

Validator ファサードを使えば値検査部分だけを部品化して値検査をすることが可能です。バッチ系で値検査を行うときは直に呼び出して使うことが多いと思います。例えばCSVインポートバッチの入力値チェックなどはこの Validatorファサードの出番です。

上記は、config/validation.php で設定を外だししている例です。個別実装することももちろん可能ですが、ある程度共通化できるところは共通化しておくと良いでしょう。

まとめ

なんだかんだいいましたが、場面場面に応じて最適な値検査の方法を選択して実装していくとよいでしょう。その中で特に伝えたかったことが「設定ファイル化」という部分になります。値検査(バリデーション)というプログラムの課題の中でconfig/validation.php にまとめておく、HTML部品という課題の中で config/form.php にまとめておく、アプリケーション設定として、config/const.php にまとめておく、などなどです。後で入力チェックをまとめるときに個別の実装をみなくてよいのは、大きな助けになると思います。まだの方は、実装時の良い習慣としてプログラムの課題の設定ファイル化を是非やってみてください。

補足

以下補足になります。入力、確認、完了のような遷移がある場合のルーティングのTIPSです。通常、入力画面は、GETリクエスト、それ以外はPOSTリクエストとしていると思います。つい忘れがちですが、保存ページについては、GETも受け付けて入力画面に逃がすとよいと思います。戻すときの遷移でリロードして、MethodNotAllowedのエラーが見えてしまうとちょっとカッコ悪いですよね。

SkypeのメッセージをDBから眺める

福岡拠点の野田です。
暑い日が続きますが、いかがお過ごしでしょうか。

Skypeが新しくなって、だいぶ使いにくくなったなぁ、と感じます。履歴をコピーしたり検索することも不自由に感じることが多くなりました。備忘録的に残していた書き込みをWikiに転載するため、どうにかまとめてコピーすることができないかと思い、少し調べてみました。

現在 2018/08/06 Windows バージョンの Skype 履歴は以下のファイルに格納されていることを確認しました。

%localappdata%\Packages\Microsoft.SkypeApp_kzf8qxf38zg5c\LocalState\\skype.db

参考:Q.how do I export my chat history?
https://answers.microsoft.com/en-us/skype/forum/skype_win10-skype_messms-skype_instamessms/how-do-i-export-my-chat-history/20849b44-d68a-40f4-8cb8-6a2dc88e9e7e

テキストエディタで開いてみたところ先頭に「SQLite format 3」と記載されているではないですか。SQLiteは、パブリックドメインの軽量なRDBシステムです。SQLをサポートしており、Skypeに限らず、いろいろなアプリケーションのデータ保持に利用されています。

SQLiteファイルへの接続ですが、ODBCで接続する方法もありますが、今回はみんなが大好きな「A5:SQL Mk-2」を使っての接続を紹介します。A5:SQL Mk-2は、ER図も描けるとても優れたデータベースツールです。今回はこれを使ってファイルを参照します。

A5:SQL Mk-2
https://a5m2.mmatsubara.com/

step 1. データベースに追加

step 2. 左下の追加ボタンを押下

step 3. SQLiteを選択

step 4. skype.db を選択します。直に接続すると破損する可能性があるため、コピーしたファイルに繋ぎましょう。

step 5.ログイン認証は表示されますが、そのまま接続できます。

step 6.  messages が書き込みテーブルです。

これでスレッドの書き込みの検索、編集も思いのままです。
無事、スレッドからWikiへの転載も完了することができました。

ブロックチェーン勉強会@Fukuoka Growth Nextに参加

福岡拠点の野田です。
梅雨が空けそうでなかなか空けないですね。今日も福岡は雨です。

昨日、Fukuoka Groth Next で行われたブロックチェーンの勉強会に参加しました。ブロックチェーンは今後システム基盤技術として大きな可能性を秘めているのは周知のことだと思います。サービスをこれから開発しようとしている方、実際に音楽やゲームにブロックチェーンの仕組みを組み込んでサービスを提供している方、いろいろな話を伺いました。中でも落合渉悟さんが行動暗号経済学というものをテーマに話をされたのですが、最高に刺激的でした。

□Cryptoeconomics Lab
https://ce.mit.edu/

□行動暗号経済学(Cryptoeconomics)とは
https://crypto-times.jp/what-is-cryptoeconomics/

行動暗号経済学は、ブロックチェーンにおける人のインセンティブ・行動を理論を設計して、研究する学問になります。まだいろいろな課題があり、それを実際に仮想通貨といったサービスなどで実証して、日々、改良が続けられているようです。ブロックチェーンが生まれるきっかけとなった2008年から始まる「サトシ・ナカモト」の論文のことを「天才が天才に考えさせる」論文であったと評されていたのですが、やはりすごかったのだと、肌で感じました。

□ビットコイン原論
https://bitcoin.org/bitcoin.pdf

□ビットコイン原論(日本語版)
http://www.kk-kernel.co.jp/qgis/HALTAK/FEBupload/nakamotosatoshi-paper.pdf

私たちもシステムを作るとき裏付けする技術要素を組み合わせてサービスを作っています。単に使うだけでなく、その背景にあるものや仕組みを理解し、日々の探求心と研究心を忘れず業務に取り組もうと意識を新たにしました。