「.db」を含む日記

■DS_Storeとかthumbs.dbとか

そういうタイプの人間、身の回りにいるよね

Permalink | 記事への反応(2) | 13:55

ツイートシェア

■Thumbs.db

社内のサーバー上ではThumbs.dbの発生を抑制してほしいわマジで

あーめんどくさ

フォルダをShift+右クリックでコマンドウィンドウをここで開く

del /ah /s /f thumbs.db

を実行して、もう一回今度は

del /s thumbs.db

でだいたい全部消えるかな？

消えてるな！もう一生出てくんなよ！

Permalink | 記事への反応(1) | 16:58

ツイートシェア

■

http://www.slideshare.net/KenyaKodaira/2016-59970832

なんかたくさんブクマされてますが、読む必要ないと思います。

p.4

• HTML Template Engin`d`ってなんですかね。誤字脱字チェックはしましょうね。
• gulpのgは小文字なのでよろしくです。

p.5

• ん〜非常に大きな枠での話をしてますけど、これから出てくる項目がそれらを解決できるのかなぁと、不安がつのりますね
• むしろ「なんでそんなルールを？」という質問が噴出しそうですが！？

p.6

• こういうアジェンダの書き方、斬新ですね

p.8

• EditorCodingってなに

p.9

• コードブロックが見づらいっす。黒バックにblueて誰が読めるのだろうか。若者か。
• npm install後に急にgulpって書いてあるけど、それは何をするタスクなのです？
  • まぁ、この後gulpタスクについて出てるんでしょう……
    • 出てこなかった

p.10

• ちょっとだけ違和感のあるディレクトリ構成

p.15

• FixとかAddとかはいいと思うっていうかみんなやってることなんですが、黒括弧はないでしょう。
• 日本語モードと英語モードを行ったり来たりするのだるいんですよ。
  • Fix - about / フッターリンクを修正
  • これなら「フッター〜」までを英語モードのまま書ける。

p.16

• 逆に考えるんだ。Thumbs.dbと.sass-cache/はバージョン管理しちゃっていいさと。

p.18

コードの品質が維持される場合に限り、難読化、最小化、コンパイルするのは自由です

• HTMLの話ですよね？　コードの品質が維持されない難読化や最小化やコンパイルってなんだろう。
• あとに出てくるけど、CSSには容量削減を異常に求めすぎてるわりには、HTMLには無関心な感じがするんですよね。

p.19

a、span、imgなどの最小の位置にでは開業は適宜対応

• その適宜が人によってブレるから、それを潰すのが「フォーマット」だと思うんすよね。
• いっそ「新しい要素が出現したら必ず改行する」くらい言ってほしい。
• あと日本語が変なんで、それも。

p.20

• NGってなってますけど、NGの理由が伝わってこないっすね。
• divの閉じタグが不正なのはスペース関わらずNGだよ！

p.21、22

• わたしはオッサンなんで、このルールは好きじゃないんですよ。
• //で始まってると、ルート相対パスと見間違えちゃうんだよね。
• それに、ソースファイル上ではそのHTMLがhttpsかどうかがわからないじゃないですか。
• 自身のドキュメントのスキーマに準じたURIの解決に頼るのは、メンテナンス性があるとは思わないんですよね。
• Googleが言ってたら正しいと思わない方がいいっすよ。あいつらは自分たちのことしか考えてないっすからね。
  • ブコメでGoogleのコーディング規約の批判はGoogleに向けろって言ってる人いました。
  • 大事なのは選ぶことだそうですが、スキーマの省略は選ぶべき項目だとは思いません。
  • なのでわたしはそれを選んだことに苦言を呈します。

p.23、24

• .editorconfigにどう書けばいいかをだな……。

p.25

• HTMLのルールだとしたら、そういう開発の都合のコメントを残して納品するのはお行儀が良くないっすね。
• Jadeを使う前提のようだし、Jadeコメントでの話をしてるなら別にいいんすけどね。
• でもさっきからJadeのサンプルが全く出てこないからオッサン不安になってきちゃったっす。

p.26

正しいHTML

• HTMLの正しさとは？
• 参考リンクから察するに、invalidでなければいいと思ってるなんてことはないっすよね。

