このいつまでも「整理」されないWebに #ポエム #駄文 - mimemo
今のWebには「なう」が多すぎる 今のWebには、「なう」が多すぎる。 そんなことをここ数年、ずっと感じています。 twitterにfacebook、Blogやまとめサイト、さらにはQ&Aサイトにしても何にしても、僕らが最近目にするWebの情報の多くは、「今」にフォーカスがあたっています。 みんな「今日起きたこと」「今日学んだこと」「今感じたこと」「今思いついたこと」「今一番新しい情報」「今日まとめられた情報」、そんな形をしています。 ストックとフローで言えばフロー。膨大な量の「なう」の情報が公開され、共有され、あっという間に消化されていく。まあ、これはこれで意味も価値もあるとは思うのですが、どうも「よくない」感じがする。 「整理」されない情報たち いったい何が「よくない」のか。 それは、「なう」の情報がWebに爆発的に多くなった一方で、情報を「編集・整理して蓄積する」ということが本当に疎
JSからtextareaの文字列を変更した時、Undoに対応できるようにする #dev #javascript - mimemo
mimemoのmarkdownエディタを作っていく上で、リストの補完などのアイデアとコードは一部esareaのものを下敷きにして書かせていただきました（多謝）。 ただ、esarea（及びesaのmarkdownエディタ）は、一部のブラウザで補完したあとにCtrl+Zなどでの「取り消し」ができなくなるようでしたので、これはエディタとして致命的、ということでmimemoでは頑張って（？）Undo対応させたので、その辺フィードバックも兼ねたハウツーメモです。 JSからtextarea書き換えた時にUndo対応させる 2018/01/13追記： Firefoxでtextareaの仕様が変わったようで、下のコードでFirefoxはundo対応できません。 方法 Chrome、SafariはexecCommand('insertText')で書き換える形にするとUndoできる形で書き換えられる Fir
Webデベロッパは新しい技術にどこまでついていくべきか #dev #駄文 - mimemo
10年のツケを支払ったフロント界隈におけるJavaScript開発環境（2016年4月現在）。 日本のWebエンジニアの大半が、変化に対応しきれなくなっている件について。 この辺のあれこれを読んで。 フロントエンド界隈の動き早い？ まあ早いですかね、確かに。 それは正直ブラウザというフロントエンド開発におけるOS的な位置付けのものが恐ろしい速度で更新されているし、JSの処理速度も互換性も向上したし、ブラウザ上でやろうとしていることがそれなりに複雑化多様化しているのでまあそうなるよね、と思いますが。 じゃあ、常に最先端をキャッチアップして導入していくべきかというと、んなこたーない。 Webデベロッパは、それぞれで取り組んでいるサイトの種類が違うので、最先端で流行っているからといってそれを導入しなくてはいけない、なんてことは全くないと思います。 たとえばWebサービス系などでSPAを作っている
カクヨムの読みづらさ、あるいは横書きの明朝体について #駄文 - mimemo
カクヨムが始まって、面白そうなので見に行ってみて。 どんなものが上がっているのかと読み始めてみたら、なんともつらい。驚くほど文字が頭に入ってこない。 iPhoneで見た場合はそこまでひどくないのだけど、Macで見た時がつらい。retinaな画面で見てもやはりつらい。 原因は明らかで、そのフォントのせいだ。 カクヨムの小説本文のfont-family指定は、先頭に「游明朝」がある。 游明朝はとてもいい書体だけど、横組みする場合はベストとは言えない。 字游工房のサイトの書体紹介文にも 游明朝体 Pr6 Rは単行本・文庫本などの長文に最適なウェイトです。縦組みに重点をおき、透明な文体で書かれた、渋く、深みのある小説をイメージし、文字を意識せずに読める、奇をてらわないデザインを目指しました。 とあって、実際にサイトの組見本を見ても、この書体は明らかに縦書きのほうが視線が気持ちよく上下に流れて読みや
mimemo - Markdown記法で書けるテキスト共有サイト
Stationheadとは? ストリーミングに便利なの？ Stationheadは、人々がつながり、一緒にストリーミングできる無料サービスです
CSS (Sass) のコーディングルール #CSS #Sass - mimemo
私的（あるいはテンマド社の）CSS/SCSSコーディングについてのルールまとめです。 自分自身の整理/備忘録と、自分の書いたコードを引き継ぐなどしていじることになった人に見せる用。随時更新。 最終更新：2019/09/25 （→ 変更内容 ） ルール設計の指針 覚えるべきことは必要最小限に メンテナンス性の高さを最重要視 開発時に「迷う」「考える」部分を極力減らして余計な事を考えずに済むように 前提 Sassを使う 素のCSSを使うような苦行は避けます。 ほとんど好みの問題ですが、Lessは記法がちょっとよくないので、Sassを使います。 処理速度やツールセットの関係で、本家RubyのSassではなく、node-sassのほうを、大抵はgulp-sassで走らせて使います。 ※そろそろSassを捨ててPostCSSのみで済ませるのも現実的になってきているので、プロジェクト参加者のCSS知識
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
