ぺーぱーふぇいす

雑記と備忘録。私はプログラマ。

Chromeに搭載される予定の広告ブロック機能とかについて

Chromeに広告ブロックが入るという2018年

結構前からだけど、Chromeにて公式の広告ブロックが組み込まれる予定だとというニュースは結構前から話題になっている。

Google、Chromeに広告ブロック機能の追加を発表。2018年の早い時期に搭載予定 - Engadget 日本版

そして最近、Chromeの試験運用バージョンである「Chrome Canary」のAndroid版にて設定画面にも広告ブロックに関する項目が現れたとか。

Android版Chrome Canaryに広告ブロックメニューが追加、2018年リリース予定 - Engadget 日本版

広告ブロック自体はChromeだけでなく、Firefoxとかにもアドオンとして既知の存在であることからするにwebサイト上の広告をブロックしようという動き自体は新しいことではない。
このニュース自体の話題性を強めるのは、よりにもよってGoogleというところなのだろう。

Googleは今でこそ色々なビジネスをやってるけど、基本的にGoogleはインターネットコンテンツの会社で、インターネットコンテンツの収益といえば広告収入であるわけで、当然Googleと広告収入は密接な関係にある。
2017年現代において、PCやスマフォを通して提供されるありとあらゆる無料のサービスが無料たる所以は広告による恩恵であり、Googleはその中でもひときわ存在感を放っている。

ニュースの見出しだけ見れば、そんなGoogleが自分の商品である広告を除外するのかってな感じではあるのだけど、実際はそんな極端に「Chromeを通して見たwebから広告をすべて抹消する」的な同族浄化作戦みたいな話ではない。例えば、テキスト広告とか小さなバナー広告とかは生き残りそうだ。
というのも今回のGoogleがブロックすると言う広告の対象になるのは、ユーザが煩わしさを感じる広告に該当するものらしく、その基準はFacebookなんかと一緒に決めているようだね。ビッグブラザーなんて呼ばれるIT企業あたりで。

ちょっと昔の広告

相変わらず中高生と団塊世代のITリテラシーは壊滅的にヤバイけど、それでも昔より遥かに(具体的に言うと10年くらい前)と比べれば誰彼かもがwebサイトを観るようになったと思う。その結果、web広告に触れる機会も当然増え、そしてあれやこれやと広告は進化、繁栄していった。

ここで言う広告の進化と繁栄というのはハッキリ言って良いものではなく悪いものだ。
どのように悪いかというと、めんどいので箇条書きにする。

  1. 画像か動画で提供され、テキストよりも遥かに情報量が多く、通信量を圧迫する
  2. 故に簡単にサイト本来のデザインを損ねる
  3. 過剰広告まがいの釣りみたいな内容で注意を引くことに必死
  4. 誤クリックを誘うような動きを持つ

などなど。
「悪質な広告なんて昔のYoutubeにもあったじゃん」なんて言われるけど、総合的に考えると今のほうがより有害に進化していると思う。
そして単純に「繁栄」と表現したのは、どこもかしも貼られているから。単純に量が増えた。それだけサイトが増えたってことだと思うけどね。

私が中学生だとか高校生だかのときに、「自分のサイトを作ろう」と考えた。
その時、「HTMLを勉強してwebサーバにアップロード」とかなんか糞めんどくさそうだなと思ってた時に@wikiに出会った。
まだそんなにwikiを利用した攻略サイトとかもそんなに多くなかった時代だったけど、とにかくもう@wikiはあった。ちょうど@wikiのトップにも「無料でホームページが作れる」とか「HTMLの知識必要なし」的な文句でキャッチしてたしね。
しかしまー当時は「有料アダルトサイトの請求」という言葉に過剰にビビっていた私は、当然webコンテンツに対して「これは無料なのだろうか、有料なのだろうか、ヒェ~」って感じで地雷原を歩くがごとくネットの樹海を散策していた。
当然、@wikiのうたう無料というパワーワードに「何か裏があるんじゃねぇの?」的な警戒をしつつ、いろいろQ&A的なの読んでたら「広告が表示されるからそれでウチらは稼いでます。だから無料です」的なことが書いてあり、幼いながらに私は「なるほどそんな商売もあんのやな」と思ったわけです。そして私は安心して@wikiで目的不明のサイトを作り、放置しました。

