仮想通貨で資産運用をはじめてみました

はじめに

巷で話題の仮想通貨で資産運用をはじめたので、なんではじめようと思ったのかと、はじめて見た所感を残しておきます。 資産運用をはじめた、と云っても、今は実験中なので掛け金は自分のお小遣いでやれる範囲です(泣)

ビットコインに絞って書きます。

あ、これ読んで仮想通貨買おうと思った人は、当然ですが自己責任なのでお願いします。

何ではじめたの?

もともとはブロックチェーンの内容を把握するために、対で語られることの多いビットコインについて勉強したのが発端。 ビットコインブロックチェーン、FinTechを初心者に判りやすく説明している以下の本を読んだら、 「仮想通貨良いじゃん」となり、ちょっと使ってみようという境地に至りました。

Amazon CAPTCHA

この記事は誰向け?

仮想通貨、最近テレビのCMでもやってはいるけど、怪しい感が拭いきれないような人々。

運用を始める前のビットコインの印象はどうだったか?

私自身、ものすごく怪しいものだと思っていました。 だって、資産が持逃げされたとか、運営会社が破産してパーになったとか色々聞いてたから。

この精神状態から、「仮想通貨良いじゃん、投資してみよう」という状態に変わった理由をお伝えできればと思います。

仮想通貨とは

インターネット上にだけある実体のないお金です。 これだけ聞くと、大丈夫なのか?って思いますが、ブロックチェーンという技術と1つの組織や国で管理されるものではないため、 不正が入り込みづらい環境が整っているため、インターネット上にしかないけど、セキュリティ面はどこぞの企業の基幹システムなんかよりも遥かに強力だという印象を持っています。 また、発行枚数に上限が決まっており、自由に発行できるということがないため、ある程度出尽くすと安定するのではないかという印象を持っています。

誰が運営しているの?

上記で、「1つの組織や国で管理されるものではない」と書きました。 これが表すのは、世界中の人、会社の事業に支えられて運営されているということです。 なので、例えば誰かが「金がないなら、じゃんじゃん刷ろう」という政策をしようとしても、仮想通貨ではこれができません。

どうやって運営しているの?

マイニングって呼ばれてるヤツです。 最近日本でもGMOやDMMが仮想通貨のマイニング事業を始めると発表しましたが、この行為に支えられています。 マイニングとは、仮想通貨のやり取りの記録を承認する行為です。

ビットコインなどの仮想通貨の取引は、個人対個人(P2P)で行われますが、取引の承認は第3者が行う必要があります。 これがマイニングというヤツです。

マイニングって具体的に何してんの?

仮想通貨の取引の記録は、ブロックチェーンと呼ばれる技術によって、1つの鎖に全ての取引記録を繋いでいます。 この最後尾にガチャンと新しい鎖を嵌め込むためのキーを見つける作業です。 具体的には、「直前の取引記録のハッシュ値」に、「今回の全取引データ + 任意の文字列」を連結し、これを64桁のハッシュ値に置き換えた場合に、先頭の16 - 17桁が全てゼロになる「任意の文字列」を見つけることです。 この任意の文字列は「ノンス値」と呼ばれています。

マイニングに参加すると良いことあるの?

あります。 ビットコインの場合、マイニングは10分に一度行われます。(ノンス価を見つけるのにそれくらいかかるというだけ、という印象) ノンス値を複数の人が発見することで、取引が承認されるのですが、最初にノンス値を発見した人に賞金が与えられます。 ビットコインの場合は、12.5ビットコイン(単位 = BTC)です。 2017/09/24のビットコインのレートが1BTC = 約40万円ほどなので、マイニングに勝った勝者には日本円で約「500万円」が手に入ります。 これが10分に一度発生するので、勝算があれば事業として始めるのは、自然なことだと思います。

個人でもマイニングレースに参加できるの?

できますが、膨大なマシンパワーとそれを動かすための電気代がたくさんかかるので、個人でやるのは相当気合の入った人ではないと無理です。 仮想通過の資産運用をするだけなら、破産は絶対しませんが、マイニングレースは勝てないと破産する可能性があるため、 個人では手を出さない方が良いと思います。

こんな感じのため、ビットコインやその他大口の仮想通過について云えば、 インターネット上にしかないとはいえ、自分が購入した仮想通過がいきなりなくなって、無一文になりました!みたいなことは発生しません。

とは云え、中国が仮想通貨を禁止するというニュースで大事になってるけど、問題ないの?

私の認識では、今現在はないと思っています。 中国で仮想通貨が流行っているのは、国の情勢もそうですが、電気代が安いのでマイニング事業者が多いという印象です。 中国が仮想通貨を禁止したところで、市場は一時的に売りに走られるため、価値は下がりますが、 発行枚数は変えられない状態で、安くなるというだけなので、買いが進み元に戻ります。 2017/08に中国絡みで、1BTC = 50万程度あったビットコインが30万まで価値が下がりましたが、数日で45万程度に回復しました。

