技術文書の長音記号どうする？「コンピューター」と「コンピュータ」2022年現在と過去のルールについてのまとめ日本語Englishdocumentation外来語長音 長音記号付ける？付けない？問題とは "computer" を日本語のカタカナ表記で記載したい場合、歴史的経緯などから次の2通りの表記方法がありえます。 「コンピューター」 末尾に「長音記号」があるパターン 「コンピュータ」 末尾に「長音記号」を付けないパターン 2022年現在の結論 原則的に語尾の「ー」は付ける "computer" => 「コンピューター」 迷ったら？ 原語がUSA英語で単語としてのスペル的にあるいは一般的発音慣習で伸びる場合 => 付ける "computer" => [US] kəmpjútər => 「コンピューター」 "operator" => [US] ɑ́pərèitər => 「オペレーター」

San Francisco Font Family San Francisco はひとつの書体ではなく、SF Pro, SF Compact などと呼ばれ、それぞれに Text, Display, Rounded バージョンが存在します。Text よりも Display の方が多くのウェイトを揃えているのは、Text は視認性を重視した書体ゆえ、細いものは利用する想定にないからなのだと思われます。SFシリーズはVariable fontに対応しています。 SF Pro vs. SF Compact SF Pro は macOS や iOS, tvOS デバイスのシステムフォントとして採用されています。SF Compact は Apple Watch のシステムフォントとして採用されています。Compact は字が四角形に近い形をしていて、Apple Watch のような小さなデバイスでも視

時系列順に書いているので、話題がアッチコッチいきますが 現場のライブ感を重視しています！ プロジェクトの後半で、すごい優秀な方が入ってきてくれたのでそこからの受け売りも結構混じっています。神様ありがとう。 プロトタイピング 何は無くともまずはプロトタイプを作成しました。 今回はUIライブラリとしてMaterialUIを採用。 superagentを使って外部JSONファイルを読み込んで、Reactコンポーネントとして表示するだけ。 この時点でのコードレビューでの話題は主に、CSSをどうするのか問題。 MaterialUIにコンポーネント自体のstyleは既に定義済みだが、それだけでは足りないレイアウト調整が発生しそうという懸念でした。 結論は、コンポーネント内に直接定義してしまってOK。 実際作業を進めてみたところ、最初の想定よりは補助的なCSS記述は不要でした。 reduxの導入 作成す

この記事の目的 セル（UITableViewCell）は iOS においてもっとも一般的なビューのひとつです。セルを利用することで、コンテンツの表示、選択、スイッチやボタンの配置、テキストフィールド、ナビゲーションを実装することができます。この辺りの具体的な実装例は『設定』や『Apple Store』が参考になるでしょう。セルにはさまざまな役割を与えられますが、どのような作法に従ってデザインされているのかよく理解する必要があります。 セルの一般的な利用作法は iOS Human Interface Guidelines で解説されていますが、私はこれを読んだだけでは十分に理解が及ばなかったため、iOS 標準アプリの事例からセルのデザインについて考察したものをまとめました。この記事では iOS の標準的なセルのデザインパターンを探り、自身のアプリにどう活かせるのかの土台となるよう考察してみま

はじめに iOS のヒューマンインターフェースを理解するためにはまず UI 設計の原則を定めた聖典 iOS Human Interface Guidelines を読むことから始めなければなりません。ここにはプラットフォームの特徴からデザインの原則、それぞれの部品が何のためにデザインされたのか、どう利用するのか、iOS を構成する UI の基本指針がまとまっています。 よく、『磨りガラス効果がかっこいい』『アニメーションしておくとイケてる』『ボタンは右配置の方が右手で押しやすい』『流行っているから』……などの観点によって UI の設計が決められることがありますが、そういうことではないのです。いや実際かっこいいかわいいだとかの感覚は重要なのですが、見た目が何となくそれっぽいだけでは優れた UI とは言えません。磨りガラスでも何でも必ずそこには意味があります。だからこそ HIG に書かれた思想

どういうこと？ iOS アプリの開発をしていると 中国語っぽい日本語フォント というものを見たことがあると思います。Interface Builder で配置した UILabel だったり、英語設定になっている iOS Simulator でうっかりアプリを実行してしまったときだったり、そのような場面でお目にかかることができるフォントです。Interface Builder の件は残念ながらわかりませんが、シミュレータについては設定アプリから言語設定を「日本語」にすれば本来のヒラギノフォントになります。これはバグではなく iOS の仕様です。詳しくは後ほど説明します。今回はこの 中華フォント現象 の仕組みと、それが通常のアプリでも発現し得ること、そしてその解決策を示したいと思います。 まずは中華フォント現象について詳しく説明します。 中華フォントの正体 このお馴染みになっている宮澤賢治のフ