それくらいの時代からまわりはケータイ小説だの、ブログだの、プロフだの、mixiだのとにかく様々なサービスが無料で提供されていて当たり前の時代に突入。
高校生のボクはガラケーを握りしめ、iモードでモバゲーとかやりながら(考えてみればこの時から課金モデルも成長しつつあったな…)「広告すげー」って鼻水を垂らしていた。ユーザは無料でサービスの恩恵を受けることができ、サービス運営者は広告費が入るからまさにwin-winな関係。
まだこの時は単純にガラケーで観るiモードサイトは通信量少ない貧弱なサイトだったし、PCで観るサイトもまだそんなに表現豊かな感じではなかったから広告もそんなに煩い感じではなかった。
そんなこんなで広告費によるサイト運営と基本無料で提供されるサービスに世は情報化社会とか誰かがweb2.0とか意味のわからんことを言い出し、晴れやかでカオスな情報社会の幕開けかに思われた。

さらなる進化と汚染

ただ、やっぱりスマフォの時代が来るともうこれよ。今の現状よ。
ありとあらゆるコンテンツは過剰な広告に侵され、無料の代償はハッキリと感じ取れるストレスとして置き換わったわけですわ。
これだけ大きな市場となったweb広告業界はもうとにかくクリック数が欲しくてたまらない。高速化したインターネットに画像を載せようが、動画を載せようが、それを通信するユーザのことなんかとにかくクリックしてくれれば知ったこっちゃないという貪欲なビジネスモデルに変貌した。

しかし、それがいくらか過剰かつ害悪に思える広告でも、広告自体は必要なものだ。様々なwebサイトが無料で観ることができ、そして面白いコンテンツを提供できるのはひとえに広告収入のおかげである。
そのため、稼ぐ側ときっちりとそうした現状を踏まえたユーザから「広告はブロックされるべきではない」という広告ブロックに対する反論も生まれる。
だがしかし、結果としてやはり今時の広告はウザすぎたため、その悪性進化の果てに裁かれる時が来たのではないかなぁと思う。

浄化されよ、やや横暴でもいいから

Googleがやや横暴ながらこうした手段を取ることに批判があるのも当たり前だろう。
大雑把に言えば、「なんでお前らが勝手に決めんねん」っていうこと。
ただ、今の現状ではこうしたウザすぎる広告で溢れたwebの現状を変える力を持つのがGoogleくらいなもんだし、個人的には大きなChromeシェア、もとい「インターネットの入り口」を持つという力にモノを言わせて一度Googleがweb広告全体をどついてくれれば良いと思う。

そうすれば、一度広告業界全体が一度ユーザビリティについて考え直す良い機会になると思うし、浄化もされると思う。そしてそれを望む。

朝会とか要る?

オフィスワーカであれば朝会は不要だと思う。

一番要らない儀式。
朝会を必要だと思う、あるいは現在実施しているという職場の主張は以下に当てはまる。

  1. スピーチをしてメンバのコミュニケーションを図る
  2. 朝会でメンバの予定を把握する
  3. 諸連絡のために必要

大体こんなかな。 今回ディスる朝会とは、基本的に毎朝に近い頻度で行われていて、職場のメンバほぼ全員が参加しているものとする。

1. スピーチをしてメンバのコミュニケーションを図る

一番アホみたいな理由だから一番最初に書いた。
基本的に朝会が朝のスピーチなるものを行う場合、それは組織における文化的なものであることが多い。
昔、職場の誰かが「朝のスピーチしよう」と言い出して、それがずるずると継続されているという感じ。このスピーチの形態も様々で、課長とか部長に該当する人が毎朝やるとか、メンバ全員に対して一日ごとにスピーチの当番とか係的な役割が順番で回ってくるとか。
こうしたスピーチが始まる理由というのは、だいたい二通りで「言い出した人が話好き」か「コミュニケーション能力を上げる為」とかだ。いずれもメンバ間でのコミュニケーションを図るという目的を持って(あるいは後付けされて)いる。