今現在、仮想通貨でデイトレードしている人たちからすると、早よ下がれ!そしたら買い増して上がったら円に戻すか他の仮想通貨に移すから!規制してくれてありがとう!くらいにしか思ってないです。

仮想通貨での資産運用って儲かるの?

今現在で云えば、有名どころの仮想通貨を買っておけば硬いです。 ビットコインの場合、1日で3万程度は増減するため、1万円の投資でもうまくやれれば1日1000円程度は資産を増やしたり減ったりさせられます。

資産が減った場合を書きましたが、 買ったところから価値が下がっても、放っておけばそのうち上がる、という安心感が今はあります。 現状では完全に仮想通貨バブル状態なので、基本的に負けは有りえません。 ただ、放置はしない方が良いです。 基本は、安く買って、高くなったら売って利益を確定させるか、売るときに下がっている仮想通貨を買えば良いです。 ビットコインを持っている場合は、直接他の仮想通貨を買えます。

破産の心配ってないの?

余貯金でやっている場合は、基本的に破産はないです。 クレジットカードで買うこともできるのでそういうことをする人は知りませんが、 仮想通貨を買うためには、仮想通貨用の銀行口座が必要になります。 これは、取引するWEBサイトでユーザーを作れば勝手に作られます。 この口座をウォレットと呼ばれているヤツです。

仮想通貨は、このウォレットに振り込んだ金額分だけしか売買できないので、 自分の資産を超えた投資というのはできないため、破産の心配は先ずありません。 ※給料全額入れたり、クレジットカード振込しなければ、です。

なので、私のお小遣いでもできるというわけです。

資産運用以外に使い道ないの?

海外送金・外貨への両替、募金なんかにはものすごく使えると思います。 通常、海外送金する場合、法外な手数料を取られますが、ビットコインでこれを行うと手数料が送料の1%で済みますし、 海外旅行をするのに円を外貨に両替すると両替手数料がものすごく取られますが、ビットコインを挟むことで格安で済みます。

また、募金については、東日本大震災など災害が起こる度に募金活動が行われますが、その用途は実際不明ですよね? これを仮想通貨で募金を行うことで、その取引はブロックチェーン上に記載され永久に残るため、 本人たちに届いたのか、どういう使われ方がされたのか?などが第3者に分かるようになって透明度が増します。

その他だと電気代をビットコインで払えたりとか、つい先日H.I.Sがビットコインでの決済をはじめました。 今後、どんどん仮想通貨の利用範囲は拡大していくと思います。

どうやって始めるの?

仮想通貨の取引ができるWEBサイトでユーザー作って本人確認証を送付なり、アップロードすると、 本人確認の通知ハガキが届くのでその時点で買えるようになります。 BitFlyerが最近TVCMをよくやっていますが、私は初心者に優しいといろいろな書籍に買いてあったので、コインチェックを使用しています。

インチェックはスマホアプリもあるため、アプリを入れておけば、24/365好きなときに1タップで取引できるようになるのでオススメです。 取引は数秒で成立し結果がメールで送られてきます。 このスピード間も人気の理由だと思います。 ちなみにですが、仮想通貨の売買は手数料がかかるため、しっかり利確したら売りましょう。

いつ買う?

チャート見てると、平日の昼11時 - 15時の間は割と下がって谷がきやすい印象。 夜は21時 - 1時くらいまでの間にピークがあって、それを超えると下がり出す。 明け方(5時くらい)は大体やすい、谷ではないけど、十分利益をあげられそうな程度には低い。

最後に

疲れたので、まとめます。 仮想通貨は、

  • 不正がしづらく安全

  • 破産の心配はない

  • 値動きが速いため、うまくやれば1万円の投資で1日1000円程度は増やせる

  • 海外送金や外貨への両替に良い

これを機に仮想通貨にちょっと手を出してみるか、勉強してみると私が楽し〜!と言っている理由が分かると思います!

JavaエンジニアがPHPer(Laraveler)にクラスチェンジするためにやったこと

はじめに

会社のエンジニアにLaravelを教えないといけないっぽいので、
何をしたかを文章にして参照できるようにしておきます。

今からLaravelを始める人、PHPを始める人には参考になると思います。
※嘘です、プログラム経験が全くない人には参考にならないと思います。

ちなみに、PHPは始めて丸4カ月程度、Laravelは3カ月程度です。
それ以前はJavaやCなどを10年書いてました。

