仕事（本業）
可もなく負荷もなく代わり映えもなくという感じ。
ただ少し学びもあって設計とテストの関係性について理解度が深まったりしました。
設計→実装→テストという流れを汲むとしたとき、テストの仕様書は設計書をベースに作ります。（実装をベースにしたらバグ通りのテスト仕様書とかになりかねない）
ということは設計書が土台になるわけですが、設計書の書き方と実装の処理の仕方が若干異なる場合ちょっと困ったりするなとか思いました。
例えば値が切り替わったタイミングをイベントで感知して、何かしらの処理を走らせる。というやり方ではなく、フレームワークやライブラリの実装されている値の監視をするようなシステムを利用したほうが良いと実装者が判断して実装した場合、見た目上は変わりなくても処理に違いが出てしまいます。
この辺は見た目の動きを軸に考えて良さそうに今は理解してますが、ちょっと面倒くさい部分だなとか思いました。設計段階ではその言語仕様のこととか把握できていなかったりするケースも全然有るし、実際今回はメンバー全体がそんな傾向にあるようでしたし。
そこで出てくるのが自動テストだったりテスト駆動開発なんだろうなとか思いました。確かにこれから画面の動きを手動でテストしていくのとかかなり面倒くさいことが予想されるわけで、そう考えると自動テストほしいですね…
品質をちゃんと高いものにするのであれば自動テストって工数に含められるなら含めたいものなんだなぁとか思ったりしました。本業はそんな感じ
※あとwebエンジニアになってから1年経ちました。
初期は8割型知らないことだったので仕事する = スキルアップみたいな所ありましたが、いまは知ってることのほうが多いような状況になってきたので、スキルアップがまあないです。
それでも開発の仕事の流れみたいなものは知れているので良い部分はありますが、自分が個人事業やめてからのモットーとして「できる限り難しいことをできるようにしていく」というのがあり、物足りなさは感じていたりもしました。
まあでも冷静に考えてみると、知らないこと8割でコーディングしている状況がよほどおかしいわけで、現状が普通なのやも。
スキルアップしたいなら自分の時間でやっていくしか無いのかもなという気持ちです。
仕事（副業）
きちぃ……
Today we released the October 2022 spam update. Find out more about spam updates at https://t.co/XthD5GF06M . We'll update our ranking release history page when the rollout is complete: https://t.co/sQ5COfvo3J
— Google Search Central (@googlesearchc) October 19, 2022
スパムアップデートがアナウンスされて、ちゃんと被弾してました。
10月20日前後ぐらいで崖みたいになってるところがそうです。
なので、7月末ぐらいから動向を見ていたサイトはお陀仏した感じではあります。
類似サイトは2つほど10月中に作りました。
前者は直近数日で怪しい動きをしているので多分やばいです。後者はどうだろう、うーん……
後もう一つ別ジャンルで作ったのもあります。
需要調査も兼ねて作ったぐらいなのでかなり適当。どうなるんだろう、わからぬ
簡易的な死活監視作った
格安vps上で5分おきにcronで保有サイトにrequestを送り、正常なら何もなし。異常ならslackにメッセージを送るみたいなやつを作りました。
AWSのcloudwatch使いたいっすね…
反省とか
7月末ぐらいから見ていたサイトは「この方法でうまくいくのか？」を確認したく作ったぐらいのサイトだったので、アプデで死んだことにそこまでの不満はないです。
その次に作ったサイトは、まあぶっちゃけて書きますけどページ/セッション改善のためにページ分割を導入してました。
このとき2つの問題にぶつかりました。
一つはFAQ構造化データで、検索結果にFAQを表示するための構造化データはインデックスされたページにFAQ構造化データと同一の内容のよくある質問が存在しないと反映されないらしく、困らせられました。
またこっちがより大きな問題で、ページ分割をした場合canonicalをしていても別ページがインデックスされる場合があり、そうなるとキーワード戦略的にうまく行かなくなってしまうケースが判明しました。
これは完全な仮説ですが、検索で表示されるページにアフィリエイトリンクを設置した場合、評価が下がる傾向にあるのではないかと考えており、ページ分割することで別ページで訴求を行うよう変更したのですがこれは上記問題により厳しいように感じました。
これをやるのであれば素直に抽象度の高い訴求用ページを作成し、そこに量産したページからユーザーを送るとしたほうが内部リンク構造も明確になりますし良かったような気もしました。
スパムアプデ所感
スパムアプデは他の人達の反応を見るにサイト単位でのアプデだったような気がしました。
ということはサイト全体の構成が重要だといえ、現状のように設計をおろそかにしてページ単位でひたすらキーワードを取りに行く手法で進んでいくのはまずいような気がしました。
コードの汎用性
現状、スピード重視で動いていたためコードの運用保守の部分がかなり厳しいものになっています。
またテーブル構成等も流用性が低く、長期的に見るとスピード感が無いように感じてます。
コンテンツを1枚の雛形から量産するだけではサイト設計としても弱くなってしまう問題もありますし、CMSのような仕組みを作ることが必要だなと思ってました。
じゃあWordPressでやるのかと言われたら正直それがベターな気がしていますが、開発者としてのスキルを磨くいいチャンスなのではないかという思いもあり、Next.js + FastAPIで自分用の雛形を作っていこうかなという気持ちがあります。
間違いなく時間がかかるとは思っていますが、このタイミングで時間をかけてでも良いシステムを作っておいたほうがいいのではないかという考えがあります。
コンテンツちゃんと作らないとまずい
さっきの話の繰り返しに近いですが、スパムアプデ以降今のスタイルでは厳しいような気配を感じていて、解決のためにはやはりコンテンツ作りが重要な気がしていました。
これはページ単位でもそうですし、サイト全体の設計でもそうです。
とはいえそれを突き詰め過ぎると今までやってきたアフィリエイトと全く同じなため、労力的に厳しいです。なので労力の低い記事量産を軸として、そこからユーザーを抽象度の高い訴求用ページに移動させ成約させる。そういった構成のサイトを作ろうと考えていました。
来月やりたいこと
とりあえずあと一つ今の手法で作っている最中のサイトがあるのでそれの公開まではやります。
その後はオレオレCMSのようなを作成。
あと一つ残ってるアイデアをサイト設計からちゃんと作って投げる。みたいなのを想定してました。
今年中完成を目標にしたいですが、本業が新しい作業に入るので当面は余裕ないかも。
ただ寒いことを理由に11月初旬以降のほぼフルリモートを勝ち取ったので、なんとかならなくもないかなーと思ったりしました。
まとめるとこれです。
- 作りかけサイトを作成、公開まで終わらせる
- Next.js + FastAPIでオレオレCMS作る（NextAuthとzenn-editor使う予定）
- オレオレCMSを軸に設計ちゃんとやったサイト作る
こんな感じ。FastAPIのつもりだけど、もしかしたらNext.jsのAPI機能使うかもしれない。わかんないけど。
あとついでにnginxのところをなんとかしたいという気持ち。今の構成nextjs -> nginx -> https-portal(nginx) で、謎にnginxを間に一つ余分に挟んでしまっているので、多分これなくせるよなっていう。
以上振り返りでした。
