タグ

ブックマーク / parashuto.com (23)

  • Homebrewで覚えておくと便利なコマンド一覧

    Git 2.26.0以下に脆弱性が見つかった とのことで、Homebrewでインストールしたgitを更新しようと思ったら、自分がHomebrewのコマンドを理解していないことに気づきました。 ということで、この際、覚書的にメモっておきます。以下、よく使いそうなコマンドの一覧です。 Homebrewの更新 インストールしたフォーミュラ(パッケージ)が更新されるわけではないの要注意です。僕はココを勘違いしてました。 brew update インストールしたフォーミュラの更新 brew upgrade フォーミュラ名のように特定のフォーミュラを指定して個別に更新も可能。何も指定されていない場合は、インストールされているすべてのフォーミュラが更新される。更新後にbrew cleanupも実行されて30日以上古いフォーミュラは削除されます(参考 )。 brew upgrade 更新可能なフォーミュラ

    Homebrewで覚えておくと便利なコマンド一覧
  • ウェブデザインにおけるline-heightについて

    ウェブデザインにおけるline-heightってけっこう曲者で、CSSを理解してデザインしないと「空き」の設計が破綻したりコーディングで苦労することになります。FigmaやAdobe XD、Affinity Designerなどのグラフィックアプリでline heightの扱いが異なるので、使うツールの挙動を理解するのも大切です。 ということで、今回はCSSline-heightについてまとめてみます。 実は調べれば調べるほど奥が深いCSSline-heightの世界ですが、まずは基礎からまとめていこうと思います。 目次 以下はページ内のセクションへのリンクです。 CSSline-heightでは文字の上下にスペースができる ウェブで使われるハーフ・レディングとは 印刷とウェブにおけるレディングの違い デザインツールでのline heightの扱いの違い 上下のハーフ・レディングを帳

    ウェブデザインにおけるline-heightについて
  • 【2020年夏】imgタグにはwidthとheight属性を書くのがいいらしい

    そうなんです。 2020年夏、ページの読み込み中にレイアウトがシフトしないように、img要素にはwidthとheight属性を記述するのがいいらしいんです。 <img src="link/to/image.jpg" width="300" height="400" alt="画像の説明"> その昔、これが普通の時代もあったんですけどね。レスポンシブな時代にはwidthとheight属性を書かないのが一般的(?)になっていました。また、widthとheight属性が記述してあってもCSSでwidth: 100%; height: auto;が指定されているとレイアウトシフトが発生してしまっていました。 参考: img要素のサイズ属性の記述の有無についてのTwitterのアンケート なんでいまさら? なぜなら、2019年の後半にブラウザにレイアウトシフトを回避するための新たな機能が実装されたか

    【2020年夏】imgタグにはwidthとheight属性を書くのがいいらしい
  • ローカルサイトを外部に公開できるngrokの使い方

    ローカル環境で作っているサイトを、ネット経由で見せたいときってありますよね? そんなときに便利なのが「ngrok 」というコマンドラインのツールです。 自分の端末のローカル環境で作業をしているウェブサイトを同僚に見せたいときや複数端末でブラウザテストをする際、また、BrowserStack やCrossBrowserTesting のような外部のブラウザテストサービスを使うときにも役立ちます。あと、コワーキングスペースなどで作業していてネットワーク環境がコントロールできない時にも便利ですね。 しかも、これが無料で提供されています。ありがたいですね。開発者の方に感謝です。 ngrokでできること ngrokでできることを簡単にまとめると、以下の通りです。 localhostにhogehoge.ngrok.comで外部からアクセスできる マルチデバイスのテストに便利 CrossBrowserT

    ローカルサイトを外部に公開できるngrokの使い方
  • JPEG画像の最適化には85%の品質がいいらしいので画像の最適化プロセスを見直してみた

    オリジナルはPhotoshopの「書き出し」で画質を100%にして書き出した画像です。画像によっては81%にしても目視では差がわからなかったので、それくらい下げちゃっても良さそうですけど、ざっくりとしたデフォルトとしては85%が良さそうです。91% → 85%の方が85% → 81%より圧縮率がいいんですね。 サンプル画像 上の表にある「sampleXX.jpg」の画像をまとめて圧縮したファイルを用意しました。ご参考までに以下からダウンロードどうぞ。 サンプル画像をまとめて圧縮したファイル(ZIP / 3.4MB) ちなみに、表で91%と81%になっているのはImageOptimで設定できるのが、なぜかその数値だったからです。90%、80%には設定できませんでした(v1.8.0)。 職場で作業するときのプロセスはだいたい以下のような感じです。 PhotoshopやAffinity Desi

    JPEG画像の最適化には85%の品質がいいらしいので画像の最適化プロセスを見直してみた
  • Apple Watch(watchOS 5)向けのレスポンシブ対応についてのまとめ

    現在ベータ版が公開されているwatchOS 5 から、メールとメッセージ・アプリでHTMLメールやリンク先のページがWebKitで表示されるようになるそうです(Safariは搭載されない)。ついに!ウェブコンテンツをApple Watchで見られるようになるんですね。 HTMLメールが見られたら便利だと思うことがしばしばあるのでwatchOS 5の公開が楽しみです。画面は小さいですけど、HTMLメールやウェブサイトの内容をサクッとチェックできたら便利だと思うんですよね。 ということで、そろそろHTMLメールやウェブサイトのApple Watch向けレスポンシブ対応を考えておいても良さそうですね。 以下は「Designing Web Content for watchOS 」というWWDC 2018の公式ビデオの内容を基にまとめたものです。実際の環境で確認したものではないので、watchOS

    Apple Watch(watchOS 5)向けのレスポンシブ対応についてのまとめ
  • ウェブ制作者のための「はじめてのiOS VoiceOver」チュートリアル(初級編)

    先日Twitterでアンケートをしたらウェブ制作に関わる方々でスマホの読み上げ機能を使ったことがある方が少ないとのことだったので、はじめてiOS VoiceOverを使うときに困らないように、スクリーンリーダーの超初心者の僕がハマったところや難しいと感じたところをふまえて、チュートリアル的に使い方をまとめてみます。 iOS VoiceOverを初めて使う方のお役に立てれば幸いです。順を追ってiOS VoiceOverに一緒にチャレンジして行きましょう! 中級編(ローター編)も書きました! 目次 以下、ページ内のセクションへのリンクです。 VoiceOverをショートカットに入れておく VoiceOverがオンの時にロックスクリーンを解除する方法 iPhoneの画面が突然真っ暗になってしまったら VoiceOverでページを読んでみる ページの最初から続けて要素を読み上げる ページをスクロー

    ウェブ制作者のための「はじめてのiOS VoiceOver」チュートリアル(初級編)
  • メディアクエリで「em」を使うと基準になるのは何のサイズ?

    メディアクエリを書くときの単位って、何を使ってますか? 僕はいまのところpxしか使ってないんですが、先日、「PX, EM or REM Media Queries? 」という記事を読んで、メディアクエリで使うemやrem単位について、逆に混乱してしまったので、自分でも仕様やブラウザの挙動を確かめてみました。 結論から言うと、emもremもSafariで挙動の違いがあるので、pxがクロスブラウザで一番安定した挙動をします。 いったいどういうことになっているのか? 僕自身、めちゃくちゃ混乱してしまったので整理してまとめておきます。皆さんをさらなる混乱に陥れないことを願いつつ。。。 メディアクエリでemを使う際のブラウザの挙動 メディアクエリでem単位を使うと、そのサイズはブラウザのフォントサイズ設定に相対的になると仕様に書いてあります。なので、ブラウザでフォントサイズの初期値が16pxの場合、

    メディアクエリで「em」を使うと基準になるのは何のサイズ?
  • CSS GridとFlexboxを使ってメディアクエリなしでレスポンシブにレイアウトする方法

    レスポンシブなレイアウトにはメディアクエリが欠かせないわけですが、CSS GridやFlexboxを使えばメディアクエリなしでもレスポンシブなレイアウトが可能です。メディアクエリが全くいらなくなるということはないと思いますが、CSS GridとFlexboxを使えば、メディアクエリの記述を減らす方法があります。しかもコンテンツの幅に合わせて中身のレイアウトを調整するようなエレメント・クエリ的な使い方も、ある程度なら実現できます。 応用すれば今後のレスポンシブなレイアウトのCSSの組み方を変えてしまうような方法です。 ※デモはFirefox 58.0.2、Chrome 64.0.3282.140、Safari 11.0.3でテストしています。 CSS Gridを使ったレスポンシブレイアウト CSS Gridで以下の2つのCSS関数を使うと、メディアクエリなしでレスポンシブなレイアウトが実現で

    CSS GridとFlexboxを使ってメディアクエリなしでレスポンシブにレイアウトする方法
  • スクリーンリーダーのマーケットシェア 2017

    スクリーンリーダーのマーケットシェアが気になってデータを探してみたら、2017年10月に行われた利用状況の調査結果が2017年末に公開されてました。WebAIM(Web Accessibility In Mind) というユタ州立大にある非営利団体が2009年から行なっている調査で、スクリーンリーダー利用者にアンケートを行った結果 がまとめられています。欧米を中心としたグローバルな調査結果(アメリカ60%、ヨーロッパ23%)です。 この調査結果にはない日での状況についても少しだけ言及しつつ、一番気になったデータを抜粋してまとめてみます。 アンケートに回答した1,792名のうち9割近い方がなんらかの障害を理由にスクリーンリーダーを使っていると回答しています。また、障害のうち盲目(blindness)が75.8%、低視力・視覚障害(low vision/visually impaired)が

    スクリーンリーダーのマーケットシェア 2017
  • Webにおけるデザインシステムとは? - Rriver

    最近、パターンライブラリやスタイルガイド、それからデザインシステムについて考えています。もちろん、こういったことは常に考えながらウェブ制作をしてるんですけど、あまり明文化したことはありませんでした。スタイルガイドとパターンライブラリの違いについては書いたので、今回は「デザインシステム」についての考察を書いてみます。 似たようなことを考えている方の参考になれば、というか、議論のきっかけになれば幸いです。 「デザインシステム」の定義が必要な理由 この記事では「デザインシステムとはなのか」掘り下げて考えて行こうと思います。でも、まずはじめに、そもそもなぜ定義が必要なのかを少し書いておきます。 定義をしっかり整理していないと説明するのが難しいですし、議論を深めようとすると、結局、定義に戻ってしまったりするんですよね。議論のそもそもの出発点が違っていると間違った土台のうえに議論を構築してしまったり、

    Webにおけるデザインシステムとは? - Rriver
  • 頑張れウェブ担!ウェブサイトの良し悪しはウェブ担当者の粘り強いコミュニケーションにかかっている

    大なり小なり、企業組織でウェブ担当者をしていると組織的な事情でUXを損なう判断をせまられる時があります。たとえば、以下のようなシチュエーション。 責任者の〇〇さんがそう言ったから システム的に無理だから 他媒体と表記の統一をしたいから ユーザを中心に据えて考えたら「その選択肢はないよね」という判断を余儀なくされる時が結構あるんですね。だけど、そこを知恵と想像力とバイタリティでなんとかするのがウェブ担当者やUXデザイナーと呼ばれる人たちの仕事だと思っています。 ウェブ担当者やUXデザイナーがそこでもうひと踏ん張りして「それはユーザ目線で考えたら○○の方が良いですよ」とか「ユーザ目線で考えることが結果的にビジネスを成功に導くんですよ」と、ユーザを中心に据えた考え方でプロジェクトを導くことで、良い成果をあげてプロジェクトに関わる人たちをハッピーにできる。そして、そういったウェブ担当者の粘り次第で

    頑張れウェブ担!ウェブサイトの良し悪しはウェブ担当者の粘り強いコミュニケーションにかかっている
  • Gulpを使ったSVGスプライトのアイコンシステムとワークフローの作り方

    SVGスプライトって、なんか複雑なイメージがありませんか? 僕はそうでした。なんか、面倒くさそう。。。どこから始めて良いかわからない。。。といった感じでずっと手をつけられずにいました。 でも、今回やってみて思ったんですが、一度ワークフローを確立してしまえばアイコン管理がかなり便利になります。CSSスプライトの時よりも管理が楽になりますし、表示サイズや今後の高解像度対応を気にしなくて良くなるのも嬉しいですね。 SVGスプライトについての英語のリソースはあるのですが、説明が多く、とっつきにくいものも多い印象なので、ここではできるだけシンプルに必要なことだけをまとめてみたいと思います。 では、SVGスプライト・アイコンシステムのGulpを使ったワークフローの構築、始めましょう! 目次 達成したいこと デモページ SVGスプライトの仕組み ブラウザサポート 用意するもの 導入ステップ 最後に 達成

  • 生年月日の入力欄のレスポンシブ対応についていろいろ考えてみた

    先日、生年月日の入力欄をレスポンシブに最適化する良い方法はないか検証してみたら、想像以上に大変だったのでメモを残しておきます。 日付の入力と言えど実はいろいろな実装方法があって、マルチデバイスに対応しながら要件にあった実装をするにはどうしたらいいのか、改めてゼロベースで考えてみました。結局、最終的には振り出しに戻った感じなんですけどね(結論を先に見たい方はこちらからどうぞw)。 近い将来、レスポンシブな日付入力欄の実装が必要な方々の参考になれば幸いです。ちなみに、以下に書いたもの以外に「これいいよ」というのがあったら、ぜひご教授願いたいです。 要件定義とチェックポイント 今回、日付入力欄を実装した際の要件は以下の通りです。生年月日のように年の選択が必須な日付の入力欄の実装だったので、たとえば、ホテル予約の日付選択などとはちょっと違った要件になっています。 a. 年が選択しやすい 生年月日の

    生年月日の入力欄のレスポンシブ対応についていろいろ考えてみた
  • もう、レスポンシブでいいんじゃない?

    先月末、藤井さん の働く株式会社ザッパラスさん にお邪魔して、レスポンシブWebデザインの基のキ的なお話しをさせていただきました。 題して「もう、レスポンシブでいいんじゃない?」 いま、改めてレスポンシブWebデザインについて考えるきっかけになれば、という視点で内容をまとめてみました。 4年前に「レスポンシブWebデザイン 制作の実践的ワークフローとテクニック 」というを執筆したんですけど、そのころからウェブ制作のデフォルトはとりあえずレスポンシブでいいんじゃない?と思っていたのですが、最近、その思いがより強くなっています。職場のウェブサイトをレスポンシブでリニューアルしてから約5年が経ちますが、やっぱり、あの時レスポンシブを選択しておいてよかったとつくづく感じています。おかげで、Googleさんがモバイルインデックスを優先するという昨今のニュース にもあまり翻弄されなくてすんでいます

    もう、レスポンシブでいいんじゃない?
  • 面倒なレスポンシブイメージの画像作成を自動化してくれる神ツールとブレイクポイントの考え方

    レスポンシブイメージ、使ってますか? ウェブサイトの表示パフォーマンスの最適化をする際に、一番手っ取り早いのが画像の最適化です。そこで、イメージオプティム とかMac Automatorとpngquantなどのツールを駆使して一生懸命に画像自体を最適化したりレスポンシブイメージを使って画像を出し分けたりするわけですけども、特にレスポンシブイメージは手動でやるのは正直言ってかなり面倒です。 そ・こ・で! 日ご紹介したいのが「Responsive Image Breakpoints Generator 」です。このツールを使えばレスポンシブイメージの複数画像の作成やHTMLの記述を自動化できて、しかも!アートディレクションまで自動化できるんです。 ということで、今回はレスポンシブイメージについての簡単なおさらいと、画像作成の基的な考え方、それから自動化について書いてみます。 では、行ってみ

    面倒なレスポンシブイメージの画像作成を自動化してくれる神ツールとブレイクポイントの考え方
  • Node.jsとnpmをアップデートする方法

    いつも忘れてしまうので書き留めておきます。macOS Monterey(12.4)で確認をして内容を更新しました。この記事で紹介しているツール「n」もv8.2.0になりました! Node.jsのアップデート n という便利なバージョン管理ツールがあるので、これを使ってバージョンを確認してアップデートします。nの詳しい使い方はこちらの記事 あたりをご参照いただくと良いと思います。n を使う際の注意点もしっかり説明されています。 nのインストール $ npm install -g n Node.jsのバージョンの確認 1行目の「–stable」でStable(推奨版)のバージョン、2行目の「–latest」で最新版のバージョンが確認できます。 $ n --stable $ n --latest Latestのインストール $ n latest latestは最新の機能を搭載した最新版へのアップ

    Node.jsとnpmをアップデートする方法
  • デザイナーやディレクターも知っておきたい、ページ表示速度の高速化の基本

    スマホからウェブにアクセスするユーザが増え、ウェブサイトの表示速度の高速化がより重要な制作の課題になっています。1ページもののサイトなら、フロントエンドエンジニアが一人で実装できるかもしれませんが、ある程度の規模のウェブサイトではワークフローやサイト全体の設計にも関わってきます。また、表示速度の高速化の方法を知らなければ、最適化しやすい、より高度なデザインは実現できないでしょう。エンジニアだけでなく、デザイナーやディレクターがこういった情報を知っていれば、よりスムーズに結果を出せるウェブサイト制作ができるはずです。 ページ表示速度の改善にはいろいろな方法がありますが、この記事では一番効果がありそうなところから攻めていきたいと思います。自分もまだまだ勉強中なので、まずはfilament groupのScottさんの記事 やClearleftのJeremyさんの記事 を参考に、フロントエンド

    デザイナーやディレクターも知っておきたい、ページ表示速度の高速化の基本
  • なんでもかんでもpicture要素を使えばいいわけじゃない!レスポンシブ・イメージ実装の際の注意点

    画像表示のマルチデバイス対応をHTMLCSSのみで実現できる「レスポンシブ・イメージ」ですが、効果的な使い方をするには、いくつか注意点があります。プロダクション・サイトで使えるようになるまでにはもう少し時間がかかりそうですが、基礎と注意点くらいは今から覚えておいても良さそうです。 Cloud Fourというアメリカの制作会社のブログ で、<picture>要素の使い方について注意を促していて、とても重要な情報だと思ったのでこちらでもシェアします。先日書いたレスポンシブ・イメージとPicturefill 2のまとめとあわせて、近い将来、レスポンシブ・イメージ実装の参考になれば幸いです。 まずは推奨の記述方法から レスポンシブ・イメージ実装の際に推奨されるHTMLの記述方法は以下のとおりです: とりあえず、これだけ覚えておけば、細かいところはこの記事をはてブ しておいて、使う時にもう一度見な

    なんでもかんでもpicture要素を使えばいいわけじゃない!レスポンシブ・イメージ実装の際の注意点
  • Appleがトップページで自動送りカルーセルをやめた理由

    残念ながらページ全体のキャプチャをとっていなかったので下までお見せできませんが、ページのメイン要素となるカルーセルの下にはフッターしかありませんでした。ほんとですw そして、おぉ、さすがApple。 ここでも思い切った選択をしたな〜と思っていたわけです。 ところが! 数日後にもう一度トップページを見てみたら、あの懐かしの4つのボックスが戻っているではないですか!? 実は、このレイアウト(巨大ヒーローイメージと4つのフィーチャーボックス)が、何年も続いたAppleの鉄板レイアウトだったわけですが、先日のリニューアルでこのフィーチャーボックスがなくなっていて「ついに、あれもお亡くなりになられたか」と、密かに悲しんでおりました。 その後のこの華麗なカムバックです。 かなり興奮してしまいました。 しかも、スタイルも細かいスペースや背景の扱いがよりシンプルなものに更新されています。 iPadでみると

    Appleがトップページで自動送りカルーセルをやめた理由