やったこと(時系列)

  1. PHPerになるためにやったこと
    以下の本を読書&写経しました。
    プログラミング言語は色々と経験があるので、文法が判ればとりあえずOKというスタンスで選びました。
    とりあえず、PHPは文字列と配列の表現が豊かというか、ほぼ半分くらいこの説明だったので、あ~こういう言語なのね、というのがよく判って良かったです。

    www.amazon.co.jp

  2. Laravelに慣れるためにやったこと
    当然、素のままPHPを使うこともなく、会社ではLaravelというWEBアプリケーションフレームワークを使用するので、それの仕組みや使い方を知る必要があるわけです。
    それには、以下の2冊を写経しました。(Kindle Unlimitedで無料)

    www.amazon.co.jp


    www.amazon.co.jp


    これで使い方や仕組みは大体判るので、普通に組めるようになると思います。
    あ、Java屋視点だと、APサーバはワーカースレッドで以て処理を行うためマルチスレッドで動きますが、PHPは1リクエスト1プロセスで動くため、
    ここを理解していると一層やりやすいと思います。
    この辺りを理解できていないと、モヤモヤしながら組むことになるので。

では、よきLaravelライフを~。

LINE Messaging APIでできることのまとめ

はじめに

仕事でLINE Botを作る機会があり、休みにドキュメントを読み込んだときのメモを晒します。

たしか、Overviewを和訳して糊付けしたヤツです。

なので、これを読むとLINE Messaging APIで何ができるのかほぼ全部判ります。

Overview

https://developers.line.me/messaging-api/overview

アーキテクチャ

LINE Platformに、企業側サーバのURLを記載する必要がある
ユーザーがあなたのアカウントを友達として追加したり、メッセージを送信したりすると、LINEプラットフォームが登録された上記URLにリクエストを送信する。

メッセージ受信とオペレーション

LINE platformから企業側サーバに情報を送信するパターンは以下。

  • ユーザがメッセージを送信するメッセージタイプ
  • ユーザが(bot)アカウントを友達として追加する操作タイプ

すべてのHTTPリクエストヘッダに署名が含まれているため、
企業側サーバは署名を使用して、リクエストがLINE platformから送信されたことを確認する必要がある。
リクエストがLINE platformから送信されていない場合、リクエストは無効であり、
予期しないイベントが発生する。

Calling APIs

LINEプラットフォームが提供するAPIを使用して、企業サーバーからユーザーに情報を送信することができる。

APIでできること

  • 個々のユーザーまたはアカウントを友人として追加したすべてのユーザーにメッセージを送信する
  • ユーザーのニックネームを取得する

サーバーはいつでもユーザーにメッセージを送信するためにAPIを呼び出すことができる。

API呼び出しが行われると、以下がリクエストヘッダーに設定され、呼び出しが企業サーバーからのものであることを確認する。

  • Channel access token or Channel ID
  • Channel secret
  • MID for your Channel

これらは、LINE Developersサイトから取得できる。

また、APIHTTPS経由でアクセスする。HTTPは不可。

Messaging APIでできること

  • push messages
    Botアカウントを友達に追加しているユーザーに直接メッセージを送信できる。(ユーザーへの単方向)
    これをやるためには、followやjoinなどのイベントが発生した場合に、送信元IDを取ってDBなどに保存しておく必要がある。
    また、unfollowやleaveが発生した場合は、保存した送信元IDなどは削除しておいた方が良い。
    unfollowやleaveした相手にはメッセージは届かないが、こちら側のアプリで余計な処理をしないようにするために入れておくとイイ。
  • reply messages
    ユーザからのメッセージに返信する。Webhooksを使用してBotアカウントへイベント通知を受ける
  • Send Imagemap messages using APIs
    イメージとリンクを含むリッチコンテンツメッセージを送信する。
    Imagemap messagesは、クーポン、特別プロモーション、ニュースアナウンス、ブログ投稿に最適
  • Template messages
    画像、テキスト、複数のユーザーアクションの選択肢、ボタンなど、さまざまな種類のテンプレートメッセージを送信します
  • Use your bot in groups and rooms
    グループチャット、1対1チャットでユーザーと交流できる

APIリファレンス

https://devdocs.line.me/ja/

構成コンポーネント
  • Webhooks
    友だち追加情報やユーザから送信されたメッセージをリアルタイムに受信する仕組み
  • Reply Message
    ユーザから受信したメッセージやイベントに対して返信する
  • Push Message
    任意のタイミングでユーザにメッセージを送信するAPI(要PROライセンス)
  • Multicast
    複数のユーザに任意のタイミングでメッセージを送信するAPI(Push Messageの複数版)
  • Content
    ユーザから受信した画像や動画、音声をダウンロードするAPI
  • Profile
    ユーザのプロフィール情報を取得するAPI
  • Leave
    参加したグループやトークルームから退出するAPI
LINE Bot SDK