私が思うにスピーチは能力であると思う。
それが天性によるものか訓練によるものかはさておき、人の気を引くスピーチができるのは評価される能力だ。
できれば身につけたい能力であり、発揮できるのであれば是非発揮させて仕事に活かしたいものだが、毎朝メンバに対してやるべきことではない
いかにうまいスピーチであったとしても、基本的にそれは話す側と聴く側が発生する「作業(仕事)をしていない時間」であり、 貴重な労働時間を削ってまでやることではない。
たまに、「客先とのスムーズな会話能力をつける」とか「今の若者はコミュニケーション能力が低いから」とかそんなようなアホみたいな妄想をして、「毎朝スピーチすればコミュニケーション(会話)能力が高まるだろう。これはそういう訓練だ」という理由付けがされていることもある。
だがそれはせいぜい自己啓発の範囲だ。たかだか個人の能力訓練にメンバ全員の労働時間を削って投入して浪費するべきではないし、そんな訓練が必要なほど残念なコミュニケーション能力の人間は個別に指導を入れるべきである。強調するようだが、毎朝メンバの労働時間を削ってまでやることではない。
だが、こうした訓練的な意味合いを持つ(あるいは持たせて)スピーチを行っている場合、「そんなことを言うが、実際に朝のスピーチはそうした役に立った」だの言う人も居る。しかし、それはあなたが向上心の高い素晴らしい人であるが故で、大体の人はそんなに向上心が高くない。本業と多少離れた物事となれば、大抵の人間はその物事に対して身の入り方はさらに悪くなるものである。

こうしてスピーチを訓練扱いして、最もらしい理由をつけて(あるいは理由をつけた気になって)続けていても結局は形骸化するのがオチだ。
そもそもコミュニケーション能力は明確に数値化して表せる能力ではないし、組織の中でそれをスキルとして承認するような仕組みなんて大抵存在しないし、コミュニケーションの良し悪しはそもそも人によって感じ方が違う。
そんな中、毎朝行われるメンバのスピーチに対して、聴いている側がスピーチしたメンバに適切なフィードバックを行ってメンバの高い低いすらの基準もあやふやなコミュニケーション能力の向上とやらに熱心に助力を捧げるかというと答えはノーだ。スピーチに対してそれを聴く側が何かフィードバックを与えられるかと言えば、せいぜい、「もっとこう話したほうが良いよ」「もっと大きな声で」なんて簡単なアドバイスを言うことができるかどうかが関の山ってところで、毎朝続けばそれすら継続できるかどうかすらあやしい。逆にもっと深いアドバイスを行う必要があるのであれば、その時点でやはり個別に会話指導や言語指導をすべきだ。

こうした訓練と称した毎朝のスピーチがどうなるかオチを当ててみよう。
結局は「ただやるだけ」になる
スピーチをするという行為だけが残り、コミュニケーション能力がどうこうという考えは無くなるし、メンバ全員の時間を食う割りに得られるものは何もないかあまりにも少ない。
スピーチという行為だけが残るので、メンバはネタ切れにならないように毎朝ネタを探す。それはコミュニケーション能力を向上させるためでなく、スピーチをするためになり、いつの間にか「コミュニケーション能力を向上させる」ための手段であるスピーチが目的そのものに成り代わる。意味がねえんだよバーカ。

2. 朝会でメンバの予定を把握する

朝会でメンバが各自の予定を報告していて、それを重要視している場合について。 建設現場や一日かけて大きな作業を複数人のメンバで遂行するといった場合は、一日の全体の流れを把握する"打ち合せ"としてメンバの作業内容を予定として把握する必要があるかもしれないけど、それ以外は基本的に毎朝必要なことではない。

この予定把握を朝会で求めている組織は以下のような問題を抱えている場合がある。

  • タスクやスケジュールを公開/共有できる良いツール(グループウェアとか)がない
  • ツールはあるのだけど利用が定着していない
  • 組織として人員への役割、タスクの割り当てが下手
  • クライアントからの問い合わせがほぼ電話応対ベースである

グループウェアが導入されていない職場という時点で現代らしからぬ感じがするけど、それならばそれなりにホワイトボードを見える位置にはっつけてメンバが予定を書いておくとかでも良い。
どうせ一日の各メンバの予定なんてその都度変わる。急な来客とかトラブルの発生とかもろもろの理由で変わるので、何時でも共有できるリアルタイムな予定表をデジタルであれアナログであれ共有すべき。
そういったツールがあるのに定着していないのであれば、メンバの意識が低いか、そのツールがクソ(起動するまでに時間がかかるとか)である可能性が高い。
口頭ベースでの連絡に頼り、グループウェアなりホワイトボードの予定表を使わない組織は、「その場で伝えるべき人員が欠けていた場合はどうするのか?」「予定を伝えた相手が忘れてしまった場合は?」といったとにかく情報がきちん残るだけで解消できるこれらの問題を理解していないか軽微にとらえている

