投稿者: 伊東 輝

投稿日:

EmEditorで巨大ファイルを開く（サクラエディタとの性能比較有り）

テキストエディタとしてはサクラエディタが良く使われると思います。
しかし、サクラエディタで重いファイルを開こうとして時間がかかってしまった、ということもあると思います。

そこで役立つのが、EmEditorです。
EmEditorは、サクラエディタとほぼ同時期（2000年頃）に生まれたWindows用のテキストエディタです。
サクラエディタと比較すると、巨大ファイルを開く時の速さに定評があります。

EmEditorはこちらからダウンロードできます。
有料版もありますが、今回の用途であれば無料版の「EmEditor Free」で十分です。
https://jp.emeditor.com/#download

参考までに、実際にどれほどの差があるのかを計測しましたので、計測結果を公開します。
先に結論を書くと、今回の計測では、EmEditorの方が40倍以上ファイルを早く開けるという結果になりました。

【動作環境】

  • OS：Windows8.1 64bit
  • CPU：Inter(R) Core(TM) i5-4210U CPU @ 1.70GHz 2.40GHz
  • メモリ：8.00GB
  • ディスク：SSD 128GB
  • EmEditorのバージョン：Version 21.6.1
  • サクラエディタのバージョン：Ver. 2.2.0.1

【開閉対象のファイル】

・約170MB（179,148,566バイト）

【計測結果】

・EmEditor(Free版)

・サクラエディタ

いかがでしたでしょうか。

今回はちょっとした作業テクニックの紹介でした。
ファイル編集に関しては、サクラエディタ以外のテキストエディタはあまり使われないと思いますが、今回紹介した通り、他のテキストエディタを併用すると作業を効率化できる場合があります。

このようなちょっとした小ネタも今後取り上げていきたいと思います！

投稿日:

相手の論理に乗っかった主張が最も受け入れられやすい

交渉や議論の場で、相手の主張に対して自分の主張を通したい場面があるとします。
この場合、相手の論理に乗っかった形で展開される主張が一番通しやすいです。

相手は、何かしらの主張を行う際に、論理を積上げます。
その論理の中で何かしらの問題点があれば相手の主張は崩れるので、相手は相手自身の論理を否定することができません。
そのため、相手の論理の中で自分の主張に取り込むことができる部分があれば、その部分は相手に否定されることがなくなります。

例えば、自分が投資商品の販売員だとし、相手が見込客だとします。
そして、相手が、以下のような主張をしたとします。
主張　「私は投資はしない」
論理①「私は心配性なので、リスクは負いたくない」
論理②「投資は金額が減ったり増えたりするので、リスクがある」
論理③「だから、私は、投資せずに全額預金する」

ここで、相手の論理の中には、自分の主張に取り込めるものがあります。
それは論理①です。
預金は見た目の金額は減らないものの、物の値段が上がった時（インフレになった時）に、実質的に金額が減るデメリットがあります。
しかし、金（金属の金）へ投資していれば、物の値段が上がった時に金の値段も上がり、金の値段が上がったタイミングで換金することでそれを防ぐことができます。

以上のことを踏まえると、以下のように論理を組み立てることで、少なくとも論理①の部分については否定されることがない強固な主張となります。
主張　「あなたは金へ投資した方が良い」
論理①「あなたは心配性なので、リスクは負いたくない」←絶対に否定されない
論理②「預金はインフレの時に価値が目減りするリスクがある」
論理③「だから、あなたは、資産の一部を金で持った方が良い」

なお、心理学には似たような概念として、「一貫性の原理」というものがあります。
「一貫性の原理」とは、「人間は、やると決めたことや人に宣言したことを、一貫性をもってやり遂げようとする傾向がある」という原理です。
「その方が社会的に信用を得やすい」という理由と、「その方が判断にかかるコストを少なくできる」という理由により、このような傾向になりやすい、と言われています。

ただし、「一貫性の原理」は、論理について説明した概念というよりは、心理的バイアスについて説明した概念であるため、今回の私の記事で説明したテクニックとは少し趣が異なってきます。
論理を組み立てるというよりは、人間のバイアスを使った少しずるいテクニック、という色が強くなります。

いかがでしょうか。

IT業界においては、設計したりプログラミングしたりするだけでなく、時には交渉や議論が必要になります。
そこで、今回取り上げたようなテクニックが役に立つことがあります。

交渉や議論におけるテクニックはこれからも解説していきたいと思います！

投稿日:

サクラエディタの置換機能を使った簡単な独自ソート

サクラエディタの機能として昇順・降順ソートが用意されていますが、それ以外の独自の条件でソートを行いたい場合、置換機能を上手く使うことでソートできる場合があります。
改行コードを一時的に置き換えて１行のファイルにするのと、参照機能で並び替えを行うのがポイントです。
マクロとして保存すれば、繰り返し実行することもできます。

本来はjavaやC#等のプログラムでソートするべきだとは思いますが、障害対応等で急ぎで作業する必要がある場合に使えるテクニックです。

