cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
OCNのPOP・SMTPメール設定をBecky!にする方法
自社・自宅サーバーをVPSに移行するための有力候補3サービス
Google reCAPTCHA v3をコピペで簡単に導入
WordPressの新エディタGutenbergは待ち望んでいたUI
PukiWiki 1.5.2対応XMLサイトマッププラグイン
XMLサイトマップをGoogle Search Consoleに準拠
フレッツ光を使っている人はウイルス対策ソフトを買う前に確認
ConoHa VPSリニューアル後のプランに移行する方法
時代錯誤な自社サーバーをクラウド(VPS)にするメリット
東芝dynabookはWindowsのクリーンインストールに対応していない
タリーズ オンラインストアでカード情報が漏洩【ペイメントアプリケーションの改ざんについて】
WordPressをお名前.comのレンタルサーバーRSプランに引っ越しをする際の注意点
Webコンテンツの適正画像サイズをディスプレイ解像度の利用者統計データを元に検証します。 ホームページに載せる適正画像サイズをデータで検証という記事から11年も経ってしまいましたので2018年版を載せました。 (StatCounterによる統計データを元にしています。) 2018年版が確定したのでデータおよびグラフを修正しました。 2019年版も(確定版ではありませんが)掲載しました。 Webコンテンツに使用する画像サイズ結論 掲載データが多くなってしまいましたので、結論を先に書いておきます。 パソコンのモニター幅いっぱいの可変サイズの画像(ヘッダ等)を想定するのであれば、(w)2,000ピクセルは必要。これくらいあれば(w)2,560ピクセルで表示したとしても耐えられるクオリティ。10年前に比べると回線環境は良くなったとはいえ、画像サイズが大きくなれば読み込みに時間がかかり、またスマホユーザーに無駄なデータ通信量を消費させてしまう。 記事に添える画像は300~800ピクセル程度のサムネイルを表示して、高解像度が必要であれば元画像にリンクを張る。 レスポンシブデザインの場合、表示サイズと同等にリサイズされた画像が表示される工夫が必要。(CSSにwidthを書いても元画像が同じであればデータ量は変わらず、w320のスマホユーザーにw2,000の画像を送り付けるという事態に。) jQueryで端末サイズに応じて読み込む画像を振り分けるのが今のところ良さげ。 下記のようなメディアクエリーを書いても読み込む画像が増えるだけで逆効果。 <img class=”w1920″ src=”../img_1920.png” /> <img class=”w480″ src=”../img_480.png” /> .w1920 { display: block !important; } .w480 { display: none !important; } @media only screen and (max-width: 480px) { .w1920 { display: none !important; } .w480 { display: block !important; } } 2018年ディスプレイ解像度利用者率Best10(世界) 1366 […]
WordPress用のテーマXeory Extensionでトップページ表示用のfront-page.phpが、同じid属性の値(id=”front-contents-1″とid=”front-service-1″をそれぞれ複数)を持つ要素を出力してしまっているのを修正する方法。
インデックス登録されましたが、サイトマップに送信していません Google Search Consoleのカバレッジで緑色の有効(インデックスに登録されている)になっているものの、「インデックス登録されましたが、サイトマップに送信していません」という詳細情報が気になりました。 クリックしてみると「例」としてURL一覧が表示されます。 そのURLをさらにクリックすると、UTF-8でエンコードされたURLが表示されます。 送信しているXMLサイトマップもUTF-8でエンコードをしていますし、URLの正規化も済んでいるのになぜ? じっくりと見比べてみると、XMLサイトマップのURLはスラッシュが「%2F」にパーセントエンコーディングされているのに対して、Googleでは「/」のままです。 サイトマップを出力しているphpソースを見てみると、PATH_INFOをrawurlencodeでエンコードしています。 rawurlencodeはRFC3986にもとづいて「-_.~」とアルファベット以外をすべてエンコードするようですので妥当なはずです。 Google独自仕様?と思ったのですが、RFC3986の3.4章に「スラッシュ (“/”) と疑問符 (“?”) の文字はパーセントエンコーディングする事を避けるほうがユーザビリティのためにはよい。」という記述がありました。 スラッシュはパーセントエンコードしないように修正 GoogleもRFCもスラッシュはパーセントエンコードしないと提唱しているのであれば、これに合わせるべきだと思い以下のように修正しました。 $r_page = rawurlencode($page); $r_page = str_replace(‘%2F’, ‘/’, $r_page); 修正後、XMLサイトマップの出力とGoogle Search ConsoleのURLを比較するとマッチしていましたので、これで解決です。
Windows 10 April 2018 Update (Windows 10 Version 1803)への大型アップデートが始まり、巷では不具合報告合戦が続いているようです。 私も参戦しようと思ったのですが、どうやら1803に辿り着く前のアップデートKB4103727にやられてしまったようで瀕死になりました。 スタートボタンが偶数回クリックしないと反応しない。 エクスプローラーにドライブ(C含む)が表示されない。 シャットダウンも再起動もできない。 ほぼ全てのアプリケーションが起動はするがすぐにフリーズする。 情報を調べようにもブラウザ(ChromeとFirefox)がすぐにフリーズ。 なぜかEdgeだけは機能しました。 普段使わないEdgeですが今回は役に立ちました。(ひょっとしてこれが狙い?) 更新プログラムを削除しようにも、フリーズして一覧表示されないので、思い切ってWindows 10 Version 1803へアップデートしてみることにしました。 最初のうちはサクサクと進むのに、途中から1%進むのに10分以上かかるという利用者の事を考えていなさすぎな仕様。 Microsoftに限ったことではありませんが、プログレスバーの表示は「全体の完了時間を予測してその割合」を表示するようにそろそろ改善してくれませんかね。 確か昔のWindowsインストーラは目安時間が表示されてましたが(40分とか表示されつつも平気で3時間とかかかってましたが)今の技術を使えばもっと正確な表示ができると思うのですが。 これが終わらなければ他に何もできない状況ですし、数字見ながらジーっと待ってると、もうね、詐欺にあった気分。 タバコ一箱無くなりましたがな。 ウサギと亀のウサギですか~っ! 大きな企業が大勢の人を使ってUIがどうのこうのと改善しやすい部分に時間割いて突き詰めるよりも、まずここをお願いします。 話が脱線してしましたが、画面の表示変わりました。 「以前のバージョンのWindowsを復元しています」 ( ゚ρ゚) まあ、、、システムファイルに不具合があったりすると正常にアップデートできないようなので無理もないですね。 暫く待つと、もとどおり瀕死のWindows 10 Version 1709が復元しました。 今度はセーフモードで起動してみました。 Windows 10はセ […]
WordPressに目次を自動挿入するプラグイン「Easy Table of Contents」をカスタマイズして表示を最適化したCSSを配布。
GIGAスクール構想で32GBのiPadを導入した自治体が直面しているiOS18へのアップデート空き容量の確保問題について
いまだに回線もサーバーも自社運用しているWeb制作会社がクラウド(VPS)への移行を考えて現在の構成を見直してみる。ランニングコストもさることながらスキル習得に無駄な時間を注ぎ込んできた気がする。
最近SSL化したサイトで旧サイト(http)へのアクセスが一向に減らないという現象が発生しました。 httpへのアクセスを301リダイレクトでhttpsへ遷移。 Google Search Consoleのプロパティにhttpsサイトを追加。旧サイトも削除せずに監視。 これで安心してしまっていたのですが、1ヶ月経っても、Google Search Consoleで旧サイト(http)の表示回数が減らない。(一時的に減少しましたが、盛り返してきている)平均掲載順位に至っては上昇している。 どうもおかしいと思い調べたところ、もともとHTTPヘッダとしてcanonical属性を出力していたのですが、スキンをカスタマイズした際に書き出されなくなってしまっていたようです。 これはChromeのデベロッパーツールを使って以下のように確認しました。 HTTPレスポンスヘッダ・リクエストヘッダの確認方法 Chromeを開き[F12]を押してデベロッパーツールを開く。 Networkタブを選択しておく。 HTTPヘッダを確認したいページを開く。 Nameの一番上(AdSense等がある場合は2番目以降になっている場合があります)にある該当ページをクリックする。 Headersタブをクリックするとレスポンスヘッダやリクエストヘッダが確認できます。 全てのページで<link rel=”canonical” href=”ページURL”>を<head>~</head>内に出力するように修正して完了です。 ※ページURLには各ページのURLを正確に書きます。
Windows XP関連のFAQを10年以上前にPukiWikiで公開していたのですが、最近は限られたアクセス数となっていたため、Webサイト全体を常時SSL化した際にバッサリと切り捨ててしまいました。 ですが、Google Search Consoleのクロールエラーが気になり、整備をした手順です。 プラグインで簡単にPukiWiki→WordPressにできないかと探しましたが、現行バージョンのWordPressで動作するものを見つけられませんでした。 コンテンツも100程度とそんなに多くなかったので、それぞれのページを手動で変換できればいいやと思い、PukiWiki記法をHTMLに変換してくれそうなツールを探したのですがこれも見つからず。 考えてみれば、PukiWikiの該当ページをプラウザで表示させてソースをコピーすれば良い訳なので普通は利用しないですよね。 ですが私の場合すでにPukiWiki環境が無く、そのためだけに環境を構築するのも非常に面倒でしたので…。 (WebサーバーをNginxに移行したのでさらに億劫になりました。Apache環境が手近にある方はPukiWikiを動かしたほうが早いかもしれません) PukiWiki記法をなんとかして別の表記に PukiWiki表記からMarkdown表記に変換してくれるサービスをなんとか見つけることができました。 非常に精度の良い素晴らしいツールで完璧に変換してくれます。 左側にPukiWiki記法のソースコードを貼りつければ、右側にMarkdown記法に変換されたものがリアルタイムで表示されます。 ここで一つ問題が発生。 Markdownには<dl> <dd> <dt>といったdlリストの記法が存在しません。 幸い上記の変換サービスでは行の先頭にdt ddと残してくれます。 これを使ってテキストエディタ(秀丸)で全置換を行いました。 検索:dt (.+)\ndd (.+)\n 置換:<dl><dt>\1</dt><dd>\2</dd></dl>\n ※正規表現です これでMarkdown記法+HTMLタグになりました。 MarkdownをHTMLに変換 MarkdownをHTMLに変換するサービス […]
WordPressテーマXeory Extensionの「グローバルナビ」と「プライマリーナビ」メニューを表示順や見出しをカスタマイズしてUI的に使いやすくする方法。
WordPressの引っ越しやドメイン変更の際に「All-in-One WP Migration」よりも「Search Replace DB」を使った方が良い理由。Search Replace DB日本語版のダウンロードができます。
NPO活動が停滞していましたが、Googleのサポートプログラムにより兆しが見えました。 Google Adwords(オンライン広告)を毎月1万USドル(約100万円分)まで無料で利用できるというものですが、登録時に一箇所問題が生じました。 Ad Grantsアカウントで広告設定をすると「お支払情報の確認」ページに「設定の必要がない」旨表示されるはずなのですが、何度やっても支払情報を求められてしまう。 うっかり入力してしまうと、毎月100万円程度の支払いが発生してしまうそうなので、初めてGoogleサポートに電話をしてみましたが、解決に至らず。(待たされることもなく、とても温かみのある人間的な対応でビックリしました) その後、いろいろいじってみて分かったことが、 複数のGoogleアカウントを利用している事 が原因でした。 恐らくブラウザのキャッシュが原因だと思うのですが、アカウントを切り替えても他のGoogleアカウント情報があるとダメでした。 Chromeでは複数のGoogleアカウントが登録されてしまっていたので、Googleアカウントが何も登録されていないfirefoxを使ってみたところ一発でOKでした。 以下追記 数時間待っても広告が配信されず、Adwords管理画面を確認すると「アカウントは有効ではありません」の文字が。 あれこれいじってみましたが、毎月100万円の請求が来る可能性もある部分ですので、再度Googleへ電話してみました。(相変わらず1分も待たされませんでした) アカウントの現在の状況を確認していただき、ワンステップずつ丁寧に教えていただき無事解決に至った内容です。 Google非営利団体向けプログラムを開いて、ログインされていなければログインする。 こんな画面が表示されます。Google Ad Grantsに「登録」ボタンが表示されている状態では、まだ申請が終わっていません。 指示に従ってAdwordsのIDを入力するとこのようになります。 10営業日ほど待ちます。(今ここです。) Adwordsで広告登録をしたあとに 「おめでとうございます!新しい広告の掲載が始まります。」 というメールが届き安心していたのですが、手動でAd GrantsとAdwordsを結び付けなければいけなかったようです。 Googleのこのプログラムは、システ […]
NTTのフレッツ光プレミアムが2019年1月末で終わるという事で、トラブルの出尽くしたであろうギリギリで切り替え工事をしてもらいました。 「ハイスピード」と「ハイスピード隼」が選べましたが、工事に何倍も時間のかかる「ハイスピード隼」でお願いしました。(工事に来ていただいた業者様、忙しい時期にありがとうございました) タイトルの「下り速度320Mbps」ですが、実は古いルータ(NEC WR8700N)の有線接続で出た数字です。 あ、すみません。画像加工してMbpsをbps表記にしてあります。 オリジナルは↓これです。 WR8700Nのレビューはこちらが参考になります。 2010年の製品ですのでIEEE802.11n/11aしか対応していないのと2ストリーム(アンテナが2本)のためか、別の階でのWiFiは遅く、3台・4台と接続すると良く通信が切れたりしていました。 業務用はYAMAHA、家庭用はNECという信念を10年以上貫いてきましたが、家庭用ならバッファローもありかな…と。(NTTが切り替え工事の際に施策ルータとして提供しているのがBuffalo又はYAMAHAだったのがトドメ) お買い得品をネットで見つけて買ったのが「WSR-2533DHPL」です。 バッファローのルータは、WSR-2533DHP(L無し)とかWXR-2533DHPとか間違い探しみたいな型番号が多いので、気を付けてください。 IPoE(IPv6)には対応していませんが、4ストリームで1733Mbps(5GHz)+800Mbps(2.4GHz)が魅力で実売価格7,000~8,000円。 9年前の機器とはさすが違いますね。 別の階で2台のパソコンを使っているのですが、どちらもUSBタイプの無線LAN子機を使っています。それも1,000円もしない11acには非対応で2.4GHz専用のもの。 それでも平均して下り速度100Mbps~200Mbps 出ています。 さらに非常に安定しています。 有線もすいている時には400Mbpsを超えます。 スマホやタブレットもWiFi回線が安定し、ブロスタやスリザリオがぬるぬる動くようになったと評判です。 屋根裏に潜ってLANケーブル引っ張ろうかと、釣り竿まで用意していたのが不要になりました。 無理なら屋外から引っ張ろうと、防水LANケーブルを「欲しいものリスト」に […]
サーバーを運用してきた18年間に遭遇したバックアップ・リストアの具体的な問題と改善策をまとめてあります。
世界中でGoogleを知らない人はいないといっても過言ではないほどの巨人。 インターネット黎明期の20年程前は利益を考えないベンチャーとして不気味な魅力がありましたが、最近は大きくなりすぎてしまった弊害が目立ちます…。資本主義の限界なんでしょうか。 Googleの主要サービス 検索エンジン 翻訳サービス 地図サービス メールサービス 広告サービス カレンダー YouTube Google Play Googleに踊らされている人たち 世界地図から住宅地図の尺度まで自在に表示できるGoogleMap、それも無料で使えるとあって多くのWebサイトやシステムにも導入されてきました。 私も例外ではなく、過去に制作してきたコンテンツの多くにGoogleMapを利用させてもらってきました。 ある時規約が変更され、登録しないと表示されない仕様&表示上限が設けられ、さらに規約変更が重ねられて、今では1,000回表示で7ドルに。 今やネット上の情報を検索するにはGoogleに登録されていなければ、砂漠のド真ん中にお店を開店したようなものです。 検索エンジン大手もほとんどが独自システムの開発をやめてしまい、Googleのシステムに頼っている一強の前で、検索アルゴリズムが変更されるたびに為すすべもなく、阿鼻叫喚の巷と化しています。 無料提供されてきた翻訳APIが有料化になったこともありました。 一部の国ではGmailの有料化。 もうある意味「神」ですね。生かされているので何も言えない。 検索エンジンの初期から一貫して「競合を圧倒したサービスを無料提供して、ライバルを撤退もしくは吸収したうえで市場を独占して、十分なアドバンテージができたところで有料化」という完璧なビジネスモデル。 なんかgifやmp3と似てるんですけどね。 世界中を敵にまわして事実上敗北してしまったUNISYS社らとの大きな違いは、企業として巨大化するまでじっくり待ったのと、エンドユーザからは徴収しないという方針でしょうか。 その気になれば規約やアルコリズムをちょいちょいと変更して、自社に都合の悪い情報を抹消する事なんて簡単なわけですし。 スマホは現在Apple(iPhone)が対抗していますが、勢いがなくなってしまったら次はAndroidですよね。 Androidに乗っかっている日本企業、大丈夫でしょうか。 Gma […]