また、こうした朝会で各人の一日の在席や不在を把握する必要がある組織というのは、分業がうまくできていない可能性がある。
例えば「○○さんじゃないとこの件はわからない」とか「○○さんじゃないとできない」とか。悪い意味でメンバに技術的、知識的な偏りがあり、一定の能力が突出している特定の人員にけっこうまずいレベルで負荷がかかっているという別の問題を抱えている可能性がある。
特定の人員の在席情報を強く把握したがる組織というのはこういう傾向がある。特定の人員に依存しているため、在席/不在の状況を他のメンバが気にしているというところだ。
これはそもそも改善しなければいけない問題だ。

そして、クライアントからの問い合わせが電話ベースであるというのもこの予定把握に関係することがある。
よくあるのはその職場の下っ端に該当する新人ちゃんとか、いわゆる若手に該当するメンバが外線の代表電話をまかされていて、電話で問い合わせしてくる客が求める担当の人へ取り次ぐ。この際、担当者が不在であるかどうかによって電話での応対内容が変わるので、メンバの予定は把握しておきたいというものだ。要するに電話番の為にあるということ。
話が前後するが、基本的にはこれもグループウェアのスケジュール管理/共有機能により、解決することができる。この機能の呼び出しが遅かったり、見づらかったりするようなクソでないことを祈る。

贅沢を言えば、クライアントからの問い合わせは電話ベースではなく、担当者全員に送信されるグループアドレスを窓口としたメールベースであるべきだ。
「仕方なく電話問い合わせを行っている」というのも十分承知できるが、果たして電話の問い合わせによって証跡が残るか、不在の担当者をめぐる解決までの遅延が発生していないか、受話器を持つ手と会話に意識を奪われて集中力を乱されていないか、それらは決して軽微ではないコストがかかっている。

3. 諸連絡のために必要

前述した理由の中で比較的これはマシなほうかもしれない。
例えば、「☓☓部でウイルス付きの不審なメールを受信したと報告がありました。わかっているとは思いますが、不審なメールはくれぐれも開封しないように」「本日、警報装置のメンテナンスがあります。メンテナンス業者の来訪があるので留意してください」などなど。
これくらいは別にいいかもしれない。本当のことを言えば、グループウェアにある掲示板機能やメンバに対する社内メールの送信によってお知らせするのが一番良いが、上述した諸連絡は注意喚起に該当する報告である場合が多く、それらを意識付けするためには改めて口頭で伝えることに効果がある。
ちなみに、こう説明すると「先ほどの『メンバの予定把握』も諸連絡に含まれるのではないか」と言う人が居るのだけど、「要らない理由についてはさっき十分説明したでしょ」と言いたい。

だが、まあ毎日そうした諸連絡が必要なわけないので、結局必要なのはその都度における諸連絡であり、毎朝の朝会ではない。

ざっとここまで私が思う朝会が不要である理由を述べた。
平たく言うとダルいんだよね、アレ。あと、こうした朝会ですら致命的に物事を報告するのが下手糞な人間が居て朝一番からイライラすることがある。それにオチの行方不明なスピーチをされた時はイライラが倍増だ。
私の職場には未だに朝会なるものが残念ながら存在するが、スピーチは抹消された。このまま朝会も抹消されますように。

VisualBasicをメインで使うチームの地雷感

地雷度、高いと思う。
こういった話題を挙げると、何かとVB6なのかVB.NETなのか書けよとか言われるけれど、基本的には両方で、「VisualBasic」の名を持つもののことだ。

VBそのもののディスりではない

VBそのものの言語仕様だとかに関するディスりではない。 結果的にVBディスりになってしまうかもだけど。