p.27、28

• default.cssの中身がどうなってるか知らないけど、link[rel="stylesheet"]は「そうするほか解決できない」という理由がない限り、htmlのhead要素内に書きましょうね。
• あと、CSSファイルを外部化しただけで「プレゼンテーション（スタイル）と振る舞い（スクリプト）は、ストラクチャ（マークアップ）から分離する」ことができるわけじゃないので、それも忘れずによろしくです。

p.29、30

• こういうのは、文字参照で記述しなければならない記号を規定して列挙しときましょうね。

p.31

• アクシビリティー（笑）さっきから誤字脱字が多いんだが。

p.32

• えっとえっと……「スプレッドシートのスクショです」って説明されて、ユーザーに何がわかりますか？
• 「このスプレッドシートでは、年を行に、月を列した2010年から2015年までのアクセス数の分布が表でまとめられている」くらいのコンテキストを入れていきませんか。
• 気遣いではなくウェブサイト製作者の責任として。
• ちなみにalt属性のテキストは、コンテンツマネージャーが考えるべき範囲だと思ってます。

p.36、37

• クォーテーションとかはさ、lint設定を開発に組み込む方法を紹介すべきじゃないですかね。
• gulpに普通にありますよ。 https://www.npmjs.com/package/gulp-htmlhint
• あと、容量の削減とかいうなら、空要素のスペースとスラッシュのことも、書いて欲しかったっす。
• 正直、開発ソースの容量を削減するのは無意味だと思いますけどね。

p.40

CSSの教科書

• いやいや、CSS”設計の”教科書ですからね、その本。
• 脱字なのかな！？

p.42、43

• その命名だとまだ粒度が大きくて、何を示しているのかわからないと思うのはわたしだけでしょうか。
• それでどのコンポーネントなのか特定できる程度の規模のサイトなら、CSS設計いらないんじゃないですかね。

p.44、45

• セレクタの単語は、むしろ絶対に省略させないようにした方がいいと思うんですよね。
• 省略していいなら、省略のルールまで決めていきましょう。
• 教えてgooに非常にいいページがありますよ。 http://oshiete.goo.ne.jp/qa/341377.html

p.49、50

• ステートの上書きまでショートハンドでまとめて書くなんてことはしませんよね？さすがに。

p.57、58

• HEXの短縮は規定しなくていいと思います。
• ビルドをかける前に勝手に置換されるような仕組みを入れるべきところかと。
• gulpでできますし、ググれば出てきます。
• ちなみに、#f00よりもredの方が1バイト少ないんですよ。
• 容量削減は人が思いつきでやるには不十分なのです。
• そんなのはビルド時に機械がやればいい。
• 容量の削減を理由に人の行為に制限をかけるのが愚かな行為だと気付いてくれたらうれしいっす。

p.61、62

• もしかして勘違いしているんじゃないかと思ったんですが、「プロパティの終端」は、「宣言」の終端ではないですよ、一応。

p.63、64

• と思ったら宣言のことを「プロパティ名」ってさ。どういうことです。

p.71

• TODOでコメント書くのって、一時的なメモというか、あとでリファクタリングする前提のコメントだと思ってました。
• だから、TODOで「何のためのものなのか誰が入れたのか」書かれててもどうしようもないような。

p.72、73

• FLOCSSとMindBEMdingを共存させるなら、書くべきことが足りなすぎませんか。

p.73

block__element__elementは使用しない

• 冗長になるからやめようって思ってるなら、やめるのはいいけど、そもそもB__E__EはBEMじゃないってことを忘れないでほしいっすね。
• https://en.bem.info/faq/#why-does-bem-not-recommend-using-elements-within-elements-block__elem1__elem2
• 「冗長になるから」じゃなくて「BEMじゃないから」やめろ、です。

p.78、79

• 打ち消しを減らすのは悪いことじゃないっすね。
• でも、追加的なスタイルの宣言をモディファイアの仕事にさせるのは、なかなか危ないと思うんですよね。
• 決まったルールもなく大量にモディファイアが増えたCSSはコンポーネント管理されていると言えるんでしょうか。
• 再利用性？　必要になったら作り直す方が早いと思いませんか？
• 設計してても作り直すことになると思いますけどね。
• あなたはそのプロジェクトのコンポーネントがどうスケールしていくかなんて、予測できているんですか？

