  |
はてなキーワード: 拡張機能とは
2つのGoogleアカウント（会社用のG Suiteアカウントと個人のGoogleアカウントなど）を利用しているMacユーザーにお勧めです。
Windowsだとアカウント別のショートカットを作れば、任意のアカウントでログインしたChromeを起動できますが、
Macの場合はアプリを終了した時点でアクティブだったアカウントで次回起動してしまいます。
個人アカウントのメールをチェックしたいのに、起動すると別のアカウントだった場合、
そのたびにユーザーを切り替えて起動しなければいけないのがストレスでした。
個人アカウントはFirefoxやSafariで…とも思いますが、対応している拡張機能が無かったりといろいろ不都合があります。
でもEdgeなら（ブラウザで使うのはMicrosoftアカウントですが）中身は実質Chromeですから、ほぼ同じ環境を実現できます。
しかも使ってみるとあれこれ使いやすい…特にコレクション機能が便利。
Microsoftアカウントを使えばデバイス間で同期も取れるので、スマホや他のPCともお気に入りやコレクションを共有できます。
「アカウントを作成して一番初めにすることは坊主とイエス・キリストbotのブロック」などとツイッターオタクたちは冗談を飛ばしあっているが、やはり快適なツイッターライフを送る上でブロックは必要不可欠だ。そして問題はいかにブロックを効率化するかだ。私はそのために以前「クソリプバスター（同じ穴の狢）」というアプリを利用していた。
これはツイッターのブロックリストという機能を活用して、主に特定のアカウントのフォロワーをまとめてブロックしてくれるアプリだ。しかしブロックリストが昨年行われたUIの変更と同時に廃止されてしまったので、それから使えなくなってしまった。
そこで私は、拡張機能「Twitter Block Chain」を利用し始めた。
最近BuzzFeedの古田氏やジャーナリストの津田氏に紹介されて脚光を浴びてもいるが、これはスクリプト（？）を走らせて特定のアカウントのフォロワー（／フォロイー）をまとめてブロックしてくれる拡張機能だ。しかし欠陥があった。一度の処理でブロックできるアカウントの数に限界があり（およそ500アカウント）、それを超えるとエラーを吐いて自分のアカウントが強制ログアウトさせられるのだ。それでもしばらくはこの欠陥に目をつぶって利用していたが、やがてもっと優れた拡張機能に出会った。それが「Red Block」だ。
特定のアカウントのフォロワー（／フォロイー）をまとめてブロックするための拡張機能として、「Red Block」が「Twitter Block Chain」の上位互換たる理由は2つある。まずは、数万に上るアカウントのブロックを一度の処理で完了することができるというものだ。「保守速報」のフォロワーで試してみよう。
結果→https://i.imgur.com/7Ik4c9P.jpg
一度の処理によってフォロワーだった95,000ものアカウントのほぼ全てをブロックすることができた。（「ほぼ」と書いたのは、ブロックするアカウントが多すぎたときに一部をブロックしそこなってしまう問題があるからだ。しかし今回それは「Twitter Block Chain」で確認したところ70アカウントほどだったから、あまり大したことではないと思う）。要した時間は5分弱だった。また強制ログアウトさせられることもなかった。
次に、目当てのアカウントに自分がブロックされていてもそのフォロワー（／フォロイー）をブロックできるというものだ。
以上のことを考慮すると、ブロック効率化のツールとしては「Red Block」が現時点で最も有用だといえるのではないだろうか。ガシガシブロックして快適なツイッターライフを。
註
※Firefox向けの「Red Block」もある。→https://addons.mozilla.org/en-US/firefox/addon/red-block/
頼むからセンスのない奴はプログラマにならないでくれ。迷惑だから。
これが最もプログラマになってはいけないタイプ（犯罪行為などの言うまでもないことを除けば）。
たとえば
等。
不要なものを作ることで、プログラムは複雑になり、メンテナンスの手間は増え、バグは発生しやすくなる。
一定レベル以上のプログラマが最も自然だと同意するような実装（「実装しない」という選択肢もふくめて）をパッと思い付けない奴は、センスが足りていない。
将棋で言えば、駒がぶつかったら先ず取る手を考えるといった基本的な手筋が思い浮かばないようなもので、現実的に使い物にならない。
これは、「Code Complete」「The Pragmatic Programmer」等の著名なプログラミングの本に共通する結論である。
これが「The Pragmatic Programmer」にあるDRYの原則である。
要するに、すべての情報が単一のソースから決定されるべきということだ。情報が二重化すると、それらの間で不整合が生じバグの原因になる。また、二重化した情報は、修正の手間が二倍になる。
たとえば、ユーザーのプロフィールを管理するレコードやクラスに「生年月日」と「年齢」を同時に保持する必要はない。年齢は生年月日から計算できるからだ。
世の中には、「xxxFlag」みたいな不要な変数を作ったり、共通のロジックを抽出せずにコピペコードを濫造するダメプログラマーが多すぎる。
もちろん、合理的な理由があって、この原則が適用されない場合もある。
たとえば、多くの言語組み込みの配列や文字列は、その要素と長さを二重に管理している。配列の長さは要素を数え上げることで求まるが、それには要素数に比例した計算時間がかかるためだ。
ただし、こういう場合でも、公開されたメソッドによる操作では、必ず内部の変数は同期されるように作ることが可能である。それをしないのは、怠慢でしかない。
一文字変数とか連番とかは論外だが、「ary」とか「setData()」みたいな何の情報も伝えないような変数名・関数名を付けるやつ。
正直、コードの読みやすさなんて6〜7割くらいは変数名の付け方で決まると思っている。
名著「The Art of Readable Code」も、半分以上が変数名の付け方に関連する内容だ。
なぜ変数名が曖昧になるのかと言えば、怠慢を除けば理由は2つある。
1つは、コードを書いた奴自身が、そのコードの機能を明確に言語化できないということ。
もう1つは、1つの関数で多くのことをやりすぎたりしていて、その変数の役割が曖昧になっているということ。
たとえば、関数の内部で宣言した変数は、多くの言語では関数の外からは参照できない。
スコープは狭い方が良い。これはほとんど全ての状況に適用できるプログラミングの大原則だ。
スコープが広いということは、ソースコードの多くの場所からその情報を参照・変更できることを意味する。
たとえば、クラスのメンバ変数は各々のインスタンス内でしか参照できないが、静的な変数はすべてのインスタンスが共通に持つ。このため、静的な変数を変更すると、すべてのインスタンスに影響を及ぼし、影響範囲の把握やテストが困難になる。
スコープを広げるか狭めるか、2つの選択肢があったとして、広げる方に心が傾く奴は、プログラマをやめた方がいい。
結果的にメンテナンス困難なコードを生むというのも勿論だが、単に書くだけでも、スコープが広い方が書きづらいのだ。つまり、必要もないのにわざわざ変数のスコープを広げようとする奴は頭のおかしい奴しかいないということになる。
複雑なメトリクスなどを持ち出すまでもなく、たとえば1メソッドの行数が何百行もあるとか、1クラスのメンバ変数が何十個もあるとか言うの。
これは論外である。プログラマとしての能力云々以前に、明らかな怠慢であり、社会人としての常識が疑われる。
定期的にメンテナンスされ続けているOSSのソースコードなどを見ると、関数（メソッド）の行数は平均して5〜10行。20行を超えるものは稀である。
長いものであっても、外部で定義した関数を順番に呼び出しているだけであったり、リクエストをハンドリングして各々の処理に振り分けているだけのようなものがほとんどである。
それを超えているコードは、合理的な理由があってそうなっていることよりは、単に悪い設計であることの方が多い。
これらは実はプログラミング云々というより、内容の理解力や国語力の問題なのである。
ある情報を得るために必要十分な情報は何かが分かってないから、余計な変数を作ったり、無駄に変数のスコープを広げたりする。
そして、自分が作るものを正確に理解していないから、適切な名前がつけられないし、適切なモジュール分割ができない。
それがすべての原因。
こういう人がまず身につけるべきは、プログラミングのテクニックではなく、日本語を正しく読む力。
低学歴が「プログラミングなら自分でもできるかも」なんて思っちゃいけないってこと。もちろん、下請けのSIerとかで使い捨てのコード書きとして働くことはできるが、上に書いたような最低限の力がないなら、それ以上を望んではいけない。
ちなみに、上に書いていることと反対のことを思っている人も世の中にはいる。
特に、昔からプログラミングをしてきた自称ベテランに多い。その人は、能力があるというよりも、単に現代の開発に際して必要な知識がないだけなので、真に受けないように。
また、大学でコンピュータサイエンスの基礎を学びたての学生なども、知識をひけらかしたくて上と反対のことを言う傾向がある。その程度のことは、良識のあるプログラマはみんな分かっているのだが。
Chrome+Google日本語入力でそんな酷い変換ラグが発生するのは考えにくい。おま環のトラブルもしくはバグだろう。OS等の環境は？
光回線は関係ない。辞書データはメモリに展開されているから変換候補を出すのに通信などしていない。その変換が重いのは常時なのか、たまになのか、特定のページでなのか、重い時のCPUやディスクI/Oはどうなっているのか、リソースが逼迫しているせいで重くなっているならどのプロセスが重くしているのか(IMEとは限らない)、リソースが問題ないならレンダリングの問題はないか、特殊なレンダリングソフトを入れてたりブラウザ側のレンダリング系の実験機能を弄ってないか、……いやこのへんはなんとなく当たらない気がする。
俺が昔にGoogle日本語入力でトラブルに遭遇したときは、だいたいIMEをアンインストールして再インストールしたら直った。OSのグレードアップ時やメジャーバージョンアップ時に不具合がでるようになった記憶がある(ここ数年はクリーンインストールすることが多かったので遭遇してないが)。
あとは64bitOSなら64bit版を入れているかどうか(最近は自動で正しい方が選択されるはず)、ChromeもIMEも最新バージョンになっているか。
他にはChromeに入れている妙な拡張機能が悪さをしていないか。拡張機能を無効で起動するには--disable-extensionsオプションが潰されて無ければ使えると思うが、beta版など普段使いと違う開発チャンネルのChromeを新規で入れて試してみてもいい。