私はVBが嫌いなんだけど、言語的に優れていないとか優れているとか言語自体を批判する気は今回ない。
今現在、「チームでVBを使っている」「仕事はVB」と言っている人だったら、基本的にはVB.NETを使っていることだと思う。前言したように私はVBが嫌いで、そんでもってC#が好き。ここで機能的に見てもそのC#と比較してそこまで致命的(能力的)な格差は無く、基本的にVBはクライアントの要求を十分こなせる言語であるとは思っている。そもそもVB.NETの力の中核は.NET Frameworkだしね。
私が思っているのは、VBを好んで、あるいは大々的に使う企業やチームの地雷度が高いなぁということ。

VBを使うチームの意識

このご時世にVBを使うチームにはある特徴がある。
その特徴とは、チームメンバの大半の向上意識が低くいこと。特にそれはトップに近づくと謙虚に出ていて、プロジェクトを引っ張るSEやメインプログラマの役回りとなる人間がより"そう"であることが多い。

そうしたプロジェクトにおけるトップに近い人間は基本的に高齢であることが多い。年齢という大雑把なくくりで人間性を判断すべきではないとは思うが、それでも言ってしまおう。だいたい彼らは新しいことを進んで学ぼうとしない。
彼らはとことん学習コストがかかるのを嫌い、非常に保守的である(これを保守的というのかな?)。
彼らにとってC#Javaを習得せず、VBと名のつく言語を使おうとするには下記のような意識がある。

  • 自分たちはVB6を学んだ。VB.NETも文法的に似ているのであれば、新たに言語を学ばずに済むだろう。
  • C#C言語系はポインタとかの考え方めんどそう。いずれにせよ同じ.NETなんだから今まで通りVB.NETを選択しておけば安牌だ。
  • VBだったら単純だし誰でも読めるし書けるだろう。社内あるいは派遣の老若男女問わずに。

てな具合。これらが正しい考えであるかどうかは別として。
3つ挙げたけど、理由としては今までの自分(あるいはチーム内)で培ってきたVBに対する知的資産や経験を極限まで怠慢に利用しようという魂胆がある。
もちろん、教育コストがかからないことを重要視するのも大切である。だが、利用するプラットフォームが異なるにしても、現代ではC#JavaPHPPythonといった豊富な言語選択肢があり、SIerという商売をしていれば大体はVB以外にも触れる機会がある。そうした中で、あえてVBを選択する時は高確率でこうした学ぶことに対する怠慢で言い訳がましい意識が伴う。

教育コスト以外の話でよくあるのが、クライアントの依頼で大昔にVB6で作ってもらったシステムを改修することになり、VBという名前繋がりでVB.NET化しようというお仕事もあるかもしれない。「文法が近いならソースを再利用できるかもしれない……」とか変なことを考える。
私が言うのであればそんな昔のものである時点で、そもそもイチから作り直した方が良いシステムだろうと思うし、VB6時代のソースコードを再利用しようという時点で生産性が悪い。けっこう違うんだよなぁコレが。
私はそういう仕事に対して「初めから作っちゃったほうがいいですよ」と言うのだが、営業とその他の勢力により「これでいいんだよ」って言われてこういう仕事をやる。すると、何だかおじいちゃんの形見の時計だとか、長年住んでいる思い出の木造住宅だとか、そういうものをなんとかして直してあげているという慈善的な気分になる。ごめん嘘。本当はそんな温かみなど無い。そうでも思わないとやってられないのだ。

VBは過去の遺産を連れてくる

こうした意識によってVBが選択される場合、基本的にその意識に引っ張られて過去の遺産が引き継がれる。もちろん良い遺産ではない。負の遺産だ。
… 具体的には下記みたいな感じ。

前述した意識の話関連から、基本的には昔のやり方も採用されやすい。
例えばハンガリアン記法は結構嫌いな部類だ。

ハンガリアン記法とは?
変数とかが何型か分かるように、変数名の頭にデータ型の識別子をつける記法。 例えば、String型の変数ならstrName、Integer型の変数ならintAgeといった具合に命名する。