p.80、81

• 言ってることは概ね正しいっす。でもサンプルのCSSにタイプセレクタが入っているのはツメが甘いとしか。

p.87

• 日本語校正を。

GoogleChromeなら変換時に右側に△マーク〜

• それGoogle 日本語入力のことかな〜それともChromeにそういう機能があるのかな〜

p.96

• この手の分類で上手くいくというのは幻想。試しに次の画像のファイル名を考えてみてください。
• 「ボタンを示すアイコンで、テキストが含まれていて、背景で使うことが想定されるもの」

• コンポーネント単位で使う画像ファイルと、ページ単位で使う画像ファイルがあるのが変なんですよね。
  • 管理区分が横断しているというか。
  • 画像もすべてコンポーネント単位で管理すればいいわけなんですが。
    • でもあなたはきっと、同じファイルを別名で複数持っておくことを許してくれなそうだ。

p.98

※svgにすることで1つの画像でまかなえる場合はsvgを使用する

• 言っている意味がよくわからないです。
• インラインSVGを使用してfillプロパティーなどで色のバリエーションを管理するってことでしょうか。だったらsvgファイルとしては保持されないですが。
• もしくはSVGスプライト？　スプライトならpngでよくないですか？　なんでわざわざsvg？
• 急にsvgが出て来て混乱しちゃう！

p.102

• ここまで4回くらい読みなおしたんですけが、どうにも上澄みだけの理解しかしてないように感じるんですよね。
• Jadeについては何かルールは設けないのでしょうか。
• JavaScriptについては……？

• そのほかにも、ライティング自体が下手すぎて、これを人に見せるのはどうなのっていう感じがしちゃいました。
• 誤字脱字くらいはちゃんとチェックしたほうがいいでしょうね。

• ルールを設けるのは悪いことではないですが、穴があってはいけません。
  • あいまいな基準や不足だらけのルールに、誰が期待できるでしょうか。
• エビデンスの弱さも気になります。
• コーディングルールの半分くらいはnodeプラグイン互換のlintツールでチェック可能です。

• 結論：いろいろ惜しいけど、よくなる余地はたくさんあるので、がんばってください。

Permalink | 記事への反応(0) | 11:26

ツイートシェア

■最近のWordPressの無料クソテーマについて

STINGER

http://stinger3.com/

スーパービチグソテーマ

Gush

http://gush.naifix.com/

STINGERをもとに作ったうんこテーマ

両者に共通するのはコードがクソ、デザインがクソだということ。

コーディングに規則性がない、まぁコピペだからなんだろうけど…

WordPressのフォーマッタとかあっただろ、それ使ってやれよ。せめてインデントぐらい…

あとディレクトリ構成も /images ぐらいでグチャグチャ

あと Thumbs.db とかいらねーから。同梱すんな。

「SEOに強い」とか気のせいだからな。そのブログのコンテンツが良かっただけのことでしょ。

これらのテーマ使っているブログとか良いことが書いてあっても見る気が失せるんだよなあ。デザインがダサい上に見づらい。見づらいのが致命的だわ。

このテーマが悪いというわけじゃないけど、胡散臭いやつらがこれ使ってる印象。3か月で30万PV！とか嘘吐いてたやつもいたよな。

作者とか関係者とかこれ見ていたら反応くれよ。もっといいテーマ作ってやれよ。初心者だましてないでさ。

Permalink | 記事への反応(0) | 09:50

ツイートシェア

■http://anond.hatelabo.jp/20120614091812

高確率でthumbs.dbというゴミファイルを添付して来るWindozeユーザーにも同じ事を言うべきだな。

Permalink | 記事への反応(1) | 09:31

ツイートシェア

■同人作品等でよく見かけるアレ

dateフォルダ

dataだろ。

samフォルダ

thumbだろ。

1.jpg, 2.jpg, 3.jpg～10.jpg, 11.jpg, 12.jpg…

桁は揃えて頂きたい…

Thumbs.db入り

無害だし大した容量でもないけど…

Permalink | 記事への反応(2) | 21:15

ツイートシェア