ブログの埋もれた記事を自動でランダムにTwitterに投稿出来るようにする
管理しているメインサイトの記事が300本を超えてきた。
サイトのコンテンツが増えてくると悩ましいのが、過去の記事の掘り起こし。
ブログ運営術を教えてくれるサイトを見てみると、古い記事はリライトするなり順位を下げるだけの不人気記事なら削除するようにとおススメされることもしばしば。
なるほど、検索順位を上げていくためならそれもいい。
でもね
自分で読み返してみてもこのままの内容でいいんじゃないかと思えるものもあるわけで。なにより専業でブログを運営しているわけではないのでリライトとかしている時間はほとんどない。
そうなると考えるのが、とりあえずこういった過去の埋もれた記事をランダムでピックアップしてTwitterやFacebookなどのSNSに投稿して読者を呼び込むこと。人数はそこまで大きくなくてもいい。とりあえず、こんな記事があるんだよ、と世の中に伝えたい。
ただ、時間がない。これが問題。
以前はSocialdogの予約投稿に1記事ずつ登録したりもしてみたけれど、そもそも記事を探すのが面倒。ピックアップする記事をなるべく時系列的にばらつかせようとすると、ひたすら面倒。これを自動化したくて仕方なくなった。
調べてみると、いくつか方法がある。簡単そうなのはWordpressのプラグインを入れてしまうこと。今回の目標は、過去の記事をランダムにかつ定期的にTwitterに投稿すること。Facebookはとりあえず、横に置いておく。
この条件だと、良さそうに思えたのがRevie Old Postsというプラグイン。
搭載されているすべての機能を使うには有料の登録が必要になるようだが、無料でもそれなりに使えそうだったので早速試してみた。
結果、即アンインストールした。
使い勝手がそこまで悪かったわけではなく、動作もそこまで悪くはなさそうだった。WPの現行バージョンでの動作確認が取れていなかったが、問題なく使えてもいた。では、なぜすぐに使用をやめたのか。
このプラグイン、ピックアップできる過去記事の範囲に制限があった。
この画像が実際の設定画面の一部。問題なのが上から3つ目の項目、「Maximum Post Age」が有料プランのみの設定に指定されていること。これ、要はどれだけ過去の記事までピックアップの対象にするのか、という設定なわけだが、無料プランでは365日、つまり1年以内の公開記事に限定されてしまう。
これでは意味がない。
有料プランを考えてもみたが、年間75ドル、もしくは買いきりで225ドルとちょっとお高い。
そこで別の方法を考えてみた。
そして思い出したのが、Twitterに自動で投稿しているBotの存在。過去の記事を自動で投稿させるのだってやっていることはBotと同じ。なら、出来るのではないだろうか。
さっそく調べてみたらやり方は簡単に分かった。実行する手順もそこまで面倒ではなく、お金もかからず出来るようだ。
なら、やってみるしかないだろう。
という思い付きだけでGoogleスプレッドシートを使って運用可能なTwitter Botを作ってみた。
やり方はこちらのサイトを参考にさせていただいた。このサイトの通りにやれば困ることはほぼないので、もうここでは説明はしなくていいだろう。コピペすればそれで8割がた終わる。
今回実際にやってみて困ったのは、こちらの記事に説明のなかったTwitter Developer Portalへの登録。登録自体は英語であること以外は特に問題なかったのだが、最初に分からなかったのがTweet Bot用アプリケーションのパーミッション設定(App permissions)を「Read and Write」に変更する方法。いくらプロジェクトの内容を見てみても最初の時点では変更する方法が分からなかった。
実はこれ、上記の記事の内容を先に進めてOAuth1の設定まで終わらせてからTwitter Developer Portalに戻って、コールバックURLの設定に進む時点で変更できるようになる。
ちなみに2022年3月8日時点では上記の記事に書かれている「Enable 3-legged OAuth」の設定はない。OAuth1かOAuth2の選択をするだけになっているので、ここは素直にOAuth1を選んで作業を進めればほぼ、上の参考記事に沿って進んでいける。
次に引っかかったのが、作ったTweet Botを走らせた時に出てきたGoogleからの認証に関する警告。認証の説明に関するボタンをクリックして出てくるポップアップウィンドウの左下にある、安全性の無視して認証する手順を踏めば問題なく出来るようになるのだけれど、最初はそこに気が付かずしばらくウロウロした。
そうしたすったもんだを踏んで、とりあえずスクリプトの準備はできた。次に必要なのが、Botに使うリストの作成。
最初の発想が手間をかけずに過去の記事をSNSに流したい、だったのでここでリスト作りに手間はかけたくない。300記事もいちいちタイトルとURLをとってきてリスト化していてはいつ終わるのか分からない。
てか、それをするなら今まで通りSocialdogで運用する。
とうことでここでも作業を簡単にしてみた。
まず使ったのが、Export all URLsというプラグイン。これを使ってWP中に公開されている任意の記事のタイトルとそのURLをcsvとして抽出してきた。
ただこのままだとGoogleスプレッドシートにコピペをしてもタイトルとURLが別々の列に入ってしまって具合が悪い。そこで一度、この2列をまとめてコピーして適当なテキストエディタにペースト。そうするとタイトルとURLが一列に並ぶようになる。
もっともこのままGoogleスプレッドシート側にコピペしてもまた2列に分かれて張り付かれてしまうので、まずはタイトルとURLの間にあるタブをテキストエディタの置換機能を使って半角スペースに一括で置き換える。
ちなみに自分は安定のVS-Codeで処理した。
あとはテキストエディタ内のすべての文字列を一括選択してGoogleスプレッドシートの1列目にコピペしてやれば狙い通りにタイトルとURLが1セル内にまとめて入ってくれる。一応、文字数を管理するためにウェイトを決めた列の右横に文字数管理列を作ることにした。
こちらは”LEN”関数を使ってタイトルとURLの入っているセルを指定すればそれで完了。仮に140字を超えているところがあれば、修正しておけばいいだろう。
この後は新しい記事を公開したらGoogleスプレッドシート側のリストに新しく追加するなり、一定期間ごとにExport all URLsを使って新しいリストを取得してリストを上書きするなりすればいい。
定期処理はApps Scriptのプロジェクトページの右メニューにある [トリガー] で設定すればいい。自分は今のところ、あまり頻繁に過去の記事がTwitterに投稿されてもどうかと思うので、曜日を指定したトリガーを2つ作って週に2回投稿される設定にして様子を見ている。
TwitterのBot、思ったよりも簡単に出来ることに軽く驚いた。たぶんこのやり方を説明しているのであろうと思われる有料noteなんてものまであるのに。
これならわざわざプラグインをサイトに入れるよりも、有料サービスを利用するよりも、自分でサクッとやってしまった方がいいように思える。
まぁ、しばらく走らせてみて安定した動作が出来るようであれば、だけれど。
AmazonのKindleを新調した。海外版で。
Kindleはやっぱりいい
最近は読書といえばもっぱらKindleを使っている。
今やもう知らない人はいないと思われるが、念のために説明するとkindle (キンドル) とはオンライン通販大手のアマゾンが販売している電子書籍用端末。
うっすい端末なのに複数の本を同時に持ち運べるし、狭い我が家の少ないスペースを本に占領されることもない。上手いことセールの時を選べば本も安く買える。
欠点といえば中古本で買ってもっとお安くあげる選択肢がなくなることと、電子化されていない本は読みようがないこと。そしてページをあっちこっちに気楽にいったり来たりがしにくいこと。
意外にあるな、欠点。
それでも、やっぱりKindleはいい。旅行の時や出張の時には特にいい。欠点な部分は場合によって紙の本にして使い分ければいいだけだし。
そんなKindleにも最近になって新型モデルが登場した。いつの間にやら11世代だそうだ。ちなみに個人的おススメはいくつかあるKindleのなかでもKindle Paperwhite。おススメというより、むしろこれ一択。
手持ちのKindleはそうとう昔に買ったもの。第何世代なのかなんてわからなかったので調べてみたら第4世代だったらしい。確か、日本で最初に発売されたKindle Paperwhiteだった…はず。
こんだけ使い込んでいるとそろそろ新型モデルが気になる時期。やっぱりいいじゃん、新しいやつ。
ということで、Black Fridayのセール時期に合わせて買い替えてみた。
海外版のKindle Paperwhiteに。
ちょっとだけAmazonのアカウントの話をしよう
知らない人にとってはなんのこっちゃなんだけど、とてもグローバルに思えるAmazonさん、実はアカウントは国ごとに独立している。
どういうことかと言うと、日本のアマゾンのアカウントでは例えばフランスのAmazonにはログインできない、ということ。ログインできないので当然、買い物もできない。プライムのビデオも観れないし、Amazon musicを聴くこともできない。海外から日本のアマゾンにログインすれば話は別だけど。
たまに間違ってる人がいるけど、例えば日本とフランスの両方でそれぞれのAmazonのアカウントを同じメールアドレスを使って作ってもそのアドレスは統合されない。単に同じメールアドレスを使うIDがそれぞれの国に別々に存在しているとして処理されるだけ。
なので同じメールアドレスを使って複数の国のAmazonでアカウントを作っていて、日本ではプライム会員なのに別の国ではプライムになってない!と叫ぶのは勘違い。大騒ぎすればするほど恥ずかしいので注意したい。
日本のAmazonを経由してフランスのAmazonにつないで、そのままフランス国内から買い物することは、出来ない。この一方でAmazonでは結構な数の品物が海外発送に対応している。ただ、全部ではない。例えば今回のKindle Paperwhiteは海外発送未対応の商品だ。
そうなると気になるのが、海外で買ったKindle Paperwhiteを日本で使うことが出来るのか、ということ。しかも海外のAmazonにある日本語の書籍を買うのではなく、日本のAmazonのアカウントと紐づけて日本のAmazonで本が買えるのか、と。
結論から言おう。問題なかった
今回はなぜか持ってる海外のAmazonのアカウントで、その国のKindle Paperwhiteを買ってみた。送付先は当然、その国のとある住所。
ちょいとその住所に行く用事があったので、行ったついでに注文しておいたKindle Paperwhiteをピックアップ。そしてドキドキしながら箱を開けて電源をオン。
はたして、全然関係ない国のAmazonのアカウントに紐づけられるのだろうか。
ダメだと買ったばかりの新型Kindle Paperwhiteをいきなり新古品として売らなきゃならないことになるので、ぜひとも使えて欲しい。切実に。
使えた。まったく問題なく。
今回は注文の時に購入者のアカウントを商品の発送前に登録しない設定にしていたからだろう、電源を入れたらアカウントの設定画面が表示された。ちなみにすっかり忘れていたので写真はない。頭の中で想像して欲しい。
最新型Kindle Paperwhiteではアカウントの設定がスマホにインストールしているKindle Appから出来るようになっている。なんだかiPhoneの機種変作業と同じに思えてくる。
双方をBluetoothで接続して設定情報を移行する、みたいな。みたいな、というか、そのままだろう、きっと。
で、この作業で海外版Kindle Paperwhiteが日本のアカウントと問題なく紐づけられて、そのまま普通に使えるようになった。古い方のkindleに入っていた本も全部クラウド経由でダウンロードできた。
結論。海外のAmazonでKindle Paperwhiteを買っても日本のAmazonで買っても違いはない。
いや、なんでわざわざ海外のAmazonでKindle買うんだよ、と自分でも思う。価格は為替の関係があるにしてもほぼ変わらないし。受け取りにはその国まで行かなきゃならないし。ほぼほぼ意味のない検証だった。
でも海外在住の人でKindle欲しいなぁ、という人がいたら安心して欲しい。
その国で遠慮も心配もなく、Kindleを買っていい。念のために注文時に購入者のアカウントと紐づけないようにだけしておけば無問題。あとはKindleの到着後に日本のAmazonのアカウントで登録すれば日本の本が読みたい放題。わざわざ日本への帰国時にKindleを買って帰ろう、なんて思わなくて大丈夫。
しかし、やっぱりKindleいいよ。そして買うならKindle Paperwhite。これ一択。
最新の11世代は第4世代と比べるとちょっと幅が広くなっていたけど、ページ送りは速いし、動作は軽快だし。
迷っている人にはおススメ。
自分はいらなかったけど、無線充電ができて画面の明るさや色温度が自動調整されるシグニチャエディションなんてものもある模様。
ちなみにKindleを海外のAmazonで買うのは問題ないけれど、日本の本を買って読むためには日本のAmazonのアカウントが必要なので、Kindleを買って日本の本を読みたい人は予め準備しておくように。
Kindleはいいぞ!
最近の開発環境はDockerだと聞いたので考えなしに入れてみた。
最近はDockerらしい
開発、というほどの開発をしているわけではないのだけど、一応、手元のPCには開発環境と呼ばれるものも用意している。Windows使いの自分はXAMPP。今のところはこれで特に不満もなかったけれど、最近の流れはDockerらしい。
Docker…もちろん初耳。ちょっと調べてみたらコンテナ型の仮想環境を作ってそれを管理する方法、らしい。そして起動や動作が速い、らしい。細かいことはよくわからない。
ローカルの仮想環境とサーバー側の実行環境の環境を統一できるから本番動作でのトラブルが起きにくい、なんていわれてもアプリ開発してるわけじゃないので今一つ必要性が怪しい。
ただ、とりあえずPCの負荷も減るし速くなるなら試してみたらいいんじゃね?ということでやってみた。
Dockerをインストールしてみた
ということで、早速、PCにDockerをインストール。
まずは公式サイトにいってみるとDockerとしては無料のPersonalと有料のProがある。さらにこれ以外にDocker Desktopというのもある。調べた感じでは自分の環境ではDocker Desktopでよさそうなので、それをダウンロード。
こっちがDocker Desktopのダウンロードページ。今回はこれをインストールしてみた。
インストール中にWSL 2をインストールするかどうか聞かれたので併せてインストール。Dockerの動作に必要らしい。ということでなにはともあれDockerをインストールしてWindowsを再起動。待つことしばし。
さて、なにをしたらいいのだろうと思っていたら、Windowsの起動とあわせてスタートアップ起動してきたらしいDockerからWSL 2入ってないやん、と怒られた。ので、こっちも入れてみることに。
WSL 2とついでにUbuntuも入れてみた
WSL 2が必要だ、といわれてもなにものかもわからないままインストールするのはさすがに怖い。軽く調べてみると、Windows上でLinuxを動作させるためのもの、らしい。とりあえず、言うほど怪しいものでもなし必要なものだそうなので、さっそく入れてみる。
このサイトから「x64 マシン用 WSL2 Linux カーネル更新プログラム パッケージ」をダウンロードしてきて、インストール。その後にDockerを再起動。特に問題もなく、インストールに成功。
上記のページによるとWSL 2を既定のヴァージョンとして設定したうえでLinuxのディストリビューションをインストールしろということなので、そちらも作業。Dockerのインストール、意外に面倒ね。
WSL 2のヴァージョンの既定化はWindowsのPowerShellからやるらしいので、デスクトップのWindowsマーク横の虫眼鏡にPowerShellと入力して検索後、出てきたアイコンをクリックしてPowerShellを起動。
続いて
wsl --set-default-version 2
のコマンドをコピペして実行。これ、VS Codeのターミナルからでもできるのかな?試さなかったからわからないけど。
あとはMicrosoft storeを開いてLinuxのディストリビューションをインストールしろ、と。何やらいくつかの種類があるらしいけど、よくわからないので案内サイトにある画像のままにUbuntuをインストール。
Ubuntuをインストールして起動したらユーザー名とパスワードを入れろと言われたのでこれも適当に設定して完了。最後はDocker側のSettingsからResources、WSL Integrationといって"Enable integration with additional distros"の項目でUbuntuをアクティブにすれば完了。…のはず。
考えなしに入れたのでこれ使って何するの?というのはまだ未定。
とりあえずはDocker Desktopをインストールして統合するところまでで今回は終了!
プライバシーポリシー
【プライバシーポリシー】
■広告の配信について
「考えなしにやってみる。」(以下、当サイト)は第三者配信の広告サービス「Googleアドセンス」を利用しています。(予定)
広告配信事業者は、ユーザーの興味に応じた広告を表示するために「Cookie(クッキー)」を使用する場合があります。
Cookieを無効にする設定およびGoogleアドセンスに関して、詳しくはこちら(https://www.google.co.jp/policies/technologies/ads/)をクリックしてください。
また、当サイトは、rakuten.co.jp/を宣伝しリンクすることによってサイトが紹介料を獲得できる手段を提供することを目的に設定されたアフィリエイトプログラムである、楽天アフィリエイトの参加者です。
第三者がコンテンツおよび宣伝を提供し、訪問者から直接情報を収集し、訪問者のブラウザにCookie(クッキー)を設定したりこれを認識したりする場合があります。
■アクセス解析ツールについて
当サイトでは、Googleによるアクセス解析ツール「Googleアナリティクス」を利用しています。
このGoogleアナリティクスはトラフィックデータの収集のためにCookieを使用しています。このトラフィックデータは匿名で収集されており、個人を特定するものではありません。この機能はCookieを無効にすることで収集を拒否することが出来ますので、お使いのブラウザの設定をご確認ください。
この規約に関して、詳しくはこちら(https://www.google.co.jp/policies/technologies/ads/)をクリックしてください。
■当サイトへのコメントについて
当サイトでは、スパム・荒らしへの対応として、コメントの際に使用されたIPアドレスを記録しています。これはブログの標準機能としてサポートされている機能であり、スパム・荒らしへの対応以外にこのIPアドレスを使用することはありません。
当サイトでは、次の各号に掲げる内容を含むコメントは管理人の裁量によって承認せず、削除する事があります。
・特定の人物または法人を誹謗し、中傷するもの。
・極度に猥褻な内容を含むもの。
・禁制品の取引に関するものや、他者を害する行為の依頼など、法律によって禁止されている物品、行為の依頼や斡旋などに関するもの。
・その他、公序良俗に反し、または管理人によって承認すべきでないと認められるもの。
■免責事項
当サイトで掲載している画像の著作権・肖像権等は各権利所有者に帰属致します。権利を侵害する目的ではございません。
記事の内容や掲載画像等に問題がございましたら、各権利所有者様本人が直接メールでご連絡下さい。確認後、対応させて頂きます。
当サイトからリンクやバナーなどによって他のサイトに移動された場合、移動先サイトで提供される情報、サービス等について一切の責任を負いません。
当サイトのコンテンツ・情報につきまして、可能な限り正確な情報を掲載するよう努めておりますが、誤情報が入り込んだり、情報が古くなっていることもございます。
当サイトに掲載された内容によって生じた損害等の一切の責任を負いかねますのでご了承ください。
運営者:考えなしにやってみる。
初出掲載:2021年09月01日
VS Codeでリモートが出来ると聞いたので考えなしにやってみた。
VS Codeでリモートワークが出来るらしい
いわゆるエディターと呼ばれるものをいくつか試してみたけど、最近はMicrosoftのVS Codeがお気に入り。正式名称はVisual Studio Code。
無料で使えちゃうのに軽くて高機能。ここしばらくはテキスト書くのも、コードをいじってみるのも全部これでやっている。たぶん完全に使いこなしたらさらにさらにいろいろ出来るのだろうけど、そこは素人がやることなので、まぁ、何となく使いやすいから使ってる、くらい。でも便利。
ちなみにお気に入りの二番手はSublime text。これも結構好き。最近は2つのファイルの内容の比較をしたい時くらいにしか使ってないのでめっきり出番ないけど。
使ってみたい人はこちらからどうぞ。
で、このお気に入りのエディターさんでなにやらリモート作業が出来るらしい、と聞いて詳しいことも分からないままにとりあえず手を出してみることにした。
準備するのは拡張機能1つだけ
VS Codeでリモートするのに必要になるのは拡張機能が1つだけ。その名も「Remote Development」。そのまんま。
以前は開発者向けのβバージョンみたいな扱いだったようだけど、今は正式にリリースされている。というわけで、さっそくやってみる。
まずは画面左のバーの拡張機能のアイコンをクリック。そして検索窓にRemote Developmentと入力。見つかったやつをクリックして、ウィンドウに表示される詳細からインストールをクリック。以上、おしまい。後は待つだけ。非常に簡単。
何をリモートすればいいのか、分からない…!
Remote Developmentのインストールは簡単にできた。流石、VS Code。使いやすい。ただここで問題が。いったい、何をリモートすればいいのだろうか。
ちょっと画面を触ってみると、この拡張機能でつなげられるのはContainer、SSH、WSL、らしい。うん、なんのこっちゃ。
そもそも自分はなにかVS Codeを使ってリモートで開発するような案件を抱えているわけではない。たんに興味に任せて入れてみただけ。でも入れてみたからには使ってみたいのが、人情というもの。
考えた。すごく、考えた。
そうだ、Wordpressをリモートしてみよう!!
実は筆者、細々とWordpressを使った自分のサイトの運営なんてこともやっている。で、たしかそこのFTP接続でSSHを使っていたはず。ということは、その設定を使えばVS Codeから直接、サーバーに接続してファイルをいじれちゃうはず。必要かどうかは分からないけど、面白そう。
ということで、やってみた。
WordpressでVS Codeから直接SSH接続してみた
接続の詳しいやり方はこの辺りのサイトを参考にしてみた。
こちらのサイトではMacのターミナルを使っているけど、自分はもちろん、VS Codeのターミナルで実行。
で、SSH Targetsから新規作成をするとその時点でsshフォルダとかConfigファイルとかは自動で作られている (っぽい) ので、先のサイトにあったようなコマンドラインを打って自分で作る必要はない。単純にサーバーから取ってきた公開鍵認証用のペアをリネームして該当フォルダに入れて、Configファイルの中を書き換えてあげれば完了。
Windows上でのマウス操作で出来ることまで一生懸命、コマンドラインを打つ必要はないのでここも操作はらくらく。
無事に設定が完了すると左側のウィンドウのSSH Targetsの下に登録したサーバーが表示されるのでそれを右クリックするなり、サーバー名の右のアイコンをクリックするなりするとリモート接続が始まる。
SSHの接続を始めると割とすぐにパスフレーズの入力が求められる。この直前に自分の場合はLinux、Windows、Macの選択画面があった気がするけど、たぶん、そこはLinuxにした、、、はず。大丈夫、それで問題なく動いてる。
で、そこからまたしばらくすると無事にSSHでの接続が確立された。あとは普通にローカルで作業してるのと同じようにディレクトリからお目当てのファイルを選び出してそのまま作業が可能。ディレクトリの移動はマウスを使った選択でいけるので、都度、コマンドラインを打ちこむ必要はなく、本当にローカルで作業をしているのと同じ感覚で作業ができる。
直接作業はすごい、けど
やってみるとわざわざ現行のファイルをFTPを使ってサーバーから落としてきて、加工して、アップロードして、という手間が完全に排除されてとても便利。ファイルによっては作業スピードが段違いで上がる。
ただ、ただ、ここで問題が。
自分のような雑魚がこれをやってしまうと、ファイルの記述を間違えたものが直接上書きされてしまうのでとっても危険。一度サーバーからダウンロードするステップを踏んでいないのでバックアップもない場合がある。
そこさえ克服できれば便利なんじゃないかな。まだまだ実感薄いけど。
そんなわけで、何も考えないままVS Codeでリモートワークをしてみたお話しでした。
結論は、ご利用は計画的に!