スモールビジネスのIT日誌

• (2021-01-15 06:01:04)

2つのcssファイルのマージ

ワンカラムだから楽になる？

近年の html/css の高度化はもはやボクみないな片手間でやっている素人が扱えるレベルを超えていて、webのフロントエンドを専門とするデザイナーやコーダーに書いてもらう時代となっている。

スマホ普及でモバイルファーストとなった2015年くらいから、webもワンカラムが主流。

レスポンシブがいいのだろうけど、面倒なので、PCも含め「基本ワンカラム」で書いとけばいい。

ワンカラムなので、もはやレイアウトという考え方はなくなり、デザインなんて考えなくてよくなるのかな？と思っていた。

情報を伝えるだけでよいという意味なら、ワンカラムで、上からコンテンツを順々に書いていくだけでOKである。なので、ワンカラムは入りやすく簡単。

しかし、消費者に対してインパクトがあるページを制作しようと思えば、それなりに高い技術が必要ということは変わりなかった。

それにワンカラムといったって、PC表示とその操作性を考慮すれば、やはり、レスポンシブは避けがたい。

小企業は自分でやるしかない

ボクらのような小企業の場合、秀逸なデザインを創作し、デザインに忠実なコーディングができる専任スタッフは通常いない。

外部にお願いしたいが、なかなかよい人が見つからない。

というわけで、相変わらず、自社のwebページは未だボクが制作することが多い。

作り替えの原則：旧CSSは廃棄？

今回、あるページに新しいレイアウトを導入することにした。

それで古いページからのマージが必要だが、古いページの一部はレイアウトごとまるまる転用したい。

新ページの制作の原則は「旧cssは廃棄し」かつ「新ページにはコンテンツだけを流し込む」が理想。

しかし、部分部分が、それなりに作り込まれており、まだまだ使える場合などはなかなか捨てられないケースもある。今回はそれ。

そういう部分はhtml/css ともに、そのまま移植したい。

こういうケースは今回はじめてで、いろいろ試香錯誤中である。


(1) 旧ファイル名の変更：古い html/css のファイル名に「.old」を付けた：
(新) index.html style.css
(旧) index.old.html style.old.css


(2) 旧ファイルのゴミ整理
cssは1,000行程度。相当、ゴミがたまっている。通常、cssファイルは時間とともにゴミだらけになる。以前はゴミが嫌で、不要なコードは削除するようにしていた。

しかし、そのメンテナンスのコストを考えれば、ゴミなど放置して、不具合が多くなってきたら、どこかのタイミングでバッサリと新しいものにした方が効率的だと最近は思う。

今回は1,000行あるcssファイルも、おそらく半分程度も使用していないだろうから、 html/css に関して、大ざっぱに不要・未使用部分を削除して、ある程度見やすいファイルに成形。


(3) 旧cssファイル：オリジナルのid名・class名の変更
オリジナルのid名・class名は新ファイルとの重複を避けるため、接頭子(prefix)として「2021-mergedxxx-」という名称に変更。index.old.htmlに対して、id・class名を一括置換。


(4) id名・class名以外のセレクタ
たとえば、「body, img, ul, li, h1, h2, a, a:hover, input・・」は名称変更が許されないので、原則、古い方をあきらめるが、レイアウトやデザインが大きく壊れるものはセレクタごと個別に移植する。

• (2020-12-27 09:16:50)

システム担当不在を狙ったサイバー攻撃

年末年始は長い日数、多くの企業で休暇状態となる。

システム担当者もいなくなる事が多いので、そこを狙ってサイバー攻撃をしかけてくる人々がいる。

ほとんど個人か仲間数人によるゲームとして。もしくは組織的な犯罪、あるいは軍事的野望を抱く国家組織もある。

我らのような小企業が、犯罪組織以上の組織から攻撃を受けることはほぼ皆無だが、個人レベルの攻撃なら受ける可能性は充分にある。

個人レベルの攻撃力は低いが、数が多い

個人レベルの攻撃はゲーム感覚の連中が多く、恐るるようなことはないが、問題は数が多いこと。

全世界の低レベル攻撃者は無数にいて、不特定多数のシステムに、機械的に、絶え間なく、かつ無差別に波状攻撃してくる点。

下手な鉄砲、数打ちゃ当たる方式で、やられることもある。

苦い体験

ボクの場合、10年くらい前、お正月休みに、一度ウイルスの侵入と活動を許し、HDDを一台ダメにした苦い体験がある。

だから、やはり、カラダが覚えていて、年末年始は慎重になる。ボクのオススメはPCやサーバー、ネット機器の原電は可能な限り、落としておくこと。

365日稼働という常識が、そもそもリスク

「無人で24時間・365日稼働している」という状況自体がリスクである。

そういう常識を作らせないことも、将来にわたるリスク対策となる。

当社の対策

(1) 休暇前のデータバックアップ

(2) 休暇中のサーバーやPC、ルータなどの通信機器の電源オフ