ハンガリアン記法は一見、初心者から見ると「すげー変数の型が一発でわかるぜ」と関心させるような力がある。これは初心者があまりコーディングテクニックというべきものに触れたことがないからによる(まあ、ハンガリアン記法は最早テクニックでもなんでもないけど)。
が、そもそも今のIDEだったらマウスカーソルを合わせれば何の型なのかわかるもんだし、周辺の処理内容を眺めれば利用している変数の型の推測なんてすぐにつく。
また、処理内で使う変数なんてデータ加工や合計値、識別子となるパラメタを放り込んでおくバッファみたいなもんで、処理間をやりとりするデータなんてクラスのメンバとして定義されているもんである。
それに加え実際にはハンガリアン記法は変数名を長くするだけでなく、もっと有害な場合もある。
例えばintValueと言いつつホントはLong型なんてものもある。これは途中でIntegerからLongに宣言部を変えたんだけど、変数名を修正していないとかそういうアホな原因から生まれたお肌に優しい天然由来のトラップだ。型をわかりやすくするためのハンガリアン記法がフェイクとして出現するとか本末転倒だな。

あと、VBにはコメントが多い。すげー多い。
ソースコードの内容をいちいちコメントで説明するのが大好きな人が多い。

'未成年の場合 
If intAge < 20 Then 
    'メッセージを表示 
    Msg.Show("お酒はダメよ") 
End If 

こんな感じのレベルのコメントがマジで多い。そんなもんソース見りゃ分かるわ、的な。
これは単純にVBを求める層が技術的に低い水準であることに起因する。前述したVBだったら誰でも読めるし書けるだろう」といった考えから発生する。VBを選択した時点で「どんなエンジニア未満のエンジニアでも大丈夫」といった思想があり、この鬼のように優しいコメントはそうした思想を実現するものである。
もちろんコメントを一切残さないのも問題だが、なんでもかんでもコメントで解説するのはそれだけ自分がソースを理解するのに時間がかかっているということになる。つまりはプログラマとしての能力が無いと言っているようなもの。前述のハンガリアン記法にもこれは当てはまり、ソースの前後から型を自然と推測できない、つまりは便利なIDEがあるにもかかわらずそれに加えてもソースを読む力が弱いからハンガリアン記法を好むのだ。

また、コメントといえば修正したロジック部分をまるごとコメントアウトして残すという文化やルールもある。

'↓2014/04/01 修正ここから F.Yonezawa Start --------- 
' 消費税改訂により、下記処理をコメントアウト。 
'Dim decTax As Decimal = 1.05D
' 
'decTotal = decPrice * decTax 
'↑2014/04/01 修正ここまで F.Yonezawa End    --------- 

'↓2014/04/01 追加ここから F.Yonezawa Start --------- 
' 消費税改訂により、下記処理を追加。 
' 固定で取得していた消費税を共通関数で取得するように修正。
decTotal = decPrice * GetTax()  
'↑2014/04/01 追加ここまで F.Yonezawa End    --------- 

例えで書いたソースコードもいい感じに馬鹿っぽさが出てて良いと思う。なんで消費税ハードコーディングで計算してんだよとかね。
少し話が脱線したが、例えとしてこんなような履歴管理がソースコード上で普通に行われている。
こうしないと上の人間が怒る。そりゃもう怒る。
証跡や過去の履歴を残すという大切さはわかる。だが、GitやSubversionといったバージョン管理ツールがあるこのご時世にソースコード上でこんなことをやる意味(必要)はないし、ソースコードの可読性を損なうだけだ。
結果として、VBソースコードはVisualStudio上から見た時に緑色が占める割合が高い。VB自体は冗長になりやすい文法なので、それと相まってソースコードがクソ長くなる。それでアホみたいにスクロールして読まなければいけない。地獄かな?

なんかもう書く気力が薄れてきた。まあ続けよう。
ここまで述べた通り、ソースコードに対する読解力やツールの応用力が低い。総じて能力が低いのでオブジェクト指向をうまく活用しようとしない。というかできない。
例えばクラスやインターフェースはメンバやメソッドの存在を定義付ける為のただのルールだとしか思っておらず(あるいはそういう使い方しかできない)、いらんところまで実装や継承を促して、がんじがらめにしたりする。ソース見るとクラスに対して同じ数のインターフェースが居たりして(そのインターフェースはその対になる一つのクラスにしか実装されない)、「何考えてんのコイツ……???」って感じになる。これはインターフェースをおまじないのようにしか考えていないから発生する。
他にデプロイを自動化しようという考えや、テストを効率化しようとかも考えない。当然のごとく考えない。そもそもそういう考えがわかない。ただ時間がかかるタスクとしてどーんと工数が割かれ、Excel方眼で作られたスケジュールシートに長い長い棒線が引かれるだけである。

