「豊後高田市 情報」に「フレッツ・光マイタウン開通」を公開しました。
- 工事までの具体的な流れ
- 準備しておくもの
- 機器写真
- インターネット接続について
- CTUの設定方法
- CTUのチューニング
- 速度測定結果 他
「豊後高田市 情報」に「フレッツ・光マイタウン開通」を公開しました。
最近トレンドなフィッシングメールをピックアップ
バッファローLinkStationの管理画面が重い
最近主流のPC用ディスプレイ解像度は?【過去10年間の推移】
ウイルス!?パソコン不具合で慌てて20万円の請求が来るカラクリ
WordPressテーマXeory Extensionのナビメニューを修整する
光ネクストへ切り替わったのでルータ新調で下り320Mbps
偽サイトに嵌って防衛手段を検証する
Google AdSenseで広告が表示されたりされなかったり
タリーズ オンラインストアでカード情報が漏洩【ペイメントアプリケーションの改ざんについて】
Windows 10 April ネガティブクエリ100に全力レス
Windows 10 April 2018(1803)の不具合【前編】
XMLサイトマップをGoogle Search Consoleに準拠
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 […]
いまだに回線もサーバーも自社運用しているWeb制作会社がクラウド(VPS)への移行を考えて現在の構成を見直してみる。ランニングコストもさることながらスキル習得に無駄な時間を注ぎ込んできた気がする。
アクセス解析を見ていたら、ここ最近のWindows 10アップデートに関係する検索クエリが多く、さらにネガティブワードだらけで、改めて大きな問題なんだと認識しました。 復旧しようと何日も寝ずにがんばって再インストールから何からしてみたあげく、ハードを疑いだして何時間もかけてデバイス買いに行って取り付けてみたものの結局変わらず無駄な出費だけがかさみ(←それ私)と、パソコンが利用できないとどうしようもない方々や、スマホから情報収集したりと、人それぞれの重みを感じる検索クエリ達。 windows10 1803 不具合 一番人気。不具合てんこ盛りですもんね。 windows10 1803 chrome そもそもの始まりはChromeがフリーズするあたりからでした。 kb4103727 失敗 守護霊のおかげかもしれません!様子見ましょう。 kb4103727 不具合 はい。私はなんとか削除できました。 windows10 1803 不具合 ネットワーク 具合が悪くなるとあっちもこっちも辛くなりますよね。 windows10 kb4103727 シュールですね。 1803 windows10 不具合 そういえば「Windows」と「10」の間に半角スペースが入っているのを最近知りました。 1803 不具合 「デリーの戦い」に勝るとは。 intel ssd 1803 SSD買いに行ったお店で店員さんも言ってました。 kb4103721 ssd 登場しましたね、3721。 kb4103721 削除 私もしました~ kb4103727 インストールできない 幸せかも。 4103727 エラー 該当の郵便番号は無いようです。静岡県っぽいですけど。 kb4103727 再起動 1週間で再起動100回以上しました。SSDを誰よりも活用しているかも。 kb4134661 不具合 1709も戦ってますね! win10 kb4103727 昔「ホムペ」って言う人に違和感覚えていたのを思い出しました。 windows 10 1709 kb4103727 お手本のようなワード区切り。 windows 10 april 2018 update 不具合 Aprilとか1803とかRS4とか呼び名多すぎですよね。 windows 10 kb4103727 情報リテラシー高そうな方ですね。 windows […]
HTML5・CSS3に対応しているLeafletという地図表示スクリプトがヌルヌルと動いていい感じです。 これを使ったLeaflet-MapというWordPress用のプラグインがあり、喜んで使ってみたのですが、場所を登録するのに少し手間がかかります。 一つのマップに一つのマーカーを表示するのに特化した、LatLng(経度緯度)を意識しないでもいいGUIタイプのプラグインWP Leaflet Mapperを作りましたので、良かったらお使いください。 地図タイルはOpenStreetMapまたは地理院地図に対応しています。 readmeに書き忘れてしまいましたが、マップ表示のショートコードは[lmap]で表示されます。(エルマップです。アイマップやイチマップではありません) WP Leaflet Mapperのダウンロード 必須leaflet-mapper.zip(WordPress用MAP登録プラグイン) Download WordPress公式サイト 当サイト ※WordPress公式サイトからのダウンロードをおすすめします。(名称を変更等、新しいバージョンになっています) Leaflet-Mapperのインストール方法 普通のプラグインと同じですが、まだWordPress.orgには登録されていませんので、zipアーカイブをダウンロード・解凍したものをFTP等でアップロードしてください。 【2019.05.01追記】令和初日にWordPress公式プラグインとして登録されました。その際leafletから始まる名前はNGということで、正式名称がwp-leaflet-mapperとなりました。 上記よりleaflet-mapper.zip(またはwp-leaflet-mapper.zip)をダウンロードする パソコンで解凍する /wp-content/pluginsディレクトリにleaflet-mapperフォルダをアップロードする WordPressの管理画面からプラグインを有効にする WP Leaflet Mapperの使い方 必要に応じて「設定」-「Leaflet-Mapper」から初期設定をする 各投稿ページ下段にマップが表示されているので、マウスをドラッグして位置を合わせ、ホイールでズーム倍率をいい感じにする ショートコード[lmap]をマップを表示した […]
小中学校でZoomを使った遠隔授業を「安全」「簡単」に行うQRコードの作成方法と、実際に授業へ導くためのフォーマットの作成方法の紹介。
新型コロナウイルスで休校中の学生を持つ親として学力の低下を懸念。 オンライン学習の早期実現に向けて、素案やZoomに代わるオンラインミーティングツールを独自の視点で考えます。
Webコンテンツの制作をするにあたって、Internet Explorer/Google Chrome/Firefox/Safariといった主要ブラウザに加えて携帯電話での表示も乱れないようにと、クロスブラウザ対応に多くの時間を費やしてきました。 その後HTMLの文書構造が重要視されるようになり、テーブルタグを使ってページレイアウトをすることも減り、またフラットデザインというシンプルなデザインが好まれる風潮になり、クロスブラウザ対応もだいぶ楽になりました。 さらにスマホやタブレットが急速に普及したおかげでレスポンシブデザインが主流となり、構造化されたHTMLとメディアクエリを書いたCSSで多くのブラウザに対応できるようにもなりました。 さて前置きが長くなりましたが「今後何を基準にレイアウトを決めようか」と悩む出来事がありました。 下記をご覧ください。このサイトの記事です。 見る人の設定次第で表示は大きく異なる どちらも同じ記事です。 1枚目が私の見ている環境、2枚目が一般的な表示環境です。 このコンテンツは「WordPress」+「海外のテーマ」を1時間程度の簡単なカスタマイズだけ施したものですが、パソコンから閲覧する際に、Windowsやブラウザのフォントサイズを巨大化させているのを忘れていました。 数年前から近眼なのか年のせいか、小さい文字が非常に疲れるんです。 高解像度ディスプレイは人間の目の限界超え 時々訪問先で「文字が小さくて」という話を耳にするのですが、拡大表示設定などをすると、文字がぼやけてしまいとてもお勧めできるものではありませんでした。 XGA(1024 x 768)がまだ出たてのころ、とある会社の社長デスクの設定を行った際に、VGA(640 x 480)にしたらとても喜んでもらったことがありました。内心(「もったいない…」)と思っていましたが。もう文字滲みまくり。 若い人は解像度が高い=多くの情報が表示できるというのを好みましたので、設定で文字を大きくするような人はあまり見かけませんでした。 しかし最近はディスプレイの解像度が高くなりすぎて、そのままでは非常に小さい文字となってしまうため、OSやアプリによる拡大表示機能が充実してきています。 [DropWin src=”https://www.ii-sys.jp/tips/506″]4Kモニ […]
10年以上ぶりにPukiWikiをいじっているんですが、昔の情報は豊富にありますが最近の情報が乏しいですね。 PukiWikiの全盛期は、Nginxが誕生したばかりでしたので仕方ないのかもしれませんが。 PukiWikiのindex.php無しでURLを統一する URLの正規化としてまず、 http://example.com/ http://www.example.com/ https://www.example.com/ これらをhttps://example.comに301リダイレクトしました。 これについては各所に載っているようにserverディレクティブを追加して、return 301~といった感じです。(ここでは詳細は割愛します) これで完璧!と思いつつGoogle Search Consoleを眺めているとindex.php有りと無しが…。 pukiwiki.ini.phpの設定でindex.phpを表示しないという項目があります。 // Shorten $script: Cut its file name (default: not cut) //$script_directory_index = ‘index.php’; コメントアウトを外して試してみましたが、何かが違う。 確かに表示はされなくなりました。 index.php有りの膨大なURLがすでにGoogleにインデックスされているので、index.php有りで404エラーになると困るのですが、結果はindex.phpを入れたURLでもちゃんとページが表示されました。 しかしindex.phpが表示されたままの状態。ステータスコードは200。index.php有りと無しの両方のページが存在した状態です。 ということでNginxの設定を変更しました。 server { if ($request_uri ~* “^(.*/)index\.php(.*)$”) { return 301 $1$2; } } 上記のようにdefault serverディレクティブに書き加えて、 nginx -s reload で完了です。 PukiWikiネタってまだ需要あるんでしょうか。 今回PukiWiki 1.5.2(utf8)をベースに以下のようなカスタマイズをしたのですが、要望があれば時間を見つけて記事 […]
最近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を正確に書きます。
VMware Playerでテスト環境用に構築した仮想マシンを複製しておきたいと思いネットで調べたところ、なんだか少し面倒くさそうに書いてある記事が多かったのですが、3ステップの簡単操作で出来ましたのでメモしておきます。 VMware仮想マシンの複製【3ステップ】 【ステップ1】ワーキングディレクトリ(ゲストOSフォルダ)の複製 VMware Playerは終了しておきます。 ゲストOSがサスペンド状態であれば、その作業状態のまま複製されますが、ネットワーク等の初期化のために後で再起動する必要があります。なるべくゲストOSはパワーオフの状態にしておいたほうが良いです。 【ステップ2】.vmxファイルのdisplayNameを変更 コピーしたフォルダの中にある拡張子がvmxのファイルをテキストエディタで開きます。 この作業をしないでも問題ありませんが、同じ仮想マシン名が複数あると自分自身で区別がつかなくなりますので末尾に数字を足す等の変更をしておきます。 【ステップ3】VMware Playerで仮想マシンを開く 新しく作成したフォルダにある.vmxファイルを選択します。 VMware Workstation Player上での各種OS動作報告 ichmyさんの「VMwareで遊ぼうのこーなー」というコンテンツがおすすめです。
WordPressに301リダイレクトを設定するSimple 301 Redirectsというプラグインを導入しました。 PukiWikiで運用していた旧コンテンツをWordPressに引き継いだ後に、Google Search Consoleのクロールエラー対策&SEO対策です。 PukiWikiからのデータ移行については下記の記事をご覧ください。 https://www.ii-sys.jp/notes/716 WordPress用プラグイン Simple 301 Redirects 必須WordPress用プラグイン Simple 301 Redirects Download WordPress公式サイト Simple 301 Redirectsというプラグインですが、phpファイル1つだけで構成されていて、管理画面もURLを設定するだけという名前の通り非常にシンプルです。 Google Search Consoleでクロールエラーが出ているURLをコピーしてRequest欄に貼り付け、リダイレクト先のURLをDestination欄に貼り付けて「変更を保存」ボタンをクリック。 しかし挙動を確認するまでもなく、Request欄に貼り付けたはずのURLが一部消えてしまいます。 どうやらURLエンコードされている部分が消失してしまっているようです。 ソースコードを追いかけてみると、保存する前にWordPressの関数sanitize_text_fieldが呼ばれていました。 WordPress関数リファレンスを見ると、 オクテット(’%’ に続く 2 桁の 16 進数)を除去します。 と明記されています。 これは日本語を含むURLの場合は致命的で、それ以外にも「/」を「%2F」にエンコードするような仕様でも困ったことになります。 プラグイン「Simple 301 Redirects」のカスタマイズ セキュリティ的なリスクを承知の上で、wp-simple-301-redirects.phpの188行目と189行目にあるsanitize_text_field関数を削除しました。 wp-simple-301-redirects.php 変更前 for($i = 0; $i < sizeof($data[‘request’]); ++$i) { $request = […]
見やすいコード表示をするhighlight.jsをさらに便利にするための拡張スタイルシート。WordPressであまり使われることのないイタリック体アイコンボタンを押すだけで、任意の範囲を強調表示できるようになります。
ConoHa VPSが2020年1月29日からSSD容量と料金が改訂されましたが、放っておいても既存のサーバーには適用されません。 適用させるには以下の手順が必要になります。 旧サーバー停止 ※自動バックアップを設定している場合には不要 旧サーバーのイメージ保存 ※自動バックアップを設定している場合には不要 新サーバー追加(保存イメージから) 旧サーバー削除 これで新契約の内容となります。 料金が重複してしまうのではと思い、問い合わせをしてみたところ以下のような回答をいただきました。 ConoHaのサービスについては1時間毎の課金となりますので 料金についてはご任意のタイミングで削除し1時間後に新たに サーバーを追加することで料金の重複は発生しないものとなります。 1時間毎の課金ですが、上限を超えると固定(1か月料金)となるため、その場合は「旧サーバーの1か月分+新サーバーの時間課金」になると思われます。 新サーバー追加後すぐに旧サーバーを削除すれば、多くても5日分増える程度ですね。 契約自体は上記で移行されますが、SSD容量が50G → 100Gになったとしても、パーティション操作等をしなければ意味がありません。 また、IPアドレスが変更になるためネームサーバーのIPアドレス変更も必要になります。 FreeBSDのパーティション拡張については下記の記事をご参照ください。 https://www.ii-sys.jp/notes/2211
小中学校のiPadやChromebookでバッテリー持ちが悪い端末をモバイルバッテリーを使って延命させる、GIGAスクールサポーターの実体験。
WordPress管理画面のユーザー一覧から不要な項目を削除・オリジナル項目を追加し、並び替えができるように設定する方法をコピペ可能なソースで紹介。
