サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
買ってよかったもの
worklog.be
Webブラウザの Google Chromeが2017年10月より、通信が暗号化されないHTTP接続を使ったWebサイトに対する警告をURLバーに表示するよう仕様変更されました。 これまでは個人情報を送信するフォームへだけが対象でしたが、今後はどんどん対象が広まっていくという事で、Web運営者の間ではちょっとした騒ぎになりました。 ところで、Webサイトの常時SSL化はどこまで暗号化されるのでしょうか? もし、完全に暗号化されるのであれば通信内容を覗き見出来なくなるので、職場で仕事に関係のないサイトを見ていてもシステム管理者(=会社)にバレない!という事になりそうですが、少し気になったので調べてみました。 スポンサーリンク 職場からHTTPサイトを見た場合 まずは職場から暗号化されていないHTTPサイトを見た場合の通信を傍受してみます。 クライアント(192.168.0.1)からHTTPサ
クローラー開発でPython製のクローラーフレームワークScrapyを使ったらめちゃくちゃ便利だったのでメモします。 Scrapyを使うと数行のコードでお目当てのデータを簡単に抽出できるので、これからクローラーを作ろうとする人なら覚えておいて損はないです。 また、Scrapyの読み方は「スクレイピー」と「スクラピー」で二通り分かれていますが、海外の動画を見ているとスクレイピーと言っているように聞こえます。 どっちなんですかね… スポンサーリンク Scrapyのインストールと新規プロジェクトの作成 今回はPython 3.7.2 (pyenv) の環境にScrapyをインストールして動かしました。インストールはこのように。 # pip install Scrapy インストールが終わったら早速、新規プロジェクトを作成します。プロジェクト名は「blogScrapy」にしました。 $ scrap
更新:2020-03-08 フッターに表示されるサイト名にもh1が適用される問題を修正しました。(include/func-custom-header.php) WordPress でブログじゃないサイトを作るため Cocoon を触ってます。 Cocoon はブログを作る時によく使う機能がほぼ網羅されていて、プラグインだとか PHP をゴリゴリいじるカスタマイズが不要で、ホントに無料?って言うくらい凄いテーマです。 自分がWordPressを使い始めた頃はPHPを触らなければ思うようにデザインも出来ないという感じでしたが、今のテーマは本当にカスタマイズがしやすいです。 しかし今回はブログじゃないサイトでトップページを作ろうとした時に、PHP のカスタマイズが必要だったのでそのやり方を書いておきます。 スポンサーリンク Cocoonでトップページを作ると普通はこうなる まずはじめに、Coc
ログイン認証が必要な Web ページの内容をスクレイピングしたくなったので Selenium を使ってみる事にしました。 認証が必要なページを自力でスクレイピングしようとすると中々大変なので、ブラウザの Google Chrome を Selenium (& ChromeDriver) から操作してしまおうという感じです。 今回試した環境は下記となります。 CentOS6 もしくは Centos7 Python 3.6.8 (pyenv) Selenium 3.11.0 Google Chrome 73 ChromeDriver 73.0.3683.68 スポンサーリンク ChromeDriverとフォントのインストール まず始めは Chrome を外部から操作できるように ChromeDriver (WebDriver) をインストールします。 また、ブラウザのスクリーンショットを撮った
WordPress で SEO 対策を目的とした、noindex・nofollowを細かく設定できるプラグインを作成したので公開します。 このプラグインを使うとこんな事が出来ます。 投稿、固定ページ、カスタム投稿タイプの noindex・nofollow 設定 カテゴリ、タグ、カスタムタクソノミーを個別に noindex する設定 投稿、アーカイブページ全体の noindex 化設定 サイトによってはカテゴリやタグも重要なページとなり得ますが、中には不要な物もあると思うので、それを細かく noindex 化して必要な物のみを検索エンジンにインデックスきるようにしようという代物です。 全体を noindex 化できるプラグインは既にありますが、個別に設定できるのが見つけられなかったので作ってみた感じです。 下記でざっくりと使い方を書いておきます。
mp4を直接配信じゃダメなの? 実のところこんな真似しなくても mp4 形式の動画ファイルを <video> タグにセットすれば簡単に動画配信はできます。 しかし、これには結構デメリットがあってユーザーの事を考えるなら HLS 形式での配信をしたい所です。 mp4は再生もシークも遅い mp4だと無駄なネットワーク帯域を消費する 簡単にダウンロード保存されてしまう 良くも悪くも mp4 は一本のファイルを配信するためか、疑似ストリーミングでも再生が始まるまで遅くシークで固まりやすいのが難点です。 トラフィックデータを計測して HLS と mp4 を比較してみると、同じ位のセッション数でも mp4 の方が無駄にトラフィクが流れていたようでした。 mp4 -> HLS に切り替えた後は体感的にも早くなり、トラフィク量も削減できたので本格的にやるなら HLS を採用したいなと個人的には思います。
無料でSSL証明書を取得できるサービス Let’s Encrypt のメモです。 今回は CentOS + Nginx の環境で Let’s Encrypt のセットアップ、証明書インストール、自動更新設定をやっていきます。 スポンサーリンク certbotのセットアップ Let’s Encrypt が発行する証明書は有効期限が90日となっています。 このままだと運用が困るのでcertbotを使い自動更新出来るようにします。 以前はcertbot-autoというツールを使っていたのですが、これが現在は新規で使えなくなったので注意です。 また、セットアップ済みのcertbot-autoは現時点(2021/8/16)でも一応動き、SSL証明書も更新されていますがいずれ使えなくなるかもしれないので早めに対応した方がいいです。 久しぶりにcertbot-autoを新規インストールしたらうんともすん
jQuery-File-Upload を利用した分割アップロードサンプル 今回は jQuery-File-Upload の分割アップロード機能 (Chunked file upload) が使えそうという事で、あちこちを見ながらカスタマイズして WEB サーバに設置してみました。 WEB サーバは下記 Nginx 1.10.1 と PHP 7.0.8 で構成していて関連する設定値は下記の通りデフォルトのままなので、その状態でも動作するように設定しています。 Nginx のアップロード上限はデフォルトの 1MB (client_max_body_size) php.ini に設定したアップロード上限はデフォルトの 2MB (upload_max_filesize) とりあえずサンプルファイル一式は zip にまとめてアップしました。 中身は下記のようになっていて “upload.html”
計測方法は VM を 1 つ起動して、fio, dd を使って RAID1 – RAID10 まで計測してスコアを取っていくというシンプルなテストです。 fio は見どころ満載な結果を吐き出しますが、今回は IOPS だけに注目。 fio では各メニュー 1 回づつ計測し、計測後は作成したファイルを削除し 10 秒スリープしてから次の測定をするようにしています。テストレシピはこんな感じで用意しおきます。 [read-1M] name=iotest directory=/home/ filename=fio.file direct=1 rw=read bs=1M size=1G numjobs=1 thread=1 [write-1M] name=iotest directory=/home/ filename=fio.file direct=1 rw=write bs=1M size=1G
WordPress のメモ書き。 とあるサイトの負荷を軽減させるために画像サーバを別建てする必要が出てきました。 サイトは WordPress で作っていて、これまでと変わらない操作で画像を管理出来るようにする必要があるため、この画像を Nginx のリバースプロキシ + キャッシュを使って処理させようと思ってます。 実体は WordPress に。画像サーバの Nginx は要求された画像をなければ取得しに行って、以降はキャッシュを返す事によってリクエスト数を分散させようという目論見です。 とりあえず今回は WordPress の画像を別サーバで処理させるためにフックを使って URL を変更してみます。 スポンサーリンク URLを置換する関数 (手抜きVer) まず最初は共通で利用する画像の URL を置換する関数から。 今回は時間がなかったのでやっつけで “/wp-content/up
WordPress で記事を投稿・更新する際に、投稿データを強制変更する方法を調べてみました。 今回は、投稿の作成・編集画面の “公開・更新” ボタンを押した際にフックで内容を書き換えてみたいと思います。 とりあえず、タイトル・本文等の “投稿データ” とカテゴリ・タグ等の “タクソノミー” を強制変更する方法を以下に記載します。 スポンサーリンク 投稿データをwp_insert_post_dataでフックする 投稿データをフックして書き換える方法はいくつかあるみたいですが、調べてみると wp_insert_post_data が使い勝手が良さそうなので試してみます。 functions.php に以下のコードを追加して “投稿タイトル” を強制変更してみます。 function replace_post_data($data, $postarr){ $data['post_title']
NginxでWordPressを使う時の設定は色々な書き方が出来ますが、ネットの情報は断片的な気がしたのでまとめてみました。 可読性良く設定をしたいのと、WordPress向けにこれだけ書けば不自由はないよ!っていうのを目的に設計してます。 スポンサーリンク 環境 各種スペックはこんな感じでやってます。 サーバはVPS (CPU: 3~4Core, Mem: 2GB~4GB 程度) CentOS 7, Rocky Linux 9 Nginx: 1.22.1 PHP (php-fpm): 8.1.13 CentOS 7は2024年にサポート期限が切れるので、今後は後継のRocky Linuxを使う前提が良いように考えています。Rocky Linux以外だとAlmaLinuxという選択肢もありますが、基本同じようにインストール出来ます。 アップデートに追随しないと後々面倒になるので、Nginx
Highcharts の応用メモ のつづきの記事です。 前回説明しきれなかった Highstock のパラメータをここで解説していきます。 スポンサーリンク Highstock の期間範囲の設定 Zoom に表示される期間の変更するには rangeSelector というパラメータを弄ります。 “4時間”, “90日”, “全データ” という期間で区切りたい場合は下記のような設定をすれば OK です。 rangeSelector : { selected: 1, // デフォルトで表示させる期間 // 0 からカウントしこの場合は日単位 buttons : [{ type : 'minute', // 分単位 (0) count : 240, // 約 240 分のデータを表示 text : 'm' // ボタンの表示名 }, { type : 'day', // 日単位 (1) coun
WordPress の管理画面内にメディアアップローダーを呼び出す方法のメモ書きです。 プラグインの設定画面等で、メディアファイルの ID が取得したいと思ったので調べてみました。 スポンサーリンク 標準のメディアアップローダーを呼び出す 今回試した内容は WordPress 3.5 以降が対象となりますが、WordPress にはメディアアップローダーを使う API が用意されています。 このあたりは流石 WordPress と言ったところ。 とりあえず必要な部分だけですが、テキストフォームとボタンのパーツを HTML で以下のように書いておきます。 <input name="mediaid" type="text" value="" /> <input type="button" name="media" value="選択" /> <input type="button" name=
注意事項 プラグインは WordPress のデータベース、wp_postmeta テーブルを更新するので、念のため DB のバックアップを推奨します。 また、このプラグインは基本メンテナンスしていませんので、バグがあったとしても気付けていません。コメントかメールをいただければ対応しますが、基本利用は自己責任でお願いします。 インストールは通常の WordPress プラグインと同じで、ダウンロードした zip ファイルを管理画面からインストールするか、zip を展開して出てきたフォルダを FTP 等で サーバ上の plugins ディレクトリにアップロードすると OK です。 プラグインを有効化すると、管理画面に「画像一括変更」というメニューが追加され下記のようなプラグイン管理画面が表示できます。 使い方は、 カテゴリ・タグから対象範囲を絞り込む 画像を上書きするかどうか決める 設定する
FreeBSD でメモリ使用量を記録しようと思ったのでその確認方法のメモ。 Linux みたく free コマンドがないので top コマンドとかを使う。 top 普段は top で確認している。Linux だとあまり top しないけど、FreeBSD は高頻度で top してる。Linux よりフォーマットが見やすい。 # top -n last pid: 8563; load averages: 0.01, 0.00, 0.00 up 64+06:30:37 18:50:31 53 processes: 1 running, 52 sleeping Mem: 267M Active, 743M Inact, 382M Wired, 420K Cache, 213M Buf, 579M Free Swap: 512M Total, 10M Used, 502M Free, 1% Inu
OSS の L7 ロードバランサ HAProxy をコマンドラインから操作するメモ書きです。 今のところ特に利用していない機能ですが、運用ツール等を作成する際には割りと使えそうなので一通り試してみます。 検証に利用した HAProxy のバージョンは 1.4.23 になります。 スポンサーリンク コマンドライン操作の準備 そのままの状態では HAProxy をコマンドラインから操作することができないので、必要な設定をコンフィグファイルに追加します。 global stats socket /tmp/haproxy-cli.sock user root group wheel level admin stats timeout 30s stats maxconn 1 . . . 各パラメータには以下のように任意の引数を与えてあげます。 stats socket <ソケットを作成するパス> <
WordPress で利用する画像ファイルを最適化するメモです。 前回の Pngcrush に引き続き、jpegtran を使って今度は JPEG 画像を最適化してみます。 インストールおよび行ったテスト内容は以下に記載します。 スポンサーリンク jpegtranのインストール 利用している FreeBSD 8.3 の環境では、jpegtran コマンドは気付いたら入っていたので特に何もしませんでしたが、ない場合は以下のようにインストールすると良いと思います。 # cd /usr/ports/graphics/jpeg # make install clean CentOS の場合は libjpeg というパッケージに含まれているので yum でインストールします。 # yum -y install libjpeg インストールとしてはこんな感じです。 jpegtranで画像の最適化 JP
ヒートマップ を簡単に実装できる jQuery プラグインを発見したのでそのメモ書きです。 何かに利用しようと思った訳ではないですがたまたま見つけて感動したのでとりあえず書いておきます。 プラグインは heatmapjs とそのままの名前ですが、公式サイト より必要なファイルをダウンロードし heatmap.js を読みこめばすぐに利用できます。 demo も同梱されていますが、そこから必要な部分を抜粋したコードが下記になります。 ※ 見つけて試しただけですので詳しい解説は無しです。 heatmap.html <html> <head> <title>heatmap.js test</title> <script type="text/javascript" src="js/heatmap.js"></script> <script type="text/javascript" src="
WordPress のテーマ STINGER5 のカスタマイズ記事です。 今回は STINGER5 (ver20141011) の functions.php をカスタマイズ & 整理していきます。親テーマはなるべく触らない方針でカスタマイズをするものの、STINGER はここを触らないとどうしようもない部分があるので最初にここから手を着けます。 自分はある程度共通利用できそうな状態まで STINGER の親テーマをカスタマイズして、その後は子テーマで個別のカスタマイズをしていくというやり方にするつもりですが、1 ブログでしか利用しないという場合は親テーマを直接カスタマイズしちゃっても良いとは思います。 今回のカスタマイズをすると STINGER5 がバージョンアップしても本家に追随はできなくなるので注意。 STINGER5 の functions.php はこんな流れでカスタマイズしてい
WordPress の style.css に任意のバージョンを設定する方法のメモです。 WordPress のテーマが使う style.css のバージョンは、意図的に消したりしなければ HTML ソース中に「style.css?ver=3.8.1」みたいに、WordPress のコアバージョンが勝手に設定されますが今回はこれを任意のバージョン番号にしてみたいと思います。 バージョン番号を任意に変更したい意図としては、Expires ヘッダを設定してブラウザキャッシュを使うようにしていると、変更がクライアントに上手く反映できなくなるのでその対策にという感じです。 スポンサーリンク style.css のバージョンをフックで任意に設定 拾い物なんですがとりあえずコードから。 function my_wp_default_styles( $styles ) { $styles->defaul
WordPress のテーマ TwentyTwelve カスタマイズメモです。 WordPress で使えるウィジェットのひとつに「最近の投稿」というものがありますが、デフォルトはタイトルのみなのでこれをアイキャッチ画像付きで表示するようにカスタマイズしました。 プラグインを探せばもっと簡単にでできるとは思いますが、なるべく外部のプラグインに頼らないというスタンスでやってきたので何とかしてみました。 カスタマイズの完成予定はこんな感じになります。 アイキャッチ画像付き最新の投稿リストの完成図 カスタマイズ方法は以下で説明していきます。 スポンサーリンク WordPressに自作のウィジェットを追加する 「最近の投稿」ウィジェットはフックできないっぽいのでウィジェット自体を自作します。 このウィジェットのコードは wp-includes/default-widgets.php にある WP_
kickstart のメモ書きです。 RHEL とか CentOS には、 OS のインストール・セットアップが自動化できちゃう kickstart という機能があります。 ものすごく便利なのですがよく忘れがちなので自分用にメモしておきます。 本当は PXE Boot + DHCP + kickstart が最強だと思ってますが、今回は PXE Boot は利用しないパターンです。 インストール・セットアップの方針はこんな感じです。 初回の Boot は Boot 専用メディアから インストールパッケージは必要最低限に インストール完了後には全てのパッケージをアップデート スポンサーリンク kickstartの準備 kickstart を使うために準備するものを以下に書きます。 ks.cfgの作成 検証用マシンを立ち上げる時は以下の様な kickstart を利用しています。(swap 小
無料で利用できる人気の WordPress テーマ stinger3 に乗り換えてみようという記事です。 これまで、WordPress の標準テーマをカスタマイズして使ってきましたが、最近 stinger3 を試してすげぇなって思う事が結構あってちょっと本格的に使ってみようかと思ってます。 2014年01月22日に TwentyTwelve ベースのテーマから、TwentyFourteen ベースのテーマへ移行させたばかりですが、過去には別れを告げて stinger3 をカスタマイズしていこうと思います。 stinger3 の子テーマを作成してカスタマイズの準備をする カスタマイズは stinger3 の本体をできるだけ触る事なくカスタマイズしていきたいと思いますので、WordPress 公式が推奨する子テーマを使ったカスタマイズでやってきます。 stinger3 はVer20140327
オープンソースの HAProxy とNginx を組み合わせてコンテンツキャッシュシステムを構築するメモの続きです。 既存の環境にも後付けできるようなコンテンツキャッシュシステムを作るという事で、前回は HAProxy について書きましたが今回は Nginx の部分について。 Nginx でリバースプロキシとキャッシュを構成して、HAProxy と繋げるまでやってみたいと思います。 スポンサーリンク Nginx の構成例 Nginx は version 1.4.7 を使ってリバースプロキシ + キャッシュを構成してみます。 下記は FreeBSD の Ports からインストールしたものですが、こんな感じのオプションを指定してインストールしてます。cache purge モジュールはぶっちゃけお好みで構いません。 # nginx -V nginx version: nginx/1.4.7
オープンソースの HAProxy とNginx を組み合わせてコンテンツキャッシュシステムを構築するメモです。 リバースプロキシ型で動作するキャッシュシステムを構成して、既に動いている WordPress を何もしなくてもキャッシュで高速化できるようなものを作ってみたいと思います。 キャッシュだけなら Nginx の単体構成が低コストで手っ取り早いですが、今回つくるシステムはリバースプロキシ型で動作するので終端のサーバの事をあまり気にする必要がなく、既存の環境へも適用しやすいのがメリットです。(じゃないかと思っています。) 構成的には下記のような感じを予定しています。 http --> [haproxy *1] -- req --> [nginx *2] -- req --> [apache] * [server] <= 物理サーバの凡例 * ip は下記を割り当て haproxy vip
このページを最初にブックマークしてみませんか?
『work.log | エンジニアの備忘録的ブログ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く