例えば、下記のCSVファイルについて、2項目目が”END”のレコードを一番最後のレコードに持って行きたいとします。

その場合、下記のように置換すると、上手くソートできます。
（改行コードはCRLFとします）

１．改行コードを独自の文字（ファイル中に出てこない任意の文字）に置き換える

置換前：\r\n
置換後：@

２．参照機能により、”3,END@”を一番後ろに移動する

置換前：(.+@)(.+,END@)(.+@)
置換後：${1}${3}${2}

３．２の操作について、”END”のレコードが一番最初にきた場合の考慮でもう一度置換

（２の操作だと”END”のレコードが一番最初にきた場合に置換条件を満たさない）
置換前：(.+,END@)(.+@)
置換後：${2}${1}

４．独自の文字を改行コードに戻す

置換前：@
置換後：\r\n

いかがでしたでしょうか。

運用作業の中には、障害対応のような迅速性が求められる作業も存在します。
作業を早く正確に行うためにはショートカットキーを覚えるのも有効ですが、このようなデータの取り扱いの小技を使いこなすのも重要です。

このような小技はこれからも紹介していこうと思います！

投稿日:

OSI参照モデルの一覧表

OSI参照モデルとは、ノード（コンピュータ）間の通信を定めた規格のことで、通信に必要な要素を７つの層に分けて規定しています。
この規格により、異なるベンダの機器を使用していたとしても通信が行えるようになっています。

OSI参照モデルについて、応用情報処理技術者試験で出てくるレベルの知識はないと、ネットワークエンジニアと会話することができません。
その意味で、アプリケーションエンジニアであったとしても、必要な知識になります。

今回、OSI参照モデルの規定内容・主なプロトコル・主な通信装置を一つの表にまとめましたので、公開します。
この表で知識を整理するだけでも、応用情報処理技術者試験の問題は概ね解けるはずです。

いかがでしたでしょうか。

今回は、自分の頭を整理するために作っていた一覧表を公開しました。
このような一覧表は時々作成するので、これからも公開していきたいと思います！

投稿日:

トラブルのインパクトの大きさを過小評価すると大トラブルが起こる

システムの運用においてトラブルの対策を考える際、インパクトが大きいトラブルに対しては大きな労力を、そうではないトラブルに対しては小さな労力をかけるのが効率的です。

ここで、ホビーの売買サイトの運用を例に挙げて説明します。

例えば、エンドユーザーが直接触る画面において、金額計算を間違えてしまった場合、直接クレームに繋がってしまいます。
このようなインパクトの大きいトラブルの発生が想定される場合、予め念入りにテストしたり、本番リリース後にもテストを行ったりして、トラブル発生を防ぐために大きな労力をかける必要があります。
その結果として、実際にそのようなトラブルが起こる可能性は小さくなります。

逆に、管理者しか触らない画面において誤字がある、という程度のトラブルであれば、謝罪して修正してリリースすることで、大事にならずにトラブルを解消することができます。
このような軽微なトラブルについては前述のような念入りなテストを行ったり体制を用意する必要性は薄く、他のトラブルの対策に労力を割いた方が効率的になります。

しかし、トラブルのインパクトの大きさを過小評価してしまった場合、本来かけるべき労力をかけずに、高確率で大きなトラブルが発生してしまいます。

例えば、１日の売上記録を他システムへファイル連携するバッチ処理を想定します。

当該の他システムが開発中であり、その他システムではただファイルを受信しているだけであれば、ファイルの中身が誤っていたとしても後で時間をかけて検証して修正すれば、大きなトラブルになることはありません。
このトラブルで済むのであれば、開発者が作成したデータでテストで済ませ、リリース後も後で時間をかけて結果を検証する、という程度の労力でも通常は問題ありません。

しかし、開発中でファイル未取り込みだと思っていた当該の他システムが、実はファイル取り込みも行っている、しかも管理者がシステムテストのために処理結果を見ている、となった場合、システムテストのスケジュールに影響を与えてしまうというトラブルになってしまいます。
更に、取り込んだデータの修正も必要になるため、リカバリーにも時間がかかるという厄介なトラブルになってしまいます。
このレベルのトラブルになってしまうのであれば、本番データを想定したテストを事前に行い、リリース時も事前にファイルを出力し、出力結果に問題がある場合はファイル送信を差し止める、といった対応が必要になります。
前述のような少ない労力の対策では、本番で厄介なトラブルが発生する確率が高くなってしまいます。

このように、トラブルのインパクトの大きさを過小評価してしまうと、大きなトラブルに発展してしまう可能性が高まります。
それを防ぐために、トラブルのインパクトの大きさは予め有識者に確認しておく、確認できない場合は大きなトラブルが発生することを想定して労力をかける、ということが必要になります。

いかがでしたでしょうか。

今回は実務で発生したことを元にして、得られた教訓を記事として残しました。
実務から得られる教訓は貴重なものですので、これからも文章として残していきたいと思います。