よって地雷

よってVBを好んでよく使うチームは地雷が多い。
向上心や技術力が低い集団である可能性が高いと言える。

私は尊敬できるVB使いという人間に今までで一人だけ出会ったことがある。派遣のNさんだ。
派遣のNさんがVBが好きだった理由は、学生の頃からBASICに慣れ親しんでいてBASIC系そのものの文法が好きだということからで、.NETの技術についても熟知していたし、C#も使いこなしていた。つまり、アホみたいな言い訳の為にVBを選択しているわけではない人間だった。よく技術書やMSのブログも読んでいたぁ。
現実で出会った尊敬すべきVB使いはNさんだけだが、ネット上にもNさんに似た人は沢山居る。

VBは嫌い……いや、大嫌いだ。
まあ、大嫌いであれど正当で然るべき採用理由があるのであれば、ある程度の個人の好き嫌いは仕事として割り切り目をつむるが、VBを採用する組織的背景というものは基本的にどうしようもない

ここまでのレベルでどっぷり怠慢してきたSIerは良い仕事ができない。
ああ、これは仕事意識とか成果物のクオリティが低いという意味の戒めだけではなく、実際の受注において良い条件の仕事の話が来ないということだ。
できるのは自身たちの能力不足による生産性の悪い作業ばかりなのに対し、曲がりなりにもこのSIerの根底にあるのは効率化と生産性を求めるシステム開発であるという根本的なズレが発生する。
言わば「便利なシステムを開発しよう」という人間自体が、便利で効率的な仕事をできていないし追求していない。「切れりゃなんでもいいでしょ」って言いながら、ナマクラ包丁を作り続ける鍛冶屋さんみたいなもんだ。
そんな集まりの組織ができる仕事なんてたかがしれていて、今以上の存在にはそう安々となれない。であれば、そうした最低の位置をこれからも墜落寸前低空飛行し続けるか、気がつけば他に仕事を奪われて撃墜されているかのどちらかしかない。
ソースコードの質は悪く、ツールも使わず、結果的にアホみたいに時間と人をかけて作業をするので、営業もそれをある種わかっていて買い叩かれたようなアホな案件をとってくる。

ただの開発言語であるVBひとつから話を掘り下げすぎただろうか。
いや、決して言い過ぎではない。これは日本SIer界という魔界でわりとマジで言えることだと思う。
ある程度プログラマとして仕事をし、色々な企業の人と出会ったが、VBをメインとする環境は常にこんなんだった。
ちなみにC#の開発プロジェクトでも「なんか変だな」と思ったら、やっぱりSEとPMがVBしか組んだことが無い人間で、笑顔で「VBしか組めないよーC#とかJavaとかって難しいよね」とか笑顔で言ってた。

メインがVBとか言っているような組織は注意した方が良いだろう。
例えあなたがVBに対してBASICの頃から抱き続けた愛着があったとしても、他人がそれを分かち合い、より高度なことを実現できる仲間が居るとは思わないほうが良い。
彼らは地雷だ

テキストエディタをMeryに

WindowsのエディタをMeryに変更した。 MeryいいよMery

Mery

いくつかもろもろの理由があってWinで使っているテキストエディタサクラエディタからMeryに変更した。

「Mery」プラグインやマクロに対応するフリーの高機能テキストエディター - 窓の杜ライブラリ

f:id:PaperFace:20170515230211p:plain

※Win10と高DPIの液晶のためボタンサイズがおかしい。私は気にしていない。どうせショートカットキーで操作するし。

メジャーな言語のハイライトはもちろん、プラグインやマクロもある。レジストリを汚さないし、諸々の機能を満たしている。

SE(私)が必要とする機能

SEとかプログラマが使うテキストエディタに欲しい機能を含め、Meryでは以下ができる。

  • ソースコードのハイライト
  • 行番号表示
  • 正規表現による検索and置き換え
  • アウトライン解析
  • テキスト本文と特定ディレクトリ下ファイルへのgrep
  • タブによる複数テキストファイル編集
  • 編集中ファイルを引数としてコマンドの実行
  • カーソルが当たっている文字のキャラクタコードがわかる
  • カーソルの座標がわかる(何行目, 何文字目か)
  • キーワード補完ができる
  • 画面分割
  • 印刷時に行番号とページフッター/ヘッダーにページ番号出力
  • ブロック選択