(3) クラウドやリモート、VPNなど外部につながるネットワークを止める

(4) Dropboxなどクラウド経由の自動同期プログラムなども止めておく


たとえば、必要なければ、Dropboxの自動起動なども解除しておく。

10年前のウイルス騒動ではPC一台の感染で、Dropbox経由で感染拡大するリスクがあって、汗が出た。


(2021 → 2022) 年末年始のセキュリティ対策

• (2020-12-16 13:59:01)

最小プログラム構成のマスターディスク

マスターディスクはOSだけでなく、オフィスソフト、ブラウザ、その他、最小限必要なソフトだけを入れている。

OSだけだと、そこからセットアップが煩わしいので、最小だが、一通りのソフトを入れることにしている。

しかし、ポリシーは極力不要なアプリやソフトをインストールせず、可能な限り最少のプログラム環境であること。

このマスターディスクから、下記のモデルを作成する：

(1) 業務用PC
(2) 個人用PC

業務用PCは最少のプログラム環境

業務用PCはマスターディスクから制作するが、同じく極力最小限のプログラム構成にしており、不要なソフトは入れないことをポリシーとしている。

これは近年の怪しいアプリに対するセキュリティ対策。

2世代のクローンバックアップ

業務用PCでは定期的にクローンHDDを作成する。

それを2世代作成し、古い世代を他のPCで運用することがあるが、SQL Serverなど、OSに深く絡むようなソフトが入っているので、転用はちょっとしにくいのが実情。

それに業務上のデータがディスク内に散乱しているので、削除するとしても、手間がかかること、削除しても磁気データは残留しているので、リスクという点では転用は適切ではない。

個人用PCは汚れたら戻す

個人用PCも、マスターディスクから作成する。

個人用PCは様々なアプリやソフトをインストールしても、定期的に古い比較的安全な環境に戻せる状態にしている。

個人用PCはいつでも乗り換えられるよう個人作成のファイルなどは外付けHDDに保存している。

ハードは同じものを準備すべし

ハードウエアはすべてのPCで同じ物を使用し、周辺機器も同じものをシェアする。

PCがすべて同じ場合、部品のバックアップにもなる。

周辺機器をシェアしていれば、ドライバーのセットアップなども不要。

• (2020-12-14 17:29:40)

Windowsの仕様として、ネットやUSBやと外付けHDDなどにフォルダーをコピーするとタイムスタンプが、コピー時のものに更新される。

(各々のファイルはタイムスタンプが維持される)

タイムスタンプを維持したいときは「FastCopy」を使おう。

とくに設定はないようで、デフォルトで維持されるようだ。

• (2020-12-09 13:13:32)

JNBからケータイサイト終了おしらせ

JNBから「携帯電話向けサービス終了のお知らせ」というメールが来た。

「2021年3月31日をもって、携帯電話向け（フィーチャーフォン、ガラケー）のすべてのサービスを終了させていただきます」

逆に今でも、ケータイで、ネットバンキングしていると人いるの？と驚くが、名実ともに、ケータイサイトが終了するようだ。

公共性が高い銀行のケータイサイト終了はあらゆる業種のしんがりに近いタイミングでの終了だろうから、これで社会からケータイサイトが、おおむねなくなる印象を受けた。

そこで、考えた、当社の携帯電話サイトはどうすべきか？・・

残すか？ 廃棄か？

第一印象は「残していても害はない」。

Googleや他のサイトからリンクされている可能性もあるので、削除したらページが表示されなくなる(リンク資産が失われる)。

また、廃棄すれば、かつてケータイサイトがあったという記録も失われかねない。

社内にはバックアップとしてデータは残るが、ライブサイトにデータがないと、バックアップデータの取扱い自体、適当になり、いつのまにか失われる。

反面、古くなった情報、あるいは今後古くなる情報、たとえば、販売規則や商品アイテム名、価格などはそれなりに短期間で変化している。

そんな古い情報が残っていると顧客に混乱を与え、当社にも手間が増える。ここはきれいさっぱり消した方が良いとも思う。

複数のメンテナンスポイントはトラブルの元

思えば、メンテナンスポイントが複数あるることは手間が増えて、かつ、トラブルの元だったな、と思う。

Webサイトをデバイスごとに分けて運用するやり方はケータイ時代、多くの企業が実施していたが、長年の経験からすれば、まったく得策でない。

一本に絞るべきだ。

スマホが隆盛し始めた際、Googleは複数サイトでなく、レスポンシブ・デザインで、単一サイト運営を推奨していたが、実に正しい判断だった。

メンテナンスポイントが一カ所であることのメリットは大きい、コスト的にもリスク的にも。

残すが汎用性の高い情報のみに変更

メリット・デメリットともにある、いくつか考えて、今回は残すことにした。

ただし、これを機に内容を一通り見て、詳細な情報や変更される可能性の高い内容は削除し、汎用性の高い内容だけに変更した。

結果的に内容はあまりない、ページの存在自体に意義があるかのようなケータイサイトが残ることになった。