はてなブックマーク

今さらだけどawait awaitは2017年あたりに出てきた機能で新しくもないですが、私は新しい機能が出ても大体の環境にサポートされるまで触らない意識低い系エンジニアなので、IEで使えない async/awaitとPromiseは存在を知りつつもスルーしてきたのですが、そろそろIEを切ってもいいと思えたので、解禁してみました。 本記事の内容 この記事はawaitがどんな時に役立つかを紹介するものです。 Promiseのことは知っている前提の記事なので、Promiseの使い方を知らない人は、まずそちらを調べてから読むのがおすすめです。 awaitの使い方 awaitの使い方について簡単におさらいです。 awaitはasyncをつけた非同期関数の中で使え、Promiseを返す関数呼び出しの前に書きます。 本記事でawaitを使っているコードは、明示していなくても全て非同期関数内の前提です。

概要 JavaScriptでキーボード押下時などに日本語IME入力中かを判定する方法のまとめです。 日本語入力周りのイベントは、2022年現在主だったブラウザでも挙動に差異があり面倒です。 IME（全角）入力におけるjsイベント現状調査 こちらの方の記事とだいぶ内容が被っていますが、私の調査結果と微妙に異なるところもあり、改めて自分なりにまとめています。 調査対象ブラウザ Chrome 99 (Mac) Firefox 98 (Mac) Safari 15 (Mac) Chrome 99 (Windows) Firefox 98(Windows) Edge 99(Windows) ※ Edgeはバージョン79からChromiumエンジンに変わっており、それ以前は挙動が全く異なると思われるので注意 日本語入力時に発生するイベントの流れ まず、日本語入力時に発生するイベントとその発生順序を確認

Vanilla JSのメリット フレームワークのサイズが大したことないなら、バニラでやるメリットはあるのか？という話になりますが、実際作ってみてバニラの方が優位だった点が１つありました。 それは動作が速いことです。 今回作ったSPAの中に1つ、画面内の要素が多すぎて描画に数秒時間がかかるページがありました。 どれくらい多いかというと、テキストボックス・チェックボックス・プルダウンなどの入力要素が１画面に１万個以上あります。 この画面を高速化したいと思い、試しにVue.jsで同じようなページを作ってみたのですが、比較するとVanilla JSの方が速かったです。 仮想DOMは速いみたいな記事を目にすることがあり、VueやReactはなんとなく速いイメージを持っていたのですが、よく考えてみるとVueやReactだって最終的には画面描画のためにリアルDOMを操作するわけで、それなら必要最小限のリ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 チームによる継続的開発を前提としたコーディングのガイドライン。 特定の言語を対象としたものではないが、主に静的型付けのオブジェクト指向言語を想定している。 サンプルコードは別段の定めがなければSwiftで記載。 ガイドラインの目的 生産性を高め、メンテナンスコストを下げる バグが生まれづらくする 開発メンバー（特に新規参加者）がコードを理解しやすくする 初心者プログラマーの教育 内容の説明 タイトルの頭についた【数字】は重要度。 高いほどシステムに与える影響が大きいが、低いものの方が影響が小さく改修しやすいものが多い。 【5】変数

実現したいレイアウト 特に何の変哲もないレイアウトだが、これをConstraintLayoutで作るのに手こずった話。 素直なConstraintLayout実装 とりあえず上記のレイアウトを素直に作ると以下のようになる。 <androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="70dp" xmlns:app="http://schemas.android.com/apk/res-auto" android:background="#FFDDDD"> <TextView android:id="@+id/titl

ImageViewのサイズがwrap_contentじゃない前提。 絵、写真 → FIT_CENTER 9パッチ画像 → FIT_XY スプラッシュ → CENTER_CROP 以下補足。読むと秒では決まらない。 よく使うもの 画像は正方形のImageViewに横長の画像をセットした場合のイメージ。 FIT_CENTER 縦横比保持 切り取られず、画像全体が表示される ImageViewにちょうど収まるよう拡大・縮小される ImageViewの全体は画像で埋まらず、隙間ができる 画像の縦横比を維持したまま、画像全体がImageViewに収まる最大サイズで、Viewの中心に画像を表示する。 Viewと画像の間に、縦か横どちらか隙間が空く。 縦横比保持で画像全体が表示されるので、絵や写真を表示するには一番無難なパターン。 画像全体がImageViewに収まるように表示するので、場合によっては結

TARGETについて TARGETはビルド設定のまとまりで、Xcodeでプロジェクトを作成すると自動で1つ作成される。 TARGETを複数用意することで、テスト用、本番用などを切り替えてアプリをビルドすることができる。 サーバー環境を複数用意する場合などは、TARGETも複数作成すると良い。 TargetとConfigurationどちらを使うべきか 2019/12/17 追記 Xcodeにはビルド設定を切り替える仕組みが、TargetとConfigurationの2種類存在する。 Targetの方がより詳細な設定ができるが、この記事に書いた内容は全て Configuration でも切り替えられる。 多くの場合、Targetを複数作るよりConfigurationを複数作る方が運用が簡単である。 ただし、以下のようなケースはConfigurationでは対応できないため、Targetを複