どれも重要な機能。
たまにテキストエディタ論争で「メモ帳が最強」とか言ってるやつは流石にネタだとしか思えない。

Meryに行った設定

ショートカットの設定

いくつかのショートカットを追加。

ショートカットキー 割り当てた動作
Ctrl + w タブ閉じ
Ctrl + Shift + s 名前をつけて保存

Ctrl + wによるタブ閉じは、Excelとか各種Webブラウザでもよくある動作なので外せない。
Ctrl + Shift + sも、既存のテキストファイルを別名として保存する際にもショートカットで欲しい。

後述の外部ツールにもショートカットは割り当てるけど、ひとまず標準の動作に対してはざっとこんなところだろうか。

外部ツールの登録

現在編集しているファイルが格納されているフォルダをエクスプローラで開くように外部ツールを設定。
なお、フォルダが開かれた時に対象のファイルが選択(フォーカス)された状態で開く。

f:id:PaperFace:20170515234223p:plain

項目 設定値
タイトル フォルダを開く
コマンド %WinDir%\explorer.exe
引数 /select,“$(Path)”
作業フォルダ $(Dir)

表示

標準テーマ「iPlastic」をカスタムしている。
白地だとコントラストが高すぎて長時間見ていると目に悪いので、目に優しいように背景色をグレーにしてコントラストを落としている。 フォーカスしている行を見失わないように、フォーカス行はやや濃いグレーを背景色に設定した。

f:id:PaperFace:20170515235212p:plain

フォントとしてIPAゴシックを使っている。
コーディングに適したフォントはいくつかあるが、個人的には1(数字のイチ)や|(パイプ記号)、l(小文字のエル)、0(数字のゼロ)やO(大文字のオー)が見分けられるものであれば良いかな。

構文追加(Markdown対応)

個人的によくMarkdownを書くので、下記の公式wikiを参考に構文ファイルを追加している。

構文ファイル - MeryWiki

個人的にMarkdownファイルの拡張子は*.mdとしているので、拡張子の紐付けも別途設定する。 構文ファイル - MeryWiki

また、Markdown編集時は#が見出しとなるので、アウトライン解析できるように下記のとおり設定している(末尾が#というように半角スペースを1つ入れる)。

f:id:PaperFace:20170516000409p:plain

これでMarkdownに関連するキーワードが色分けされ、なおかつアウトライン解析された際に見出しがツリー表示されるようになる。

f:id:PaperFace:20170516003319p:plain

Markdownのプレビュー画面こそないが、軽量のエディタでガリガリ書くにはこの程度の色分けとアウトライン解析があれば十分。
必要であれば外部ツールとしてPandocを呼び出すコマンドを加えてもいいかもしれないね。

余談

以下余談。

前はサクラエディタを使っていたんだ

Mery以前はサクラエディタを使っていた。
上述した機能はサクラエディタでも使えるのだけど、サクラエディタにはちょっと個人的に悩まされている仕様があった。
私はWinキー + 矢印キーで画面半分をエディタにして、もう半分を別のアプリケーションとすることが多い。この時、別のタブに切り替えたり新たなファイルを開くとウインドウサイズが元に戻ってしまう。
タブを切り替えるたびにこの現象は発生してしまうので、複数のテキストファイルを操作する私としてはこの仕様の改善を期待していたのだけど、どうもWinのこの動作と相性が悪いらしく、解決が難しいようなので絶望的だった。そんな時にMeryと出会った。

Atomとかよりも

最近のはやりのエディタと言えばAtomとかだろうか。
前述した構文ファイルの追加やらアウトラインの解析やらの設定でMarkdownを対象とした設定を行ってはいるが、ガッツリとMarkdownを書くならそうしたエディタを使ったほうが良いと思う。
プレビューとかついてるしね。

テキストエディタというよりも

私の場合、テキストファイルをひたすら書くというよりも、正規表現による文字列加工マシーン、grepによる検索ツールとして使う側面が強い。
CSVファイルもExcelではなく、だいたいこういったテキストエディタで眺めているし。

Meryはそういった意味ではお道具箱みたいなもんで、作業中は私のデスクトップ中でほぼ起動している。

SEやプログラマならこれくらい使って当然だよね。おすすめ。