whileの条件に !feof は注意

とある国産オープンソースで見つけました。

while (!feof($fp)) {...}

この処理の前に、$fpが正常かのチェックがされていません。
これではファイルオープン失敗時に無限ループしてしまいます。　怖いですね。
ファイルオープン失敗なんて、バグでよくあること。

ファイルオープンに失敗していると、$fp に false が入っています。
feof(false)は、 false になります。
したがって、無限ループします。

正しいやりかたは、

エラー時に何かしたいことがあれば、
if ($fp !== false)  { while(!feof($fp)) {....}}else {...}

単純にスキップしていいなら

while ($fp && !feof($fp)) {...}
 でもいいね。　※毎回$fpの判定という無駄があるけど、どうでもいいでしょう。

パスに日本語が含まれる場合の $_SERVER問題

パスに日本語(エンコードされたリンクURLではなく、デコード後文字列）が含まれる場合、$_SERVER の中身に問題が発生します。

REQUEST_URIはエンコードされたままの文字列が入るので、問題ありません。
しかし、その他はデコード後のURLが入ります。
SCRIPT_NAME, PHP_SELF, PATH_INFO です。
特に SCRIPT_NAME はよく使う物なので、非常にやっかいです。

簡単に対応させる方法は２つ

その１：explode('/', $_SERVER['SCRIPT_NAME']) で分解し、ループでエンコードして再度結合させる。
その２：REQUEST_URIの?以降を削除して使う。

その２が簡単で良いと思います。
REQUEST_URIはブラウザから送られてきた値なので、扱いには注意してくださいね。


ちゃんとエンコードしないと、用法と文字の組み合わせ次第でエラーになるので気を付けましょう。

Amazon Echo到着！

「お使いの端末はこのバージョンに対応していません。」

所持しているスマホが対応しているか、事前に確認しておきましょう。
対応していない場合、wifi接続可能なＰＣが必要になります。

wifiを使うため、環境によっては不安定です。
マンションやアパートの人はセットアップが大変かもしれません。

セットアップするために、echoとwifi接続するのですが、一覧になかなかechoが出てこない場合があります。
win10の場合、画面右下のwifiアイコンをクリックして一覧を出すを繰り返すと出てきます。
出て来てもすぐ消える場合があるので、すぐクリックして接続します。
※wifiはパスワード無しのオープンでした。

接続が成功しても、セットアップが終わるまで接続が維持できなければなりません。
時間がかかるか何かあると、セットアッププログラムのセッションが切れ、amazonへのログインからやり直しになります。
※ログアウトしてログインする必要があります。

ということで、セットアップは一発とはいきませんでしたが、完了しました！
セットアップ後はechoにwifiで繋げなくてもアプリ側からの操作が可能です。


音声認識の精度は、想像を絶するほど良好です。
おそらく、私の声との相性が良いのでしょう。
２・３メートル離れた位置に置いてあるのですが、ささやいて操作でき、驚きました。
小さい声や早口がしっかり認識するので、思いのほか楽に操作できるという印象です。
しゃべり方はまったく気にする必要がなく、普通にしゃべるだけです。
ボイスコマンドを覚える必要もなく、思いつきで問題ありません。様々な言い方に対応していました。さすがAIですね。
ただ、なまりがひどいとどうなのかわかりません。

セットアップ完了に、真っ先に設定をするべき項目があります。
「音声ショッピング」です。
間違って購入しないよう、ＯＦＦにするかパスワードを設定するべきです。
過去に、ＴＶ司会者の発言で国中のechoが勝手に注文という事件がありました。


ちなみに購入したのは、Amazon Echo(チャコール)です。
写真だと青色っぽいのがあって、黒なのか青なのか不安でしたが、黒でした。
※チャコールは炭色であり、黒に近い灰色って感じです。

音質は、大きなスピーカーには当然かないません。
小さいわりには、かなり良い音質だと思います。私には十分です。

あとは、対応家電なんかが増えて行くと楽かも。ぐーだらばんざーい

cssのidとclass 使い分け方

cssのidとclassの使い分けを気分で適当にやってる人も多いはず。
これ、適当にやると後でかなり面倒な事になるんですよね。
idで指定されてる物をclassに変更する作業とか、面倒です。
最悪なのは、idが重複して使われていたり。
長期保守が必要な場合は、しっかり分けることが必要不可欠です。

原則、id属性は使わない。
使わないにこしたことはありません。

絶対にやってはいけないパターンで、よくやらかす人が多いパターンは、
「一カ所しかつかわないから」idで指定。
これやめてください。 classで指定してください。
結局後で複数個所利用になります。

idを使うのは、「一カ所しか使わないから」ではなく、「一カ所しか使えないから」という時に限定されます。

すなわち、デザインでidを使う必要は無いということです。
idはJavaScript用と覚えておこう。


おまけで、classの命名のしかた。
デザインの内容をclass名にしないでください。
デザインを変更するときに、非常に面倒です。

たとえば、class="title-red" とか。 ※赤色というデザイン内容を指している
これ青に変更したいとき、全ページを title-blue　に変更ですか？　最悪ですよね。

ほうれんそうは無意味

言葉の意味は常に移り変わっていきます。
意味が変化するパターンは２つ
・言葉の意味がわかりにくく、勘違いして使う。
・力のある人が都合の良い解釈を行って意味を変化させていく。
ほうれんそうは、両方がまざってる気がします。

・流行りだした当初の本来の意味
社員間のコミュニケーションを重要視し、風通しの良い環境づくりの方法論。

・知れ渡った現在の意味
上司への自発的な報告・連絡・相談を徹底させ、全ての情報が上司へ自動的にあつまるようにする。
※手段が目的になっている。

意味が完全にかわってしまったため、ほうれんそう否定派が続出してしまったというのが現実です。
大手でもインタビューでほうれんそうを廃止したと言うほどです。※社内ルールで不要と明記。


私が実践するほうれんそうは少し違います。
内容は「ログを残す」です。
上司へ知らせるのが目的ではありません。いつでも情報へ参照できるようにするのが目的です。
ログは全て開発用チケットシステム(JIRA)の各チケットのコメント欄に記述していきます。
何かあった時に、過程が細かく書かれているログがあると非常に助かります。
なぜこういう仕様になったのかとか、やりとりの内容とか、後で重要になりやすいです。
また、ログに不審点があれば、他の人から突っ込みがきます。
ほうれんそうが自動的に達成できる仕組みというわけです。

私の意見としては、部下から上司へのほうれんそうよりも、上司から部下へのほうれんそうのが重要だとつくづく感じます。
部下とのコミュニケーションが取れていない上司は大問題です。会社のガン細胞とも言えます。

いろんな所で言われるホウレンソウまとめ

■報告
結果を報告が原則。
順調な場合の途中報告はいちいちしないことが重要。
海外ドラマでも、途中経過をいちいち報告するなと怒られるシーンがよくありますね。
歓迎する上司は、よほどの暇人なのでしょう。

■連絡
情報の社内共有です。
インフォメーションと言った方がわかりやすいですね。
これは発信者任せにするのではなく、受信者が自発的に受信するようにしないと機能しません。
部下からの連絡を待つだけの上司は駄目ってことです。

■相談
悩み、迷いを一人で抱え込ませないようにしようってことです。
部下からの相談を待つだけの上司は無能です。


全てに共通して、事実と想像(予測・推測・憶測)は明確に分けることが重要です。
ごっちゃにして想像を事実かのごとく書く人が居ます。
こういう人の想像は、10割がた間違ってるので、本当に困ります。
想像は読み手に伝染し、間違った処理をすることが多々あります。
また、どうでもいい想像の部分の検証ができずに時間がとられたりします。
想像は原則書かない。書く場合は誰が見ても想像だということを明記する。これ重要。

プログラマーの三大美徳

3大美徳は必要不可欠な要素とされています。
有名なので今更ですが、自分なりに解釈してみます。
※オリジナルの解釈とは微妙に異なります。


■怠惰
laziness：勤勉に仕事をすることを嫌う意。
これを意味するのは、効率主義です。
実現するためには、楽をするための努力をすることになります。
これほんと重要。私は高校時代に身に着けました。
勉強が大嫌いだったので、勉強の効率化を徹底していきました。
そして天才と呼ばれるよになります。

逆にこれができない人は、何も考えずに、ただひたすらにやるだけの人です。
勤勉ですが、時間を浪費するだけで、間違った方向の努力です。
頑張っけどと言って失敗に終わりやすいタイプになります。

■短期
Impatience：我慢できないこと
これを意味するのは、柔軟性です。
短期な人は、ストレスを回避しなくてはなりません。
そのために、柔軟で綺麗な設計をするようになります。
さくさく仕事をこなせる環境をつくり、こなしていきます。
仕事をしていて、かなり感じます。短期なほど色々気が付き便利な機能を作ります。
そして神と呼ばれるようになります。

逆にのんきな人は、どんなひどい動作でも、何も感じず、何もしません。
大変でも最終的に目的が達成できればそれでよしとなります。

■傲慢
Hubris：高いプライド
これを意味するのは、完璧主義です。
皆から褒められる物を作ろうと努力します。
これは特にソースコードの綺麗さに現れます。
プログラマーにとって、一番性格が出る部分がソースです。
ここが汚いと恥ずかしいと感じるのです。プライドが許しません。
結果、保守性の高いソースができるのです。
そして・・・・伝説となるかも。

逆にプライドの無い人は、うごけば良いの考えで、ひどい物を作ります。


以上ですが、本当に必須要素だと日々実感します。

ウェブデザイナーの意味

以前は、ウェブデザイナーと言えば、htmlやcssを扱うコーディング職でした。

コードが筆であり、コードでデザインを表現する職業です。

しかし今は違います。

本来のウェブデザイナーは、コーダーと呼ばれるようになりました。

そして今のウェブデザイナーは、ウェブ専門のグラフィックデザイナーを指すようになったのです。

もちろん今でもコーディングを兼任しているウェブデザイナーは沢山います。

高給取りのウェブデザイナーは、本来のウェブデザイナーでしょう。

何故このようなことになってしまったのかは、２つのパターンがあるように思えます。

１：大型プロジェクト

大型プロジェクトでは複数のウェブデザイナーが居て、役割がわかれたります。

グラフィック(UI/UX)担当と、コーディング担当といった感じです。

これにより、グラフィック専門のウェブデザイナーが増えてきたのだと思います。

２：コーディング内容の高度化について行けなくなった

htmlタグは大して変わっていないけど、cssでのグラフィック表現がメインとなりどんどん高度化、javaScriptも大量に使う時代。

これに脱落していったデザイナーが、コーディングをやめてグラフィックのみ受けるようになりました。

まぁ、複雑化により役割が分かれたということです。

auto_incrementをMAX+1で初期化したい？

ぐぐると面倒な事をしている人ばかりですが、簡単確実な方法があります。

alter table テーブル名 auto_increment=0;

値に0を指定してください。

オートインクリメントは、値が無しや0やNULLの時に、MAX+1で置き換わります。

これはインサート時だけではなく、初期化でも同じです。

技術用語。外来語や、英単語の読み方

外来語の多くはドイツ語です。
かつてドイツが世界一の技術大国だったからです。
日本はドイツから大量の技術書を輸入しました。
なので、ドイツ語が多いのです。
※英語も、ドイツ語由来が多くあります。

最近は英語化の波が押し寄せていて、大変カオスです。
ドイツ語派と英語派に別れてるため、使い分けなけらばなりません。

ベクトル：ベクター
ヌル：ナル  ※アメリカ英語はノウですけど。

一番カオスなのは、表記は英語のスペルで、読みはドイツ語というのもあります。
ドイツ語が先に広まって、英語の発語が広まっていない状態です。
有名なのは、「テーマ」。
英語スペルの theme(シーム) と書いて、テーマ(thema)と言う人が大半だと思います。
こういうのは日本語に翻訳してしゃべってると思えば良いと思います。いちいち気にしない。

英語の読みについて
英語をカタカナ表記する場合に、恥ずかしい突っ込みをする人が稀に居ます。
英語をかじった人が、それは正しくないと言い出します。
そういう人は、英語を勉強する前に、日本語を勉強してください。
英語をしゃべってるのか、日本語をしゃべっているのか、ちゃんと使い分けましょう。
日本語をしゃべっている時に、アメリカ式発音なんかどうでもいいんですよ。

warning
これ、日本人ならワーニングと読みます。
これを間違いと言う人もいますが、ワーニングで合っています。
英語をしゃべる時は、英語の発音をしてください。どうでもいいです。
何故ウォーニングではなくワーニングで広まったか？
ウォなんて書き方、昔は日本語に無かった。　ただそれだけです。
戦争のwarも、昔はウォーではなくワーと表記/発音しました。
同様に、アワード、ワープ、ワーナーなどがあります。アワードをアウォードと書く人を見た事がありません。
いずれも正確にはワ(ウァ)とウォの中間の発音でしょうか？

ping
ピングです。　英語でもピングと発音します。
なのにピンが正しいと主張する人が後を絶ちません。
まぁ、英語の早口ではピンのみでグを飲み込んじゃいますが。
英語は日本語と違って発音の変化が激しいですからね。
※ジョギングが間違いでジョギンが正しいと言う人が居ないのが不思議。

conference
カンファレンス、コンファレンス。どっちも広まったのでどっちでもいいです。
元々はコンファレンスが広く使われていて、後から英語に近いカンファレンスが広まりました。
というか日本語使おうよ。


こうやってみると、日本語狩りに近い感じがします。
定着している言葉を間違っていると否定して潰していき、使いにくくさせます。
目的と手段を間違える人が多い気がします。


話がずれますが、面倒なのは英語ブームが加速している事！
何でもかんでも英語に置き換え、ルー大柴かよ状態です。
しかも理解しないで使っていますから、会話が大変です。
カッコつけや、営業の都合(相手を騙す商法)で発生しています。
やっかいなのは、会社や人によって意味がまったく違う事！
理解しないで使っていれば、当然そうなりますよね。まるで伝言ゲームです。


■マメ知識
歌詞では、英語のスペルで書かれている場合は英語(アメリカ？)の発音、日本式の発音をする場合はカタカナで表記というルールがあります。

バージョンやリビジョンの意味

バージョン 0.43 や、バージョン 3.45.3 など、
バージョンは数字と点で表します。

他に、アルファ版は a 、ベータ版は b が付いたり、その他いろいろな物が会社によっては存在します。

初心者から多い質問の一つが、このバージョンの意味や付け方です。
なので、解説します。

まず、バージョンに書かれている点「.」は、小数点ではありません。
小数点と言う人が居るために、勘違いする人が後を絶ちません。
間違っても、小数点とは言わないようにしましょう。
英語ならドット、日本語なら点です。

すなわち、「.」の後ろの数字は、小数ではないってことです。

■初心者が勘違いしやすい例
・「1.1 と 1.10」
ドットを小数点だと勘違いしている人は、1.10って1.1の事だよね？となります。
1.10は、　「いってんじゅー」　です。 1と10です。

・1.9の次は？
1.9の次が2.0になると勘違いしている人もいますが、ドットの前後に関連性はありません。
1.9の次は1.10です。 1.99の次は1.100です。
ドットは小数点ではありません。

■それぞれの数字の意味
基本パターンは、「A.B.C」になります。
AもしくはA.Bがメジャーバージョンと呼ばれます。
BもしくはCは、マイナーバージョンと呼ばれます。
メジャーかマイナーかは、規模の違いです。
A,B,Cというバージョン番号が入れ子状態になっています。
分かりやすく書くと、A{B{C}}という状態です。これをドットで表現しているだけです。

Aは、主に全体が変更された時に上がります。仕様変更を意味します。
Bは、機能追加があった場合に上がります。
Cは、不具合修正や微調整など、機能に変更が無い程度の物で上がります。

他の A.B.C.D で表記する場合もあります。
Dは、リビジョン番号が大半です。 r245133 と「r」を付けて書く場合もあります。
この場合のDは他の部分ABCとは独立した番号になります。またがるということです。
1.2.5.33445
1.3.0.33446
2.0.0.33447
というようにです。
A{B{C}}D という状態ですね。

さらに複雑なパターンでA{B{C}}DEもありますが、もうわからなくていいです。
マージやらブランチやらの記録だったりします。

■リビジョンとは
一般の人にが耳にすることがあまりないリビジョン。
リビジョンとは、バージョンの一種です。
バージョンは客向けの抽象的な数字、リビジョンは内部向けの厳格な数字とすることが大半です。
リビジョンにはドットが無く、何かするたびに数字が増えて行くのが大半です。
これは、リビジョン管理ソフトの仕様によるものです。
リビジョン番号により、どの時点のソースかが明確にわかり、開発者にとって便利なのです。
リビジョンは内部バージョンと言われる場合もあります。

binディレクトリ（binフォルダー）とは

binについて誤解している人が多すぎるので、触れておきます。

binはbinaryの略ではありません。
binはbinです。

英語の苦手な人が多い日本では、binを理解しにくいと思います。
日本ではbinは瓶ですからね。

英語のbinはただの入れ物です。
日本人だと、boxのイメージが相当します。
英語のboxは、入れ物というよりも、詰め物です。
boxよりさらに詰め込むイメージはcanかな。

binフォルダーは、一般的な物（フォルダー分けしない物）を入れる場所です。
ルートフォルダーに入れず、binフォルダーに入れているだけです。
結果的に、実行ファイルが大半なだけです。（テキストファイルも存在します）

binはフォルダー以外でも、拡張子のbinもあります。
これも同じ意味です。
色々中にファイルが入っているという意味です。　バイナリ―ではなくビンです。

forおじさん

なんでもかんでも、ループ処理に for を使う年配プログラマーの事を言うそうです。
おそらく、C言語から入った人ではないでしょうか？
たしかにPHPでは for って滅多に使いませんね。

forを見ると、無性に他の処理で置き換えたくなることもあります。
だって、forはめんどくさい場合が多いですもん。

たとえば、

max = count($a);
for (i=0;i<max;i++) { $a[i] }

こういう無駄に複雑な処理！

foreach ($a as $item) {$item}
としたほうが、扱いが非常に楽です。
楽ってことは、バグが入りにくいです。

さらに処理内容によっては、map系など各要素にコールバック関数を適用する関数を使うとさらにスマートで不具合が出にくくなります。

まぁ、foreach だけ使ってれば大抵問題なし。 便利すぎます。

whileもありますが、私はforeachじゃ面倒な場面で使う程度です。滅多に使いません。

phpマニュアルにあるような例

$i = 1;
while ($i <= 10) {
    echo $i++;
}

これだと、while ではなく for を使います。

for ($i=1; $i <= 10; $i++) { echo $i;}

可読性の問題です。

まとめると

①配列をループで取り出す場合は、foreach。
②条件でループさせるる場合は、while。※初心者が意図せず無限ループさせる鬼門
③決まった回数をループさせる場合は、for。
④配列の各要素で処理するなら、集合関数。※foreachにする場合もあり

①と④は似てますが、たとえば①は途中でbreak;が行えますが、④は必ず全ループです。
あとは、スコープの違いがあるため、変数の扱い方が異なります。

ちなみに
「foreach の最中に、元の集合を追加・削除するのは禁忌事項です」
という情報を見かけたが、PHPのforeachを理解していないと思われます。
元の集合を追加・削除する時こそ、foreachが有効だし、これができるというのがforeachの特徴である。

セキュリティーに精神論はやめよう

たまに精神論でセキュリティーを語る人や、精神論者vs現実主義者の言い争いを見かけます。
簡単な例ですが、※あくまで例

精神論でいくと、1カ所対策を徹底するだけで良い。だから1カ所の対策のみでよい。

現実は、そこをミスって脆弱の発生。

なので現実主義者は、2か所以上で対策を行い、万が一片方がミスっても突破されないようにするべきと唱える。
一カ所のみというのは、ミスに対して脆弱である。

長く大量のコードを扱ったり見ていたりすれば明白です。
人間は必ず間違う物。可能性がある物はいずれ現実になります。

徹底すればよいという、非現実的な精神論はやめるべきです。

ちなみに二重にする以外には、ミスしにくい構造を作る事ですね。
フレームワーク側で強制させることです。※ある意味これも二重対策
たとえば、$_POSTをバリデーション後に別変数へ格納unsetし、外部からのデータを直接使えなくする仕組み等。
使っちゃだめと決めても、使えるってことは使っちゃう人が出るということです。なので使えなくします。

こういう考えは、プログラミングに限らず、仕事の仕組みとして非常に重要です。

staticメソッドの呼び出しは、selfでなくstaticにしよう

その前に、「$this」はまだしも「$this->」で呼び出すのはやめましょう。
静的なのかインスタンスがあるのか、構造がわかりにくくなります。

selfは、古くららphpを使っていた人がよく使います。
staticは5.3から追加された遅延静的束縛機能です。

selfだと、クラスを継承した時にselfが継承クラスに置き換わらないので、非常に面倒です。
継承禁止のクラスでのみ使うべきです。
でないと、親クラスからコピペしまくり状態という、悲惨なコーディングになります。

statcは、簡単に言えば、呼び出されているクラスに置き換わります。
これがちょっと曲者でして、

selfで呼び出した先でstaticで呼び出すと、selfで呼び出されているクラスに置き換わります。

selfはコンパイル時に静的にクラス名が入り、staticは実行時に動的に入るイメージをすれば良いと思います。

まぁ、ややこしくなって不具合の元なので、staticで統一しましょうってことです。

smarty2でも、メモリからテンプレートを読み込めます

smarty2はデフォルトでメモリからの読み込みに対応していないので、あきらめている人を多く見かけますよね。

でも、方法がちゃんと用意されているのですよ。

ほんのちょっとコードを書くだけです。　プラグインとしてね。

公式ドキュメント http://www.smarty.net/docsv2/ja/plugins.resources.tpl
これでさくっと完成します。

Exampleをコピペしてプラグインとして読み込み、システムにあったコーディングをするだけです。

smarty_resource_db_sourceとsmarty_resource_db_timestampのみ書き換えで、後の２つはダミーです。（使わないけど書かないといけないだけ）

メモリから読み込みなので dbではなくmemoryにしましょう。
smarty_resource_memory_source というように。　残る３つも同様にです。

smartyに渡すファイル名のフォーマットは、「type:filename」です。
通常はtypeを省略していますよね。　省略するとtype は file になります。

今回の例では、「memory:filename」にしてあげれば、プラグイン側の処理をしてくれます。
filenameは、使わなければダミー値を与えればよいです。

あとは、smartyオブジェクトにテンプレート内容を渡してあげれば完成です。
$smarty->templateSource = テンプレート内容;

この場合のsmarty_resource_db_source()の内容例としては

$tpl_source = $smarty->templateSource;
return true;

この２行にするだけで動きます。
smartyをシステムに組み込んでいる人なら朝飯前だと思います。

Chromeの ERR_BLOCKED_BY_XSS_AUDITOR 原因

56で実装され、57で強化され問題となっている ERR_BLOCKED_BY_XSS_AUDITOR。
大手サービスやソフトも片っ端から問題発生となり、大騒ぎですね。

どうも判定ルールが公開されていないため、試行錯誤で皆回避方法をさがしています。
一番やっちゃいけないのは、セキュリティーをOFFにする方法。　これだけは絶対にやっちゃダメ。

原因の多くが iframe で、検索するとこの情報しかみつかりませんでした。
私が開発を手掛けているサービスで発生したケースが見つからないので載せておきます。

JavaScriptによる submit()実行において、送信内容(input内容)に form要素があり、かつaction属性が存在する場合に発生となりました。

回避方法は、JavaScriptで送信するまえに文字列置換を行い、サーバー側で元に戻してあげることです。

色々な情報をあわせると、JavaScriptでsubmit()する時の制限が厳しくなった感じです。
iframeとformの扱いに注意ですね。

サーバー or サーバ どっちが正しい？

言葉は常に変化していっているので、新旧共にメジャーな時って迷う事がありますよね。
特にカタカナ用語は、時代による変化が激しいです。ほんと困りますよね。

インターネットが定着すると共に目にするようになったのが、長音記号の省略です。
サーバーと書かず、サーバと書いたり、メモリーと書かず、メモリと書いたりです。

工業系の企業では、省略する場合が多いです。
その他の企業では、省略しません。
すなわち、エンジニア以外で省略する人は稀です。

IT系はどうかと言うと、察しの通り一般とは異なることが好きなオタクが多いので、中小企業では省略が多いです。

どっちが正しいか？と言われると、「省略しないのが本来だが、省略するのはJISで認められているので間違いではない。」になります。

JIS Z8301により、「略しても謝りでない」としています。
どっちでもいいよってことですね。
国語としては、「原則略さない」となっています。
上記が決まったのは21世紀になってからです。
それまでは、略すのは工業系の人だけで、一般人が目にすることはありませんでした。
20世紀のJIS Z8301では、略すことになっていたからです。
それがネットにより一般に広まって混乱が発生したため、「原則略さない」で再度決めた感じです。

あと、IT系企業は普通略すって言う人を良く見かけますが、間違ってます。

マイクロソフト：略さない
IBM：略さない
アマゾン：略さない
ソニー：略さない
NEC：略す
富士通：略す
日立：略す

国内工業系は、昔からの伝統で略しています。
ネットで発言する人の素性は偏っているため、どうしても省略を多く見かけるってだけです。


私の場合は？

字数少ない方が楽なので、気にする必要の無い時は略しています。
正式な場では略しません。

textareaをブラウザいっぱいに広げる WideArea をfixしてみる

textareaをブラウザいっぱいに広げる切り替えができる軽量スクリプトに WideAreaというのがあります。
手軽に実装できて、非常に便利です。

だがしかし、長い間メンテさていなく、不具合がいくつか残ったままです。
まぁ小さなスクリプトなので、さくっと手直しして、実用に耐えられる物にしてみます。
ただし、jQuery前提の箇所もあります。
それと、好みによる改造ポイントも。

■拡大ボタン表示位置を決めるロジックが動いていない
公式トップにあるデモを見ての通り、IEでもChromeでもEdgeでもダメです。
昔の古いブラウザではおそらく、動いていたのでしょう。

×:offsetWidth
〇:clientWidth

ユーザー入力部分の横幅は clientWidth で取得しなければなりません。
offsetWidthですと、一番外側のボーダーまで含まれてしまいます。

これだけだと、スクロールバーが無い時にアイコンが点滅っぽい状態になります。
タイマーでループ処理されているのですが、最後の条件文が正しくありません。
タイマーを使う事自体が間違っているというのは置いておきます。

×:(oldPosition.left - currentTextareaPosition.width + 21) != currentTextareaPosition.left
〇:oldPosition.width != currentTextareaPosition.width

■拡大時に、スクロールバーが二重化
スクロールの発生するページで使うと、ページのスクロールとtextareaのスクロールで２重になります。

拡大時はページのスクロールバーを非表示にしてあげましょう。

・拡大移行処理
関数 _enableFullScreen() 内 document.body.appendChild()実行直前に追加

$("body").css("overflow","hidden");

突然jQueryでごめんなさい。

・通常サイズ移行処理
関数 _disableFullScreen() 内 overlayLayer.parentNode.removeChild()実行直後に追加

$("body").css("overflow","auto");

これで綺麗に動きます。

■ヘンテコなバックアップ機能がある
複数ページに設置すると、動きません。(他ページのバックアップで上書きされる)
フォームに初期値が入っていると、機能しません。（バックアップで上書きされる）

_saveToStorage()と_getFromStorage()の中身を空にすれば、機能を削除できます。

■拡大ボタンの表示に問題が起きる場合等
タイマーを使ってるので相性問題が出やすいです。アイコン追従がカクカクですしね。
汎用的にするなら、タイマーを使わない実装がよろしいです。

textareaのサイズ変更時に処理したいなら、タイマー部分を削除して
$(document).on('mouseup mousemove change', 'textarea[' + this._options.wideAreaAttr + '=\'enable\']', function() {
var wideAreaIcons = document.getElementById("widearea-" + $(this).attr("data-widearea-id"));
_renewIconsPosition($(this)[0], wideAreaIcons);
});
サイズ変更中は mouemove で拾えます。
変更完了は、mouseup で拾えます。
スクロールバーが出たり消えたりは、change で拾えます。

他の方法としては、jQuery UIの resizable を使う方法もあります。
これのイベントに resize があります。

上記のみだと、テキストエリアの位置そのものが動的に変化した場合にボタンがズレます。
CSSで absolute(絶対値) 指定しているのが原因です。
.widearea-icons を position: relative; にしましょう。
これにより下部に余白ができてしまうので
.widearea-wrapper {height: 0;} を追加します。

js側の修正は
- document.body.appendChild(wideAreaWrapper);
+ $(currentTextArea).after(wideAreaWrapper);
これでボタン要素がテキストエリアに追従するようになります。

位置修正関数 _renewIconsPosition() も修正します。
iconPanel.style.left = currentTextareaPosition.width -21 + "px";
iconPanel.style.top  = "-" + currentTextareaPosition.height + "px";

これで大抵の場合はボタンがズレなくなります。レスポンシブ対応ってことです。

■拡大時に横幅固定とフォント巨大化で、拡大のメリットがあまりない問題
拡大しても、文字が大きくなるだけで一度に表示できる量が変わらなじゃんって場合。

CSSの max-width を削除すれば、名実共にフルサイズボックス化。
font-sizeとline-heightも削除か変更して、快適に。

AWSでAMIから起動した時に、SSHのパスワードを許可する正しい方法

sshd_configで 「PasswordAuthentication yes」 としても、AMIからインスタンス作成時に 「no」 になります。

パスワードを許可しなくてはならない場合、これはとても面倒です。
たとえば、一部のユーザーのみパスワードを許可することなんて、よくあることです。


そこで、設定どおりに起動してもらう方法。


AMIからインスタンス作成時には、色々と初期化されます。
その中に、sshd_config の書き換えがあります。

強制「no」設定が書かれている箇所は、

/etc/cound/cloud.cfg.d/00_defaults.cfg
※もしくは /etc/cound/cloud.cfg

ssh_pwauth: no

です。
sshのパスワード認証を許可するかどうかの設定になります。
これを「yes」にすれば、yesで書き換えが行われます。
※「0」や「false」と書かれている場合は、許可するには「1」や「true」

これを安易に「yes」としてしまうと、全てが yes。　これは面倒です。
一部のユーザーのみ許可したくてもできませんしね。
sshd_configで管理できないのは面倒です。

そもそも、yesにする意味がまったく無いではありませんか。

てことで、「ssh_pwauth」の行を削除しましょう。
設定が無ければ、何も書き変わりません。

AWS S3のCLIの落とし穴 「空ディレクトリ」

s3のCLIは非常に便利ですが、見落としがちな仕様があります。

「空ディレクトリは無視される」

linuxコマンドのような、cp, mv, sync などが用意されていますが、どのコマンドも空ディレクトリはスルーされます。
「--recursive」を使って丸ごとコピーしたくても、空ディレクトリはコピーされない点が非常に面倒です。

厳密には、s3のデータベース上で、値が空のデータですね。

また、mvはcpのエイリアスでしかなく、mv元は消えません。
ファイルパス/ディレクトリ/ファイル名の変更はできないので、コピーして削除と２回実行しないといけません。

s3はただのkey-value式データベースでしかく、ファイルパスがkeyとなっています。
ファイルシステムの常識は通用しないので注意が必要ですね。

ちなみに私のプロジェクトでは、空ディレクトリになる場合があるディレクトリにはダミーファイル。
もしくは、ディレクトリが無い場合は自動作成するロジックで対応させています。