この数日〜数ヶ月で実装しようとしているもの
- HTMLのユニコードエスケープ
- plan / プラン、見積もり額表示のコンテンツ再開
- コーヒー系のプログラム
プラン・見積もりはパッケージのような形で業務別に分けた上で係数をつけ、画面ごとに割り出すようなロジックで計算できないかを考え中です。
コーヒー系のプログラムはものすごく使いやすいなど明確なメリットが出せれば公開・・・
丁度いいをかたちに − クリエイティブに知性を。cdbk.net CREATIVES. / Front-end Development & Designing
Just another WordPress site
プラン・見積もりはパッケージのような形で業務別に分けた上で係数をつけ、画面ごとに割り出すようなロジックで計算できないかを考え中です。
コーヒー系のプログラムはものすごく使いやすいなど明確なメリットが出せれば公開・・・
2014年に経験した大雪以降、実際に使っている雪の日にあると便利なものを
忘れないように書いてまとめてみました。
外出時はこけないように、寒さに耐えられるようにといったところで使うもの
岩場などをあるくための重く、硬いものから、ちょっとしたハイキングに使えるスニーカーのようなものまで最近は種類が豊富でGore-Texなどを使用した防水性の高いものであれば、雪の日にも使えるので1足あると便利です。
深いとコンクリートやアスファルトを痛めるので、軽装でスパイクが浅い靴に取り付けるタイプのもの。アウトドアショップなどで取り扱いのあるもの。
ドアの周りなどの着雪が氷結したときなどに使うスコップ。気温が0度以下になると溶けた雪が凍る。もしくは20cm以上坂道などに新雪が積もると滑って登れなくなる時があるので、そういったときに素手以外の手段としてあると便利です。
両手が空き、防水性のあるもの。素材が普通の布地だと着雪してしまうので、できればビニールのように水をはじくような素材orザックカバーが付いたもの。
家にいれば安心かというとそうでもなく、水道が凍結して出なくなったり、電線が雪の重みで断線、変電所が低温で不具合といったことも起こるので万が一のために準備しておくと良いもの。
室内外問わず、暖を簡単に取れる手段
ガス使用可能な場所に限るけれど、アウトドアで使うものや普通のカセットコンロなどイワタニの製品などはコンビニなどでもカセットガスが手に入ります。
それ以外は水を入れると発熱するヒートクッカーがあるとレトルト食品などを調理できる。
明日以降の最低気温がマイナス4、7度とかになっている。
水道凍結や電線の破断があると困るけれど、できる対策があまりなく・・・
以前投稿した 「サイトのブログをWordPressベースのSPAにしてみた」 の内容を整理と カテゴリー・タグ別の一覧表示や検索に対応したので軽く実装できるところまでのまとめメモ。
WordPressのSPAを公開する場合の要は普通の検索結果に載せることができるかどうか?
トップページから何度もクリックしないと行き着かないコンテンツは見てもらえず、不便なのでApacheのRewriteなどでPushStateで変更されたアドレスのコンテンツと同じものを表示させることが大事。
またビルド環境がなくともサーバー上のデータを直接編集して修正対応することや、WordPressをSPAで実装するにあたってどんな問題が起こるかなど把握するために、一旦jQueryベースのMarionette/Backboneで構築した。
Gulpでビルドしたものの出力先にMAMPの参照先を設定して、Gulpでビルド+Apacheでブラウジングできる環境を整える。
その上でWordPressはWeb上のものをそのまま使用、クロスドメインのため使用上ページ数、記事数などResponse headerで送られてくるデータが取得できないなどのところはnullを置き換える対応を行うなどして考慮する。そしてES2015へ移行。
https://cdbk.tokyo/post → トップページ
https://cdbk.tokyo/post/(slug) → 記事ページ
https://cdbk.tokyo/post/category/(slug) → カテゴリー別一覧ページ
https://cdbk.tokyo/post/tag/(slug) → タグ別一覧ページ
https://cdbk.tokyo/post/search/(slug) → 検索結果ページ
各ディレクトリ毎の(slug)に当たるところに.htaccessを置いてrewriteの設定を行い、pushStateした際のアドレスに沿うようにAPIへのリクエスト処理を構築する。
また、そのため各記事はpost idではなくslugベースで呼び出すようにし、APIで呼び出すJSONデータはキャッシュさせるような仕様にしている。
Application
API
ルーティングもMarionetteで一応準備はしているもののブラウザバックボタンを使うことがあったりするので、一旦はBackboneで実装。
初期表示を一度してしまえば、表示速度が速い。
WordPressのテーマ・テンプレートの仕様を考慮せずページを作りこめる。
投稿などをWeb、アプリなどさまざまなところから場所を選ばずできる。
Marionetteベースだとビルド環境に左右されずに作ることができる。
キャッシュさせているのでクリアさせるのが難しい。
sitemap.xmlとfeed(ATOM/RSS)がまだ未対応で手動・・・
今後を考えるとJavaScriptの主体をvue/react/nuxt/nextにしてしまうのを早めにやってしまうのがいい。
今までWordPressを使うときはテンプレートを頑張って、PHPを駆使してページを作ることが多かったけれど、REST APIを使うことで、かなりフロントより、JavaScriptメインでページやSPAを踏まえたサイト構築を行うことができるようになった。
今回はJavaScript周りをES2015へ少し移行させたり、サーバーをSSL対応のSSDベースのところにして高速化したりと今までできなかったことができてよかった。
次はNuxt?Vue?あたりを使えるようにしてから、導入できればと計画中。
https://qiita.com/uto-usui/items/4eb21aec704b888936d0
gulpとejsベースでブログコンテンツを再開したものの、更新や記事の管理を考えるとWordPressに勝るものはなく、WordPressをSPAで実装したという話。
昨年(2017年)、サイトをリニューアルした際にブログ機能をWordPressからejsにして0から始めてみたものの、今後記事数が数百などになった場合の管理やリニューアルをした時の記事データのあり方を考えると、
やはりCMSやデータベースで管理したほうがいいと思ったことと、WordPressのREST APIがとても使いやすかったので、年末年始で全記事一覧、記事表示を一旦実装したので、記事にまとめてみました。
現状、jQuery + Backbone + Marionetteベースの仕様なので、一旦それを踏襲してWordPress REST Apiを使った画面表示+設計を実用レベルで落としこむ&実装、その後、今時の新しい技術で置き換えるをゴールにしようと思い、一旦はjQueryベースで実装しています。
記事一覧トップと各記事はpushStateでアドレスを変更するようにしているものの、実態はSPAのため、記事ページ上でブラウザの更新ボタンを押すor直接アクセスすると404になるという、SPAでよくある事象はApacheのReWriteで解決することにしました。
ページへアクセスした際にアプリケーション(Marionette.Application)、コントローラー(Marionette.Controller)、ルーターを起動して、レイアウトの配置をした後に、APIへアクセスして記事データを取得、表示するようにしているのみで、
こちらから記事内容の変更や削除を行えるアクセスはできないようにしています。
APIの設計の都合上、ページ数などをResponse Headerから取得する必要があるため、WordPress本体は同じサブドメイン上に置く必要があり、また、APIへアクセスするとWordPressの実態があるURLも取得可能なため、完全なAPIのみの表示を行おうとするとWordPressのテーマ上でプロセスの追加・変更が必要になると思います。
各記事ページのアドレスを「slug」の文字列にしておき、APIへのアクセスと記事ページアドレスを両方、slugにすることで下記のReWrite設定でまかなうことができるようにしています。
RewriteEngine On
RewriteBase /post/
RewriteRule ^index.html$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^/]+)/?$ index.html?$1
その他、今後実装する予定のカテゴリー、タグ、検索結果などの○ページ目などをSEOを考慮して実装する際また大幅に手を加えることになりそうですが、ひとまずはこのままで・・・
現状はGoogle側へ送信しているsitemap.xmlをgulpを使い、ejsをビルドする際に作っているので、それに加え、WordPressのプラグインなどを使って作っているsitemap.xmlをサイトのSPAで実装しているアドレスに置き換えて実装できればSEO面も担保できそう。
表示のレスポンスの速さとアクセスのしやすさを両立したSPAをコーポレートサイトに実装する、そのノウハウを次へ活かしつつ、WordPressのSPA化を視野にサイト構築のバリエーションを増やしていくことでエンジニアリングとデザイン両面で表現の幅を広げていければと考えています。
そして15記事あまりのejsで作った記事ページをWordPress側へコピペする作業を地味に行う必要が・・・
これとは別にNuxt.jsなどを使い、何がどこまでできるか、SEO考慮して普通に実装できるかを試していて、もしうまくいく兆しがあれば、換装していく予定。
WordPressのテーマなどに依存しないサイトデザインや設計をこのサイトで具現化していこうと考えているので、また何か更新した時は記事にしていきます。
ゆくゆくはNuxt.jsやNext.jsのSPAでと考えているものの、まだ技術的な城壁が多少あるので手軽なMarionetteJSを使って、取り急ぎ、EJSベースにしているブログ記事更新をWordPressのREST APIベースの管理にしようと現在対応しています。
大まかな表示ができるようになってきたので、あとはカテゴリーなどの一覧表示や検索、ページング機能を追加することで一旦は過去の記事も観れるようになりそうです。
一応SPAなので更新ボタンを押した際にまた観れるようApacheで設定しています。