LINEに通知を送る

file_get_contents()を使う記事はあったのですが、自分の環境では動かなかったため、curlを使う方法を調べてみました。

(追記)Guzzleというライブラリを利用するとシンプルに書けました。

関連記事: LINE Notifyを使って、PHPとGuzzleでLINEに通知を送る

目次

  • curlを使ったコード
  • コードの解説
  • 参照した記事

curlを使ったコード

<?php
$token = 'トークン';

// リクエストヘッダの作成
$message = 'Lineに通知を送ります';
$query = http_build_query(['message' => $message]);
$header = [
        'Content-Type: application/x-www-form-urlencoded',
        'Authorization: Bearer ' . $token,
        'Content-Length: ' . strlen($query)
];

$ch = curl_init('https://notify-api.line.me/api/notify');
$options = [
    CURLOPT_RETURNTRANSFER  => true,
    CURLOPT_POST            => true,
    CURLOPT_HTTPHEADER      => $header,
    CURLOPT_POSTFIELDS      => $query
];

curl_setopt_array($ch, $options);
curl_exec($ch);
curl_close($ch);

実行した結果

リクエストに成功すると、curl_exec($ch){"status":200,"message":"ok"}"と返ってきます。

LINEの通知

LINEに通知しますというメッセージ

コードの解説

$tokenに取得したトークンを代入する

トークンの取得の方法は下記記事をご参照ください。 [超簡単]LINE notify を使ってみる

$messageに通知する内容を書く

LINEの通知画像に出ている**[bot]**は、 トークンを発行する際に自分で設定する文字列です。

また、配列$dataにパラメータを追加することで、画像を送ることもできます。 (対応しているパラメータについてはLINE Notify API Documentを参照)

curlのオプションの説明

curl_setopt(PHPマニュアル)より引用

オプション解説
CURLOPT_RETURNTRANSFERTRUE を設定すると、curl_exec() の返り値を 文字列で返します
CURLOPT_POSTTRUE を設定すると、HTTP POST を行います。
POST は、 application/x-www-form-urlencoded 形式で 行われます
CURLOPT_HTTPHEADER設定する HTTP ヘッダフィールドの配列
CURLOPT_POSTFIELDSHTTP “POST” で送信するすべてのデータ

デバッグのTips

上記コードをコピペしてトークンを書き換えるだけで通知がくるようにはなりますが、 念のためcurlのデバッグに役立つ情報も書き添えておきます。

送信したリクエスト文字列を取得する

手順

  1. 配列$optionに CURLINFO_HEADER_OUT => true を追加する
  2. var_dump(curl_getinfo($ch, CURLINFO_HEADER_OUT)) でリクエスト文字列を表示

実行結果