はじめに 本稿は UI Design Advent Calendar 2015 – 8日目のモバイル UI に関する記事です。 まず私はハンバーガーメニューという UI が嫌いです。その理由についてこの記事で説明していきたいと思います。 あの三本線を人はハンバーガーと呼ぶ 最近よく見かけるあの“三本線”のことを海の向こうでは ハンバーガーアイコン とか ハンバーガーメニュー とか言うらしいです。上のがパンで、真ん中のがハンバーグで、下のがパンに見えるからだそうです。にしてもこのただの三本線をハンバーガーと表現するのは少し無理があるような気がします。まあ違和感あれどそこに抗っても仕方がないので、とりあえずこれはハンバーガーと呼称することにします。 ハンバーガーメニューを避けたい理由 真面目にハンバーガーメニューを考察してみます。 1. 何をするのかがわからないアイコン https://dri

はじめに 本稿は UI Design Advent Calendar 2015 – 9日目の GUI アニメーションに関する記事です。 アニメーションの12の基本原則と GUI ディズニーの アニメーションの12の基本原則/12 basic principles of animation というのがありまして、要はこの原則に沿ってアニメーションを制作すればまるでそれが生きているかのような動きをする、平たく言えばディズニーっぽい動きになる、というものです。http://the12principles.tumblr.com がとてもわかりやすいので、うちいくつかを転載しておきます。 SQUASH & STRETCH ANTICIPATION FOLLOW THROUGH & OVERLAPPING ARCS ビデオ解説：The illusion of life これらを見ただけでも、『あー、デ

はじめに iPhone の登場から日本でも次第にアプリや Web における UI, UX というものが重視されるようになりましたが、昨今はプロトタイピング・ツールが盛り上がりつつあるようです。毎年いろいろなツールが登場してきているので、ここでは特に気になったプロダクト（一応モバイル方面、特に iOS/Mac に近い所）を自身のメモも兼ねて挙げていきたいと思います。 プロトタイピング・ツール / サービス Prott 用途：ワイヤーフレーム設計、ペーパープロトタイプの取り込み、画面遷移設計、共有 Goodpatch が開発したプロトタイピングツール。エディターでワイヤーフレームを描くこともできれば、Sketch からデータを読み込むこともできる。リンクをつないで Web やモバイル端末でプレビューすることも可能。 Sketch プラグイン https://blog.prottapp.com/

Repos: https://github.com/usagi/rust-memory-container-cs 文字で読み書きするとやや大変です。しばらく間を開けてRustを触ったりするとスコシ混乱するかもしれません。と、いうわけでRustでメモリーコンテナー系に触れるモードになった時用に1枚絵のチートシートを整理しました。 文字を書けるQiitaにポストするのでちょっとだけチートシートの解説も乗せます。 おまけ解説 Threads; スレッド群 (rev.0 -> rev.1 でこのチートシート上で最初に現れる選択肢に切り替わりました ⇔ Ownership; 所有権) Rustではマルチスレッディング実行の安全性を向上するため、 適当に確保したメモリーをスレッド間でうっかり共有できない(少なくとも簡単にはうっかりできない程度に難しい)仕組みがあります。その仕組みの核心は標準ライブラリ

下で最新版に記事を編集しましたブログを作ったよ ツイッターアカウントフォローお願いします https://twitter.com/usagipycom こんな記事も書いてます 友達がpythonでPCゲームのレベル上げツールを作っていた それを聞いて、pythonって便利なのね。と思いその後色々あってプログラミングを勉強することにした プログラマー35歳までみたいな世の中で40代おそすぎ！ってあるかもしれない PCがあって、無料の教材はネットに転がってるし、本もたくさんあるし、挑戦するのは無料だし2022年の1月ぐらいから勉強を始めた 入門書って成果物がないからつまらないなと思ってそれ以外になんかないかなって本屋さんをふらふらしてたら python自動化 みたいな書籍がいっぱいあることに気がついた なるほど、もしかしたら仕事楽になるんじゃないかそんな思いから次の本を買った シゴトがはかどる

Webパフォーマンス向上施策のために、今更ながら超速本1を読んだので、今までの自分の知見と合わせてまとめてみます。 なるべく柔らかく、改善施策ってまず何をどうすればいいの？という疑問を持った人に向けて書いています。 ▪️格言 そもそもWebは速い。遅くしているのは我々です。大抵は技術の問題ではなくて、人の問題。 引用元： テクニックではなく、今、本気で取り組むべきWebパフォーマンス （html5jパフォーマンス部 部長 竹洞さん） 心得 パフォーマンス向上に対する施策は大別すると以下の２通り 軽量化 （単純にやりとりするデータ容量を小さくすること） 圧縮 削除 最適化 （その時に最も適している実装・実行をとること） 経路・順番の変更 非同期 もっとも遅くしている原因を探して、それを対策するのが原則。「対効果」が絶対的正義である。手段から入るのは愚策。まず先に原因を知ることが重要。 ▪️1