SwiftをKotlinに書き換えるにあたってのチートシート。 コード変換 angelolloqui/SwiftKotlin このツールでSwiftからKotlinへの静的なコード変換ができる。 こちらのページから直近リリースの変換ツール（SwiftKotlinApp.2017-12-10.20-14-06.zipなど）をダウンロードできる 便利なツールだが完璧な変換ができるわけではなく、ざっと確認したところ以下の問題があった。 class var、class funcが上手く変換されない（staticは大丈夫） enum内のfuncなどが変換されない タプルが上手く変換されない（Kotlinにはそもそもタプルがない） deferブロックが上手く変換されない case文にenumをフル修飾で書く（ case Animal.dog: のような形 ）とエラーになった このツールでベースのKot

必須: 基本的に対応が必要。何らかの要因で対応できない場合は関係者への同意をとる。 できれば：状況的に困難でなければなるべく対応する。 基本対応なし：特別な要件がなければ対応しない。 直近修正履歴(2018/11/21) [OS共通] ログ出力の対策にproguardによる方法を追記 [iOS] 通信データのキャッシュの対策に一部問題があったため修正 [OS共通] 通信の暗号化 対応要否：必須 リスクの詳細 HTTPで通信を行うと通信データが平文でネットワークに流れるため、情報漏洩の危険性がある。 対策 通信を行う場合はHTTPS(SSL/TLS)通信を利用する [OS共通] SSL証明書のチェック 対応要否：必須 リスクの詳細 通信やWebViewで行われるSSL証明書の正当性検証を無効化すると、ネットワーク管理者などにより通信経路上のデータ改竄、傍受が可能になる。 対策 試験環境で証明

結果を見るとモデルの新旧に関わらずシンプルにコア数×クロック数が高いほど速い。 ビルド時間はクロック数×コア数にだいたい反比例してるっぽく見える サンプル数が少なく心もとないが、グラフにするとビルド時間はコア数×クロック数にだいたい反比例してるように見える。 だとすると、ビルド速度はコア数×クロック数にだいたい比例しているということになる。 （ちゃんと見ると2コアと4コアの間に傾きの飛びがあるように見えるが、だいたい反比例していることにしておく。。。） また、速度がコア数に比例するということは、Xcodeはマルチコアを全て活用できているということになる。 CPUのTurbo Boost機能は一部のコアしか使えない場合に有効になるので、Turbo Boostの周波数はビルド速度に影響しないと予測できる。 並列設定を変えるとビルドは早くなるのか？ defaults write com.appl

variantFilter { variant -> // buildTypeが"debug"、flavorが"a"のBuild Variantは作成しない if (variant.buildType.name == "debug" && variant.flavors*.name.contains("a")) { setIgnore(true) } } variantFilter内に任意の判定を書いて、setIgnore(true)とするとそのBuild Variantは作成されなくなる。 Flavorはvariant.flavorsの形でListで取得されるが、ここに記載するbuild.gradleではflavorsには一つのflavorしか入らない。 FlavorおよびBuild Typeで切り替えられること 必要であれば様々な設定を切り替えられるが、主に以下を切り替えることが多い。

議題 JavaでHTTP通信を書くことになったけれど、クライアントライブラリはいったいどれを使うのが良いのか？ 候補が多くて迷った。 前提条件 簡単に導入してサクッと使いたい 分かりやすくてシンプルなコードにしたい そんなにたくさん機能はいらない Androidでも使えるといい 何があるか 使ったことがあるもの、知っているもの Apache Commons HttpClient > 昔よく使った古株の有名どころ。情報が多い。 Apache HttpComponents > 上記の発展系 OkHttp > 最近Androidアプリで使った google-http-java-client > 使ったことないけどそこそこメジャーっぽい HttpURLConnectionで自前実装 > 昔実装したけど結構めんどい 他にもないか探す Googleで「okhttp vs」や「apache httpcl

機能自体は良いが色々とウザい。 簡単なViewを作るのに2、3時間費やしてしまったのでメモをアップする。 InterfaceBuilder(以降IB)表示時にビルドがかかり非常に重くなる 普通のViewでは不要な考慮が色々必要 IB上でエラーが起きても原因が分かりづらい IB上でエラーが起きるとXcodeがおかしくなることがある IBを開くびにビルドがかかる IBDesignableを修正してIBを開くとビルドがかかる。 IB上でフォントサイズを変えるだけでビルドがかかる。 メニューの “Editor” > “Automatically Refresh Views” のチェックを外すと自動でビルドがかからなくなる。 IB上で手動でViewをリフレッシュしたい場合、メニューの “Editor” > “Refresh All Views” を実行。 画像リソースを使えない #imageLite