for PHP(https://github.com/line/line-bot-sdk-php)

Status Codes list

| Status Code | Description |
| 200 | OK |
| 400 | Bad Request. リクエストの仕方に問題あり |
| 401 | Unauthorized. Authorizationヘッダを正しく送信できていない |
| 403 | Forbidden. APIの利用権限がない |
| 429 | Too Many Requests. アクセス頻度が制限を超えた、超えている |
| 500 | Internal Server Error. LINEのサーバ側エラー |
> Sorryコンテンツ返却時のコードを追加してくれると嬉しい

実装の流れ(Webhook)

  1. リクエストヘッダの署名検証
  2. 受信イベントごとの処理
  3. レスポンス返却
制約
  • WebhookのHTTPS POSTに対しては、常に200 OKを返す
  • WebhookのHTTP POSTリクエストが何れか失敗しても、リクエストは再送されない
署名検証

リクエスト送信元がLINEであることを確認するために、署名検証を行わなくてはいけない。

各リクエストの「X-Line-Signature」ヘッダと
リクエストボディとChannel secretから計算したものが同じであることを必ず検証する。

この部分はSDKでメソッドが提供されているので、それを呼ぶだけで実現できる。

Webhook event object

LINE Platformで発生したイベントを表すJSONオブジェクトで以下がある。

  • Common Fields
    全イベント共通で含まれるフィールドで、以下が含まれる
  1. type
    typeでイベント種別を識別できる。以下がある。
    • message
      メッセージが送信されると発生
    • follow
      イベント送信元に友だち追加 or ブロック解除されると発生
    • unfollow
      イベント送信元にブロックされると発生
    • join
      イベントの送信元グループまたはトークルームに参加すると発生
    • leave
      イベントの送信元グループから退出させられると発生、自分で退出した場合は発生しない
    • postback
      イベントの送信元が、template messageに付加されたポストバックアクションを実行すると発生
      ※選択肢から選んだ、などが起きた場合。このイベントへは返信可能。
    • Beacon event
      イベント送信元のユーザがLINE Beaconデバイスの受信圏内に出入りした場合に発生
      ※一部の企業・ユーザに限定開放しているらしく、今後オープン化していくとのこと。このイベントへは返信可能。
      >> 色々応用が利きそうなので、将来これだけで何かできるかも。
  2. timestamp
  3. Source user
  4. Source group
  5. Source room(複数人トークのこと?)

※1以外は使ったことないので、特に見てないです。

Message event

メッセージが送信されたことを示すEvent Object。
メッセージの種別には以下がある

  • text
    テキストメッセージ
  • image
    画像、別のAPIでバイナリデータにアクセスする
  • video
    動画、別のAPIでバイナリデータにアクセスする
  • audio
    音声、別のAPIでバイナリデータにアクセスする
  • location
    位置情報(住所、緯度経度)
  • sticker
    スタンプ
Reply message

返信可能なイベントには、replyTokenが含まれているため、これを使用してイベント送信元に返信する。
以下の制約がある

  • 一定秒以内に使用しないと無効になる
  • トークンの有効期間は1回の返信まで
    重たい処理を間に入れると事故りそうなので、そういう場合はどこかにuser_idを保存しておき、push messageで送った方が良い
Push message

企業側サーバから任意のタイミングでメッセージを送信するAPI
Push messageに対応するプランでのみ使用が可能

5件までまとめてメッセージを送信できる

Multicast

基本的にPush messageと同じだが以下が異なる

  • 複数のユーザにメッセージを送信可能
  • グループ、トークルームにはメッセージを送信できない
Send message object

送信するメッセージのオブジェクト
reply、push、multicastでこの様式を使用する
送信可能なメッセージ種別は以下がある。

  • text
    2000文字以内のテキストメッセージ
  • image
    オリジナルJPEG画像とプレビューJPEG画像のURL(HTTPSで1000文字以内)を添付する
    画像のサイズはそれぞれ以下
    オリジナル : 縦横最大1024px、最大1MB
    プレビュー : 縦横最大240px、最大1MB
  • video
    MP4動画とプレビューJPEG画像のURL(HTTPSで1000文字以内)を添付する
    動画と画像のサイズはそれぞれ以下
    動画 : 長さ1分以下、最大10MB
    プレビュー : 縦横最大240px、最大1MB
  • audio
    m4a音声のURL(HTTPSで1000文字以内)を添付する
    音声のサイズは
    長さ1分以下、最大10MB
  • location
    位置情報を送る
  • sticker
    スタンプを送る、有料のものは識別子が非公開であるため、買って調べるしかない。(そもそもLINE@で勝手に使って良いのかという問題もある)
  • imagemap
    リンク付きの画像コンテンツ。画像全体を1つのリンクとしたり、画像の複数の領域に異なるリンクURLを50個まで指定できる
    base URLの末尾にクライアントが要求する解像度を横幅サイズ(px)で付与してくるため、そのリソースパスに画像を置いておく必要がある

 

リンクで実行できるアクションには以下がある。

  • URLアクション
    WEBページへ飛ばす
  • Messageアクション
    400文字以内のメッセージを送信する(何に使うのか思いつかない)
    タップ領域はImagemap全体の幅を1040pxとして、左上を原点に座標と長さをそれぞれ指定する
  • template
    あらかじめ定義されたレイアウトのテンプレートに、カスタムデータを挿入することによって構築するメッセージ
    Template messageは、iOS版およびAndroid版のLINE 6.7.0以降で対応
    以下のテンプレートがある。
  1. Buttons
    画像、タイトル、テキストと、複数のアクションボタンを組み合わせたテンプレートメッセージ
    Buttonsテンプレートには表示上の高さ制限があり、text表示領域の高さが一定以上になると領域の下部がカットされる。 このため、文字幅によっては、文字数制限範囲内であってもテキストが全文表示されない場合がある。
  2. Confirm
    2つのアクションボタンを提示するテンプレートメッセージ
  3. Carousel
    Buttonsを複数並べて提示できるテンプレートメッセージ
    > 画像の有無、titleの有無、アクションの数は、全てのカラムで統一する必要がある

また、テンプレートメッセージに付加するアクションには以下がある。

  1. Postback action
    dataフィールドで指定された文字列がpostback eventとしてwebhookで通知される
    また、textフィールドを指定した場合は、その内容がユーザの発言として同時に送信される
  2. Message action
    textフィールドに指定した文字列が、その内容がユーザの発言として同時に送信される
  3. URI action
    uriで指定されたURIを開く
    uriには、http、https、telを指定可能

Content

ユーザから送信された画像、動画、音声のバイナリデータにアクセスするAPI
コンテンツはメッセージが送信されてからある期間経過した時点で自動的に削除される。保存される期間についての保証もない。

Profile

ユーザのプロフィール情報を取得するAPI
以下が取れる

  • 表示名
  • ユーザ識別子(送信元IDなどにセットされるもの)
  • 画像URL
  • ステータスメッセージ(設定で、ひとこと入れられるもの)

Leave

グループまたはトークルームから退出するAPI

実装について

基本的にSDKでメソッドが提供されているなので、そちらを使いながら実装すればOK。
実際に使って実装したが、難しくなかった。

[Github]

GitHub - line/line-bot-sdk-php: SDK of the LINE Messaging API for PHP

[PHP APIリファレンス]

line-bot-sdk-php

 

DynamoDBのドキュメントを結構読み込んだので、必要だと思ったことの要点まとめ

はじめに

仕事でDynamoDBと戯れる機会があり、
そのときドキュメントを結構読んだ(多分8割くらい)ので要点・思ったことをメモりました。

実装面などについての記載は、AWS SDK for PHP視点になります。

基本事項

以下を参照すれば、基本的なことは大体判る
よくある質問 - Amazon DynamoDB | AWS

物理的な特徴

  • パーティション
    自動的にテーブルパーティション全体にデータが分散され、AWS Cloud の複数のサーバーにデータが格納される。
    つまり分散ストレージであるため、データが均一で登録されるような設計・実装が肝になる。
    これは1つのパーティションに対して負荷がかかり過ぎないように調整することと同じであるため、IOのパフォーマンス安定化に繋がる。
  • 読み込みキャパシティーユニット
    最大サイズ 4 KB の項目について、1 秒あたり 1 回の強力な整合性のある読み込み、あるいは 1 秒あたり 2 回の結果的に整合性のある読み込みを表す。
    4KBデータ未満の読出しは切り上げられるため、例えばこの値を「1」に設定した場合は、1秒間に1回の結果的に整合性のある読み取りしか行えない。
  • 書き込みキャパシティーユニット
    最大でサイズが 1 KB の項目について、1 秒あたり 1 回の書き込みを表す。
    1KB未満のデータは1KBに切り上げられるため、例えばこの値を「1」に設定した場合は、1秒間に1回の書き込みしかできない。
  • データサイズ
    各データレコードのサイズには、属性値の他に、属性名も含まれる

扱えるデータ型

  • S – 文字列 UTF-8 バイナリエンコードUnicode
  • N – 数値 有効桁数が最大 38 桁
  • B – バイナリ
  • BOOL – Boolean
  • NULL – Null
  • M – マップ
  • L – リスト
  • SS – 文字列セット
  • NN – 数値セット
  • BB – バイナリセット

各型の詳細は以下を参照

docs.aws.amazon.com

設計時に注意すべき特徴

  • Primary Keyは「HASH」 or「HASH + Sort」のどちらかのみで、キーに使用できるものは最大2つまで。
  • 書き込み先のパーティションはPKに依存するため、特定のパーティションに読書が集中しないように、キーにサフィックスを付ける。
  • テーブル名が同じでもリージョンが異なれば別テーブル扱いになる。
  • 時間単位にキャパシティユニットを大きく超えるような高い読み書きを行うとスロットリングが働いて「ProvisionedThroughputExceededException」が返ってくるので、キャパシティユニットを厳密に管理したいことがある場合は、リクエストの流量に注意を払う必要がある。
  • 大量データ書込みを行う場合、その見込みデータ数を書込みキャパシティプランに設定する必要がある。また、マルチプロセス or マルチスレッドで以てデータの書込み要求を行わないとパフォーマンスが失われる。
    処理時間は書込むデータ数を、いくつのプロセスから分散して25件 * N回の書込み要求をかけるか、である。

実装するときの注意事項

  • テーブル作成は、Primary Keyのみ生成。
    RDBだと構成を全部書くけど、DynamoDBはデータ登録時に属性が作られる
  • scanは公式に書いてあるとおりで、データが大量に保存してあるテーブルには使わない。
    scan自体使わない方針にすると良い。(手抜きで使うとコピペされる危険性の排除)
  • BatchのAPI(BatchWriteItem/BatchGetItemなど)を使用する場合、すべての処理がコケない限りは失敗はせず、個々で失敗したものはリクエストのキーと値が返される。
  • 書込みキャパシティプランをケチって、マルチプロセスで大量データを書いた場合、一部のプロセスで書込みエラーになる可能性がある。キャパシティプランをケチる場合は、シングルプロセスから書いた方がエラーの発生率は下がる。
    自分で試したところだと、
    10WCUで1プロセスから1万件データを25件ずつバルクで書き込んでもエラーにならなかった。

運用するときの注意

  • インデックスを後から付けた場合、テーブルの状態のBackfilling がfalseになるまでインデックスは使われない。
  • 大量のデータが登録されているテーブルに後からインデックスを付与すると時間がかかる。

API

  • CreateTable : テーブル作成
  • UpdateTable : テーブルのプロビジョニングしたスループット値を更新
  • DeleteTable : テーブルの削除
  • DescribeTables : テーブルの状態取得
  • ListTables
  • PutItem : データを1件登録
  • BatchWriteItem : データを最大25項目まとめて登録ただしデータ量はMAX16MB、かつ個々の項目は400KBまで
    ここでいう書込みとは、項目の作成・更新・削除を表す
  • UpdateItem : データを更新
  • DeleteItem : データを削除
  • GetItem : データを取得
  • BatchGetItems : データを最大100項目まとめて取得 ただしデータ量はMAX16MB
  • Query : 検索

良いところ

  • JSON作って投げるだけでデータの操作ができるので手軽。
    AWS SDK for PHP使うと連想配列を作って渡すだけ。
  • 基本的にオンラインでテーブルのチューニングができる。
    重たい処理をする前に、キャパシティをオンラインで拡張しておき、その処理が終わったら元に戻す、といったチートプレイが可能。
  • 登録データのパーティション(分散ストレージ)を均一化させることで、データがどんなに増えてもIOのパフォーマンスが安定する。

残念なところ

  • 一括登録、更新、削除のAPI(BatchWriteItem)の使い勝手が悪い
  • 範囲系の条件が作れないのはしんどい。(が、教授するメリットの方が大きいという認識を得た)
  • BatchWriteItemで型指定しないといけない。
  • BatchWriteItemは型指定をしないといけないのに、値は全て文字列でないといけない(AWS SDK PHP)
  • APIドキュメントの読みづらさが異常

他サービスとの連携

  • タグ
    タグをつけておくと、EC2やS3など、他のAWS上のサービスでタグがサポートされているものと連携してレポートを出すときに活用できたりする。
    DynamoDBでは、タグが付けられたテーブルに関連するローカルセカンダリインデックス (LSI) およびグローバルセカンダリインデックス (GSI) は、自動的に同じタグでラベルが付けられる。

    DynamoDB のタグ付け - Amazon DynamoDB

困ったときの回避方法

  • 属性名がDynamoDBの予約語と被ったら
    式の属性名を付ける(DBのas 別名相当)
    Commentは予約語だが、以下のようにするとイケる
     {"#c":"Comment"}
    ※#は必須

補足

色んな解説見て意味不明だったものを記載

  • グローバルセカンダリインデックス(GSI)
    テーブル作成時のPKとは別に、他の属性でPKを作れる。
    テーブルのPK同様、Partision KeyとSort Keyの組み合わせで指定可能
  • ローカルセカンダリインデックス(LGI)
    テーブル作成時のPartision Keyと任意の属性をSort Keyに指定してPKを作れる。

 所感

アプリ屋としてDynamoDBを使うときは、
以下のAPIだけ使えば基本的には良いという印象を持ちました。

  • BatchWriteItem
  • Query

理由

  1. テーブルの作成・削除はアプリ屋では行わない
  2. データの書込みはまとめて送りたい
    ※他のAPI使うと1件しか書込めないので使う理由が見当たらない
  3. データ取得の条件は柔軟性を担保したい

あとは、読書するデータ量が肝なので、このあたりの想定容量をデータの整合性を保つ必要があるときはJSONなど駆使して保ちつつ最小化できるように、テーブル設計してあげれば、地雷はあまり踏まないで使いこなせそう。

書評:レガシーソフトウェア改善ガイド

Kindle版、Amazonポイント50%還元キャンペーン中に、技術書を大量買いしたときの1冊。
ずいぶん前に読み終えたけど、久しぶりにパラパラ眺めながら何が書いてあったか纏めておきます。

誰向け?

* 日々レガシーシステムと格闘していて何とかしたい人
* 新しい技術に興味がある人
* 何か新しいことを学びたいけど、何が良いか判らない人
* 新しい技術を仕事で使いたい人(レガシーシステム関係なく)
* 保守中のシステムに対して改善提案したい人

レガシーシステムを改善するためのガイド本なんじゃないの?
と思われるかもしれませんが、
私が読んだ感想としては、私の中では新しい技術を使うプラクティス本的な位置づけです。

向かない人は?

本書に興味がない人
※勉強熱心な全てのエンジニアに読んでもらいたいです

どんなことが書いてあった?

中途の人が新しい職場に転職して、出社初日に開発環境の構築に四苦八苦したり、
良かれと思って直したコードが、他のところに影響してしまったとか、
システムのリライトしたら、過去のバグを再発させたとか、
そんな、保守案件・保守開発のあるある話に対する改善方法を提示してくれています。

ツール類は?

DevOps界隈で言われているツールが殆どです。

これ見てる人にとっては、当たり前に使っているもの・特に使ってないけど、どんなものかは知っている、というものが殆どです。

新しいモノの使い方について

「とにかく一気にやり過ぎない。何かを始めるのは1つまで。」

これは新しく何かを作るときも同様で、新しいことをやったら大抵の場合地雷を踏んでプチ炎上状態の中、問題をクリアしていくことになります。
これは成長するために必要な失敗と成長を体験するために必要な儀式なので、問題ないです。
ただ、新しいことを複数行うとプチ炎上が重なり、大炎上する可能性が、まぁ指数関数的に上がります。
なので、保守・新規に関係なく、新しいことを始める場合は、1案件1つまでにしましょう。

という、納得のことが書いてありました。

私も、新しいことは1案件1つまでと決めてやってます。
もちろん、すんなりことが運んで、もう1個くらいイケたな!と思うことはありましたが、
嵌れば1週間くらいは簡単に溶けるので、2個以上は手に余るので、上手くいった次も1個しか新しいことはしません。

ただ例外もあります。
自分にとっては新しいことでも、熟練者がいるときです。
多くの組織では、熟練者にその部分を担当してもらうと思いますが、これは自分でぶんどれます。
で、自分の判る領域を別の人に回す。
誰かがプチ炎上状態になっても、その領域の熟練者がいるので即鎮火できるので、ほぼノーリスクで新しいモノのノウハウが溜まりますし、
プロジェクトメンバー間で共有すれば、自分がやってない部分のノウハウも身に付きます。(実際には自分で手を動かさないと厳しいと思いますが、あの人ここでハマってこう解決した、というのを聞いていれば解法を導くのが時短できます)

リファクタリングの仕方について

テストを書きましょう!といういつものヤツが書かれています。
新規開発では、まぁ書きましょう!となりますが、テストコードがないレガシーシステムはどういうアプローチでやるの?
ということが丁寧に書かれています。
レガシーシステムについては、有りものを正義とみなして、仕様化テストを書くと良いよ!ということが書かれています。
この辺はちょっと前にテストコードを書いてこなかった人向けに資料作って発表しているので、参照頂ければ。

www.slideshare.net

 

あまり触れられないコストについて(追記分)

絶対に書こうと思って書き忘れたので追記します。
日々の生産性やリリースまでのリードタイムなどはよく取り上げられますが、
人の受け入れコストについて触れているのが本書の特徴です。
特に開発環境の構築は、無駄コストとして扱っています。
確かに、新しいプロジェクトに入ると1〜2日、酷いと3日は開発環境を構築している人、居ますもんね。
一人なら良いですが、人の出入りが激しいと、この工数はバカになりません。

その解決手法はVagrantやDockerを使って開発環境を自動で構築して手間を省こうというものです。

また、新しい人を受け入れて、どの程度で周りと同じ程度の生産性になるかについても言及しています。

最後に

なんやかんやと色々理想が書かれていますが、作者も言っている通りで、
やれること、やれそうなことを無理のない範囲で行っていけば気付いたら脱レガシーになっているだろうし、エンジニアとして色々知見も溜まって良いですね。
私も立ち止まらないように色々チャレンジしていかねば!

レガシーソフトウェア改善ガイド (Object Oriented Selection) | クリス・バーチャル, 吉川 邦夫 |本 | 通販 | Amazon

書評:エラスティックリーダーシップ ―自己組織化チームの育て方

タイトル的に気になっていた本書。

住んでる近くの図書館に本を返しに行ったら、新書の棚に置いてあったので借りて読んでみました。

最近の図書館って発売したての本も置いてあるんですね〜。

新書過ぎてびっくりしました!

読んでみた感想としては、

「手元に置いてたまに読み返したいかな〜」

という良書です!

 

# 誰向け?

以下の人々に読んで欲しいかな

* 人の成長に興味があると、口だけは言っているマネジメント

*人の成長に興味があると、口だけは言っているプロジェクトリーダー

* チームリーダー or その予備軍

 

割と過激な書き方をしましたが、本気で人の成長を望んでいる人は行動で出来てる(自分自身やってもらった)ので、

口だけ、と書いてしまいましたが、どうやったら良いのか分からない人たちに読んで欲しいですね。

チームリーダーとその予備軍は、是非読んで実践してみて欲しいです。

 

 

# 向かない人は?

* リーダー層ではない人たち

今読むと、理想とのギャップで現職が嫌になるかもしれないので。

ただ、プライムでやってる人たちは、社内政治的な世界で殴って勝ち取れるかもしれない理想なので、読んだ方が良いかも。

 

# どんなことが書いてあった?

チームの状態を

* サバイバルモード : 自分の仕事でいっぱいいっぱい状態

* 学習モード : 学習しながら仕事に取り組める余裕ありな状態

* 自己組織化モード : 端的に言うと、YWT(やったこと・わかったこと・次やること)を自主的にやるような状態

 

各モードの関係と、何が起きると他のモードに遷移してしまうのか、
各モードでどんなリーダーシップを取ると良いのかと言ったことが書いてありました。

リーダーも自分のマネジメントスタイルをメンバーに押し付けるのではなく、
自分のチームの状態がどのモードに居るのかによって、変わっていくことが重要とのことで、これは確かにそうだし、自分自身全く出来てなかったかな〜と自省してます。

リーダーとしては、当然サバイバルモードは避け、
学習モードから自己組織化モードを目指すべき時代のようです。確かにそう思います。
たまに、あのリーダー何もしてくれないけど、プロジェクトは順調なんだよ、あのリーダー要らなくね?
と言う場面があると思いますが、それはリーダーが上手いことバランスを取ってくれていて、チームが自己組織化モードに居るという可能性が高いので、
間違っても「あのリーダーが不要」と言うのは辞めましょうw

平和なのには訳がちゃんとあるのです。

脱線しましたが、上記のモードを懇切丁寧に解説してあります。

だいたいここまでで、本書の半分程度。

残りの半分は、じゃあ何すれば良い?というのが延々と書いてあります。
これはこれで面白いですし、実際にやるときには、どういうこと気にしなきゃいけないんだっけ?というのを読み返してからやろうと思えます。

 

# 最後に

自分自身うまく出来てなかった部分も多いので、しっかり自戒して取り組みたいと思います。

あと、この本は買おうと思います。手元に欲しいw

 

ちなみに今のチームの状態は「学習フェーズ」です。

自己組織化フェーズは、多分会社としてそういう文化がまだないかな〜と言う状態ですね。

サービスを提供する会社なので、会社が潰れそうにならない限りは、サバイバルフェーズに移行することはないだろうけど、そうならないように意識だけはしとこ。

 

www.amazon.co.jp

 

バイザーに入社して2ヶ月経った

2017/4末で大手SIerを退職し、5/1からバイザー株式会社という俗に云うWeb系にクラスチェンジしました。

 

で、2ヶ月経ったので、どんな感じか書いてみます。

ちなみに試用期間3ヶ月なので、もう1月は試用人ですw

 

# バイザーってどんな会社?

自治体に向けて情報を発信するためのサービスを開発している会社です。

すぐメールというのが主力サービスで、自分の生まれ故郷の某所にも導入されていたりと、多分知らず知らずのうちに使っている人、めっちゃ多いと思います。

 

# なんで入ったの?

これから色々やっていきたいということで、話していて貢献できそうなことが多いと感じたためです。

Web系の企業だとスタートアップ時やよほど大きい会社でもない限りは、基本的にリリース済みのサービスの保守とエンハンスがメインになるようですが、

運良く転換期に出会え、バリバリコード書ける&フットワーク軽そう&面白そうなサービス持ってる&名古屋でサービス開発できるの超貴重!っていうので、選びました。

 

# 入ってどう?

入社前と後で特にギャップもなく楽しく働けています。

時間の使い方は前職とあまり変わらない感じで、

プロダクト開発8:情報収集2程度の比率を確保できています。

前職の時は情報収集しても開示する先がなかったですが、

現職では Slackを使っているので、面白かったもの・今後役に立ちそうなモノなど、

コメント入れてSlackに投下してます。

それを見て反応を貰える&どんどんやって欲しいと言われているので、どんどんやっている状態ですw

 

スキル的には、はじめの2〜3週間くらいはPHP + Laravelという初物部分で多少戸惑いましたが、最近は癖もだいぶ掴んできたので、スラスラ書けるようになってきたかなと思います。

 

あと、開発するPC環境はめっちゃ快適です。

多分Web系だと普通のレベルなのかもしれませんが、前職と比較すると天と地ほどの差があります。

 

# クラスチェンジするに当たって不安はなかった?

プログラミング言語は方言だ!と言える程度のスキルは持ち合わせているので、あまり不安はなかったです。

初日全社員の前で挨拶しろと言われていたので、スベらない自己紹介についての不安はありましたが・・・w

 

# 今後は?

お互いにミスマッチな部分も特になく、長く働いて事業・人員育成に貢献できれば!と思っています。