POST /api/notify HTTP/1.1
Host: notify-api.line.me
Accept: */*
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer トークン
Content-Length: 84

Content-Typeやトークンが送信されているのがわかります。 トークンが無効である場合は下記のステータスコードが返って来ます。 {"status":401,"message":"Invalid access token"} その場合はトークンを再発行しましょう。

サーバーからのレスポンスを表示する 手順 var_dump($response); を追記する

実行結果

"HTTP/1.1 200 OK
Server: nginx
Date: Mon, 23 Apr 2018 09:53:55 GMT
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=3
X-RateLimit-Limit: 1000
X-RateLimit-ImageLimit: 50
X-RateLimit-Remaining: 989
X-RateLimit-ImageRemaining: 50
X-RateLimit-Reset: 1524480281
  • Date: Mon, 23 Apr 2018 09:53:55 GMT

DateがGMTになっていることがわかります。 日時が入った通知を送信する場合、下記のコードでタイムゾーンを設定する必要があります。 date_default_timezone_set('Asia/Tokyo');

  • X-RateLimit-Limit: 1000

これは1時間のAPI callの回数の上限を表します。 一時間で1000回までcallできるということです。 X-RateLimitの見方は、LINE Notify API DocumentのAPI Rate Limitに記されています。

参照した記事

PHPLINE
プログラミングをするパンダ
プログラミングをするパンダ (@Panda_Program)
Software Engineer

日々大量に発信される情報に振り回されないために、情報を選別するプロセスを導入する

エンジニアに情報収拾は欠かせません。技術は日進月歩で進化し、日々新しいツールが登場します。最新情報をキャッチアップすることは、エンジニアの基本動作です。

しかし、最新情報を追うだけでは不十分です。技術は過去の積み重ねの上に成り立っているからです。

データ構造、アルゴリズム、通信の仕組み、プログラムが動作する仕組み、ソフトウェア設計、SOLID原則などオブジェクト指向のベストプラクティスなど、既に議論され尽くされている基礎的な箇所も押さえておかなければなりません。

私は主に、TwitterとGoogle Discoverで情報を集めています。また、会社のSlackで紹介される技術記事もチェックしています。

しかし、ただ「気になる」という理由だけで全ての記事を読んでいては、時間はいくらあっても足りません。また、漫然と読むだけであれば、知識は脳に定着しません。

時間という万人に与えられた平等なリソースを「情報収拾」という名目で無駄遣いしないために、以下のように情報を選別する仕組みを導入しました。

3ヶ月ほど自分で運用してみて手応えを感じたのでご紹介します。

Slackチャンネルに後で読むブログを投稿しておく

その方法は、個人のSlackにblogを積ん読するためのチャンネルを作り、気になった記事のURLを投稿するという方法です。

以前はPocketを使っていましたが、SlackにURLを貼り付けた際にTitleやDescriptionが表示されるため、見返しやすさを取ってSlackを使うことにしています。

SlackのチャンネルにURLを投稿している

新しい情報を見つけた時の思考プロセスは以下の通りです。

1. 自分が興味のある記事か否か
        → Noならスルー
2. まさに今直面している課題を解決する記事であるか
        → NoならSlackにURLを貼る
3. 記事を読んだ後、人に紹介したりまた読む価値がある記事だったか
        → Yesなら、SlackにURLを貼る
        → Noなら、何もしない

上記では記事と書きましたが、URLでアクセスできる情報全てが対象です。

例えば、ツールならGithubのレポジトリのURLや、公式ドキュメントのページでも構いません。もちろんイベントで発表されたスライドでも構いません。教育系のYouTubeやPodcastも対象です。

今の自分に必要な情報であるか否かを判断するプロセスにより、「記事を読みたいけど時間が取れなくてまだ読んでいない」という罪悪感を免れることができます。

なぜなら、その情報は自分が必要になった段階でアクセスすれば十分であり、「読んだけど結局忘れてしまった」という時間の無駄遣いを避けることができるからです。

これは必要になった時に必要な箇所だけ勉強するという遅延評価勉強法にも通じるアプローチです。

効率よく知識を定着させる2つの方法

ここまでは、「今必要か」「直面している課題を解決するものか」という観点から情報を振り分ける方法を紹介しました。

ここからは、効率よく知識を定着させる方法についてご紹介します。ポイントは2つです。

1つは、知識を他の知識と関連付けること、もう1つは、問題意識を持って実際に手を動かして触ってみることです。順番に紹介しましょう。

ある知識を自分が知っている別の知識と関連付ける

人間の脳は、自分に関係ない独立した知識をすぐに忘却してしまいます。新しく得た知識は自分の過去の経験に紐付けるか、エピソードという形で語られる他人の経験、または歴史に関連を求めることが最適です。

「愚者は経験に学び、賢者は歴史に学ぶ」とはかつてのドイツ帝国の宰相ビスマルクの言葉ですが、自分の経験だけでは広大な世界知り尽くすことはできません。

新しい情報に接した時は、経験から得られた教訓や他人のエピソード、歴史といった自分の知っていることと結びつけて解釈しましょう。そうすることで、全く新しい情報に接した時でも、自分の視点から何かを語ることができます。

(既存の知識と関連付けて知識の定着させることに関しては「イシューからはじめよ」にも記載されています。著者の安宅さんが脳科学を研究されていたので、ニューロンの仕組みなど軽く触れられていて印象的でした。)

問題意識を持って手を動かし、振り返りをする

次に、ツールや手法であれば実際に自分で試してみることです。自分の手元でプロジェクトを作って実際に触ってみるのが一番いい方法です。

動作環境を構築するのが面倒なら、JavaScriptならcodesandboxTypeScriptのPlay Groundや、Paizaといったオンラインエディタが便利です。

アーキテクチャやデザインパターンを試すなら、少しコード多くを書く必要があります。

一方、何にも銀の弾丸はなく、ある問題を解決しても別の問題が生じるのはエンジニア界隈では常識です。

ツールでもアーキテクチャでも、プロダクションに取り入れる前にトレードオフを可能な限りはっきりさせておきたいものです。そのためには必ず手元で技術を触ってみて開発体験を確認してみましょう。

そして、その解決方法は、自分が直面している課題を解決するものかを自分に問いかけてください。

解決するのであればその理由を、解決しないのであればその理由を省察してください。

学習における省察の重要性については、以前本ブログで記事を書きました。

プログラミング学習における「コードの写経」は是か非か。質の良い振り返りのための経験学習モデル

省察により、教訓を引き出し、次の行動に繋げましょう。

「積ん読」のURLを知識の体系にマッピングする

知識は別の知識と互いに関連を持ちます。ツリー構造でもグラフでもいいので、体系化してみましょう。

ロジックツリーやマインドマップを描くイメージです。これをするとしないとで、記事を読んだ時に知識の吸収力に大きな差が生まれます。

慣れてきたら、記事を読む前に「この内容は、ある分野のこのパートについて書いているのだな」とだいたい当たりをつけられます。

この当たりをつける段階で、自分が必要としていないことなら、Slackの積ん読チャンネルにURLを貼り付けるという判断をすることもできます。

(例)Reactにおける「Prop Drilling」の記事の位置付け

例を挙げてみます。例えば自分は、「常々、Reactについて勉強したいと思っている」とします。

そこで、会社のSlackのチャンネルでKent C. Dodds氏がReactに関するProp Drillingの課題を論じたブログが紹介されたとします。

その記事に飛びつく前に、少し考察をしてみます。すると、以下の疑問が湧き上がってきます。

- Prop Drillingの問題とは何か
- 記事内に解決策は示されているのか
- ReactのPropの移動は「親から子へのバケツリレー」と表現される。Drillingとはどういうことか

ここで、ReactのPropsについて書かれているのだろう、という洞察を得ることができました。すると、大雑把に以下のような知識の体系に、上記の記事を位置づけることができます。

- ReactはSPAを構築するためのJSフレームワークである
  - Reactはコンポーネントごとに状態(state)管理をしている
  - Reactは、データの扱い方にstateとpropsという区別を設けている
    - propsは、上位コンポーネントから下位コンポーネントに一階層ずつ渡すものである
    - propsを下位コンポーネントに渡すことは「バケツリレー」と呼ばれる

ここまで考えると、「この記事ではReactのPropsについて、上位から下位へ渡す通常の方法では何か不都合が生じる場面があるのだな。記事の内容は、問題となるケースを紹介して、課題を解決する方法を提示することかな」と当たりをつけられます。

さらに察しの良い方は、「Propsを深い階層まで渡すことを皮肉を込めてProp Drillingとネガティブな名付けをしているのだな」とまで推測できるかもしれません。

実際に「prop drilling positive」と「Prop Drilling negative」でGoogle検索をすると、後者の方では8倍の件数がヒットしました。英語では「How to avoid prop drilling」とタイトルに入ったサイトが検索結果として並んでいます。

ただ「面白そうだから」とすぐに記事に飛びつくより、少し考察して読み始めた方が知識の定着効率に大きな差が生まれることの一例を挙げてみました。

実際に3ヶ月「積ん読」したブログを体系立てて整理してみる

さて、ここからは実際に自分が積ん読でSlack上に投稿し続けてきたURLたちを整理してみます。

(3ヵ月分のストックを並べてみると100記事以上あったので、今回はReactとNext.jsに関するものだけを画像化して掲載します)

Reactに関するブログ記事集

Next.jsに関するブログ記事集

あまりにも多かったので、ここに全て掲載することはできませんでした。整理した全ての記事はGistで公開しています。

このように「記事の地図」を作ると、自分が学習したい分野の記事にすぐアクセスできるようになります。

まとめ

いかがでしたでしょうか。新しい情報を見つけた時に、今の自分に必要かを判断して時間を節約しよう、後から整理して体系立てて知識のインプットを効率的にしようというのが今回のブログのテーマでした。

個人的にはPocketやQiitaのストック機能とは異なり、ただ対象を保存しておくだけではなく、保存する際に「この情報はこのジャンルのこの分野の記事」というようにカテゴリの分類ができるようなWebサービスがあればぜひ使いたいものです。

Essayhow to
プログラミングをするパンダ
プログラミングをするパンダ (@Panda_Program)
Software Engineer

本記事のスクリプトファイルの使い方の説明

まずは使い方から紹介します。

ルートディレクトリで./etc/scripts/make-component-template.sh components Layoutというように、ディレクトリ名とコンポーネント名を指定するだけ。

このようなディレクトリ構造を想定しています。

.
├── README.md
├── components
├── etc
├── node_modules
├── package-lock.json
├── package.json
├── pages
├── public
└── tsconfig.json

ディレクトリ構成

すぐにコードが読みたいでしょうか。オブジェクト指向言語ではクラスを理解しようとすると、内部実装を読む前にインターフェースを見に行きますよね。それと同じです。まずは使い方から。

自動生成するファイル群

./etc/scripts/make-component-template.sh components Layoutを実行すると以下のファイルを生成します。

components
└── Layout
    ├── Layout.tsx
    ├── index.tsx
    └── style.scss
[index.tsx]
export { default } from './Layout'

style.scssは空です。Layout.tsxは下記に内容を記載しています。

コンポーネントを生成するためのシェルスクリプト

シェルスクリプトは下記のように書いています。

[etc/scripts/make-component-template.sh]
#!/bin/bash

if [ $# -ne 2 ]; then
  echo "指定された引数は$#個です。" 1>&2
  echo "実行するには2個の引数が必要です。" 1>&2
  echo "例: components(ディレクトリ名) Layout(コンポーネント名)" 1>&2
  exit 1
fi

DIR=$1
COMPONENT=$2
TARGET="$DIR/$COMPONENT"

if [ -e "$TARGET" ]; then
  echo "ディレクトリ'$TARGET'は既に存在します。" 1>&2
  exit
fi

mkdir "$TARGET"
touch "$TARGET/index.tsx"
echo "export { default } from './$COMPONENT'" > "$TARGET/index.tsx"

cp etc/scripts/component-template.txt "$TARGET/$COMPONENT.tsx"

touch "$TARGET/style.scss"

Reactコンポーネントのテンプレートは下記です。

[etc/scripts/component-template.txt]
import React from 'react'
import style from './style.scss'

type Props = {

}

const Component: React.FC<Props> = () => (

)

type ContainerProps = {

}

const Container: React.FC<ContainerProps> = () => {

  return <Component />
}

Container.displayName = ''

export default Container

生成するReactコンポーネントの構成について

コンポーネントは「経年劣化に耐える ReactComponent の書き方」を参考にしています。この記事を読んだ時、自分が求めていたものはまさにこれなのだと感銘を受けました。

以来、実務や個人開発ではずっとこのように書いています。コンポーネントの責務を単一にできること、ロジックをview(jsx)から分離できること、viewに値と関数をインジェクトしている感覚が最高です。

「CSSを書く際は、Componentだけ見ればいいからわかりやすい」とデザイナーさんにも好評です。

なお、eslintでエラーが出たりprettierで整形されるのが面倒なので、component-templateの拡張子はあえてtxtにしています。わざわざignoreに書くより楽です。

面倒なタスクを自動化してアウトプットの価値を高めよう

エンジニアの三大美徳は「短期」「怠惰」「傲慢」。繰り返し作業を積極的に自動化させましょう。

価値の低い作業を自動化することは、立派な付加価値です。浮いた時間でより創造的なことに取り組むことができます。アウトプットの価値を上げていきましょう。

参考

引数を処理する | UNIX & Linux コマンド・シェルスクリプト リファレンス

Reactshell script
プログラミングをするパンダ
プログラミングをするパンダ (@Panda_Program)
Software Engineer

ボブおじさんのClean三部作

ボブおじさんのクリーンアーキテクチャを読んでアプリケーションのアーキテクチャについての見方が一変したので、続けて別の著作Clean Coderを読みました。

Clean Coderはボブおじさんの「Clean三部作」のうちの一冊です。

有名な「クリーンアーキテクチャ」の他に、「Clean Code」という、クリーンなコードを書くためのコード例を集めた本があります。

Clean Coderという本について

Clean Coderではプロのプログラマになるためには、動くコードを書けるだけではなく、規律や倫理観を身につけることが重要であると書かれています。

また、継続的学習や練習を怠ってはならないと説いています。

語り口は全く説教くさくなく、架空の職場を舞台にしています(多分ボブおじさんが経験してきたことが題材)。

ビジネスの人とプログラマの会話や、プログラマ同士のやりとりを通して、プロとしてのプログラマのあるべき姿勢を示している本です。

プロとしてのプログラマのロールモデルが本の中に描かれており、その振る舞い、姿勢、マインドセットは早速自分で実践してみたくなるようなものばかりです。

ソフトウェアのプロが備えるべき最低限のこと

第1章に「ソフトウェアのプロが備えるべき最低限のこと」として、以下のことが掲げられています。

  • デザインパターン
    • GOFの24のパターンについて説明できる。
    • POSAのパターンを実際に使える知識がある。
  • 設計原則
    • SOLID原則を知っている。
    • コンポーネントの原則を熟知している。
  • 方法論
    • XP・スクラム・リーン・カンバン・ウォーターフォール・構造化分析・構造化設計を理解している。
  • 規律
    • TDD・オブジェクト指向設計・構造化プログラミング・継続的インテグレーション・ペアプログラミングを実践している。
  • 成果物
    • UML・DFD・構造チャート・ペトリネット・状態遷移図・状態遷移表・フローチャート・ディシジョンテーブルの使い方を知っている。

それぞれの項目について自分を振り返って

デザインパターン

Clean Coderのこの箇所を読んで、デザインパターンについて知らないのはマズいと思い、会社にあった書籍を手に取りました。

デザインパターンは、設計の段階で使えるパターンを選ぶというものではありません。

実験的にコードを書いた後に、何かしら知っているパターンが見えてくると、そのパターンで実装し直す(リファクタリング)をすると見通しが良くなるものなのです。

そして、GoF本のパターンを学ぶ意義は、自分あるいは他人のコードに適用できるパターンの引き出しを自分の中で持っておくことです。

「初心者は何にでもパターンを当てはめたがる。それは往々にして丸いネジ穴に角材を突っ込むようなことになりかねない。パターンを使わなくて済むところは、わざわざ使う必要はない」と本にも書かれていました。

また、「中級者はパターンを頭の中にロードしておいて必要な時に読み出すのだ」とも書かれており、たまたまパターンが見えたら使うくらいのものと認識しました。

一方、デザインパターンを通してSOLID原則やデルメルの法則(友達だけ知っている)、ハリウッド原則(こちらからだけ呼び出す)を知れました。

このように、オブジェクト指向設計のベストプラクティスが実現されたコードを多く読むことができ、デザインパターン以上の武器を手に入れることができました。

続けてGoF本も読んでいきます。

SOLID原則や規律、成果物

SOLID原則、コンポーネントの原則はクリーンアーキテクチャ本で繰り返し解説されていた原則です。

特にSOLID原則はオブジェクト指向言語でのクラス設計・実装のベストプラクティス集であるため、OOPをしているプログラマは必ず知っていて欲しいものです。

今の自分の開発スタイルはUMLでクラス図を書いてクラス設計を可視化し、インターフェースを定義してクラスの使い方を定め、TDDでバグが出ないように実装していくのが好みです。

設計や実装を人に相談したかったり、業務知識を予め共有しておきたいところは、職場のオープンな場所でペアプログラミング(時にはモブプロ)を取り入れたりしています。

これからプログラマとして一人前になるため謙虚に、継続的に学習を続けていきます。

他にもアルゴリズムの知識も必要

AtCoderのレート

上記、ボブおじさんの掲げる項目以外にも、プロになるためにはさらにアルゴリズムの知識も必要になると思い、同僚とAtCoderを始めました。

「AtCoder Beginner Contest」を続けて受けて、まずは緑色コーダーを目指すことを目標にしました。

A,B,C問題をコンスタントに解けると緑色にはなれます。

現時点で、自分と同僚は過去問のA,B,C問題は解けているので、あとはコンテストを受けるだけだと思っています。

なので、本当は水色コーダーになっておきたいので、D問題も解けるように同僚とアルゴリズムの勉強を毎週火曜日の昼休みに行なっています。

自分は最初のチャレンジでD問題まで解くことができたので、順調な滑り出しでした。

BooksClean CoderUncle Bob
プログラミングをするパンダ
プログラミングをするパンダ (@Panda_Program)
Software Engineer

今更だけど自分用の技術ブログを作った

2年前、WordPresでブログを作りました。中国の旅行ブログです。しかし、次第にプログラミング自体に興味が移り、更新をやめてしまいました。

去年、Noteで記事を書いていました。でも読者を絞れず、書くネタが定まらなかったため、なんとなく書くのを辞めました。

関連記事: Gatsby製の本ブログをAMP対応しました

Qiitaにもアウトプットはしています。が、最近書きたいことがQiitaへの投稿に適してなさそうだと思い、自分の技術ブログを立ち上げることにしました。

種々検討しましたが、Gatsby.jsというReact製の静的サイトジェネレータで作ることにしました。マークダウンで書けること、Reactでカスタマイズができること、表示スピードが早いこと、Netlifyでデプロイすると、月100Gまでは転送量が無料であることなど、たくさんメリットがあります。

これから役に立つことをアウトプットしていきます。よろしくお願いします。

ちなみに、中国の旅行ブログはサイトの表示速度が遅いので3月頭にWordPressからGatsby.jsに載せ換えました。爆速で快適に読むことができます。よろしければぜひ見てみてください。

Essay
プログラミングをするパンダ
プログラミングをするパンダ (@Panda_Program)
Software Engineer