GoogleデータポータルでTwitterのダッシュボード作ってみた - Qiita
これはなに Googleデータポータルを用いて、Twitterのアカウント分析用ダッシュボードを作る ※「データポータルとは？」という方は、以下の記事をご参照ください。 背景 Twitterアナリティクスでは無料でTwitterアカウントのパフォーマンスが確認できます。 但し、クロス分析などの細かな分析はできません。 今回はTwitterアナリティクスのデータを使い、Googleデータポータル上でダッシュボードを作成しようと思います。 いざ、実践。 ゼロから作ろうと思っていたのですが、moootさんによる素敵な記事を見つけたのでテンプレを拝借させていただきます🙏 今回はこちらのテンプレを元にカスタムしてダッシュボードを作成していきます。 1. Twitterアナリティクスでデータを出力し、スプレッドシートに貼り付ける Twitterアナリティクスにアクセスし、By Tweet、By da
Raspberry Pi の64-bitと32-bitで、パフォーマンスはどのように変わるのか？ (メモ置き場) - Qiita
Raspberry Pi の64-bitと32-bitで、パフォーマンスはどのように変わるのか？ (メモ置き場)RaspberryPi 64-bit 版 Raspberry Pi OS が正式リリースとなりました。アーキテクチャーの違いでどのくらい差が出るのかを確認した内容です。 検証環境 共通 Raspberry Pi 4 Model B 4GB microSD: SDSQUAR-032G-GN6MN (32GB/A1) ベンチマークプログラム: 姫野ベンチマーク この条件下で、Raspberry Pi OS 32-bit / 64-bit それぞれで姫野ベンチマークをコンパイル＆実行した結果を比較しています。 姫野ベンチマークは、CPUだけでなくメモリ帯域にも負荷がかかる(ような)ベンチマークテストプログラムとして選択しました。 結論 64-bit バイナリーは、32-bit バイナリ
2022年の Flutter ロードマップ【要約】 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最近、Flutterのロードマップが更新され、2022年のものが追加されました。 Flutterの最新情報は追いかけたい、でも英語読むのはめんどくさい！ そんな方に向けて、本記事ではこのロードマップの要約を記載します。 あくまで個人の要約ですので、細かいニュアンスや詳細を知りたい方は、 下記の元記事を読んでください。 時間がない人向け## 短くまとめると、以下の内容でした。 開発者体験向上させる デスクトップのサポートをstableチャンネルにする Webも色々向上、ページ埋め込み機能を実装予定だ Material 3のサポートとか色々
Rust のパフォーマンスに何が影響を与えているのか - Qiita
動機 The Rust Performance Book という書きものを見つけました。いろいろなパフォーマンス改善テクニックが書かれているわけですが、実際に普段書いてる Rust コードの中で一体何がパフォーマンスに与える影響が大きいのか？という点が気になってベンチマークを取ってみました。 今回パフォーマンスを計測するプログラムはビットマップ画像（1600px x 1200px）をグレースケールに変換する処理です。I/O のパフォーマンスは無視します。&[u8]から RGB をそれぞれ 1byte ずつ（合計 3bytes）取ってきて、それをグレースケールの 1byte に変換してVec<u8>にする時間を計測します。イメージとしては下記のような関数です。 // source が カラーのビットマップ画像のデータ fn sample(source: &[u8]) -> Result<Ve
結局useMemoはいつ使えばいいの？ 僕の決定版 - Qiita
皆さんこんにちは。筆者の以前の記事では、ReactのuseMemoを無駄に使うことによるレンダリング速度のオーバーヘッドがどれくらいかをベンチマークによって示しました。 それによれば、スマートフォンを想定したとしても、useMemoだけで描画に目に見える影響を与える（16msくらいの遅延を発生させる）には万のオーダーのuseMemoが必要なことが分かります。 速度ではなくuseMemoを使うことによるメモリ消費量の増加を気にする声も聞かれましたが、すみませんが筆者はそこまでメモリクリティカルなアプリをReactで書いたことがなく知見に乏しいため、今回はこの記事の対象外となります。 この結果が出たことでuseMemoをいつ使うのかなどという議論には終止符が打たれたかと思いきや、上記の記事の感想などを見ているとまだ喧々囂々です。 そこで、この記事では筆者の考えを皆さんに共有し、いよいよもってこ
そこのお前！ 余計なuseMemo1個に含まれるオーバーヘッドは余計なdiv 0.57個分だぜ！ - Qiita
※効果には個人差があります。 useMemoのオーバーヘッドについて ReactのuseMemoは、パフォーマンス最適化に使われるAPIです。コンポーネント内で計算やオブジェクトの生成を行う際に、以前の計算結果をキャッシュして使い回すことで再レンダリング時の計算を削減したり、新しいオブジェクトの生成を防ぐことができます。 useMemoに関しては、あくまで最適化のためのものであるから「無駄に使うべきではない」という言説がよく見られます。その理由は、useMemoのコストもゼロではなく、余計な使用はそれだけパフォーマンスの低下に繋がってしまうからです。 しかし、筆者はuseMemoのコストは微々たるものであり、本当に一目見て明らかに無駄でない限りは積極的に使うべきだと思っています。 そこで、筆者はuseMemoのオーバーヘッドがどれくらいかを調べるためのベンチマークを作成しました。この記事で
なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
Uncontrolled Components でシンプル且つ高パフォーマンスなフォームの実装 - React Hook Form - Qiita
Uncontrolled Components でシンプル且つ高パフォーマンスなフォームの実装 - React Hook FormJavaScriptTypeScriptReactreact-hooksreact-hook-form この記事は READYFOR Advent Calendar 2020の13日目の記事です。 はじめに こんにちは。今年の11月から READYFOR でフロントエンドエンジニアとして働いている菅原（@kotarella1110）です！ React と TypeScript が好きで、React Hook Form のメンバーだったりもします。React Hook Form は TypeScript で記述されているのですが、型の改善を中心にコントリビュートしております。 そこで、本記事では React Hook Form に関連した内容をお話しできればと思い
SQL Server / SQL Database パフォーマンスチューニングのための基礎知識 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本投稿について 本投稿は、Microsoft Learn で公開されている、「SQL Server でクエリのパフォーマンスを最適化する 」を確認していた際に、いくつかの情報を補足しながら日本語化したものとなります。 SQL Server / Azure SQL Database のパフォーマンスチューニングには様々な方法があり、「このケースであればこの方法」ということを断定することは難しいのではないでしょうか。 そのため、様々なケースで利用することが可能な、チューニング方法の基礎知識 (一般論) はとても重要です。 本投稿で、確認を行
React.memo / useCallback / useMemo の使い方、使い所を理解してパフォーマンス最適化をする - Qiita
はじめに React（v16.12.0）のReact.memo、useCallback、useMemoの基本的な使い方、使い所に関しての備忘録です。 「React でのパフォーマンス最適化の手段を知りたい」 「なぜReact.memo、useCallback、useMemoを利用するのかわからない」 といった人達向けに書いた記事です。 デモは CodeSandbox 上に置いてあります。編集して動作を確認してみると理解が深まると思います。 本記事で用いている用語 メモ化 計算結果 メモ化 計算結果を保持し、それを再利用する手法のこと。 キャッシュのようなものだとイメージすれば良いと思う。 そのため、以下の言葉の意味は大体同じ。 「メモ化された値」=「計算結果が保持された値」 「メモ化する」=「計算結果を再利用できるように保持する」 メモ化によって都度計算する必要がなくなるため、パフォーマン
Docker for Mac の Mutagen-based caching で Volume のパフォーマンスが劇的に改善した - Qiita
2020/8/23 追記 2.3.5.0 の Edge release で削除されてしまった模様です。 今後の統合方法を検討するということで、続報を期待します。。 Docker for Mac の Edge channel で、 Mutagen ベースのキャッシュが使えるようになっています。(手元のバージョンは 2.3.1.0) 従来、 EC-CUBE をはじめとする Symfony をベースとしたアプリケーションや、Composer や npm などのパッケージ管理システムのファイルをマウントすると、強烈に遅くなる問題がありました。 今回利用できるようになった Mutagen ベースのキャッシュを利用するには、 Preferences -> Resources -> FILE SHAREING でマウントするディレクトリを指定 キャッシュを ON にするだけ。 です。 あとは通常通り、ア
useReducerの本質：良いパフォーマンスのためのロジックとコンポーネント設計 - Qiita
React Hooksの正式リリース（2019年2月）からそろそろ一年が経とうとしています。Hooksの登場によってReactのコンポーネントは関数コンポーネントが一気に主流になり、クラスコンポーネントが新規に作られる機会は激減しました。 また、React 17.x系ではConcurrent Modeの導入とともにさらに2種類の新フックが追加される見込みであり、いよいよ関数コンポーネントの能力がクラスコンポーネントを真に上回る時代が来ることになります。 この記事では、フックの一種であるuseReducerに焦点を当てて、どのようなときにuseReducerが適しているのかを説明します。究極的には、useReducerによって達成できるパフォーマンス改善があり、ときにはそれがコンポーネント設計にまで影響を与えることを指摘します。 useStateの影に隠れたり、なぜかReduxと比較されたり
ブラウザレンダリング入門〜知ることで見える世界〜 - Qiita
はじめに 『レンダリングの仕組みなんて知らなくても、ブラウザが勝手にやってくれるじゃん！』 当時駆け出しのエンジニアだった私はそう思っていました。 実際、当時の私はレンダリングの『レ』の字も知りませんでしたが、特に業務上で問題はありませんでした。 しかし、その時は突然訪れました。 クライアントの要望でアニメーションを多彩に取り入れた案件を実装した際に、テスト段階で一部ブラウザ（S○f○ri、E○ge）でアニメーションがひどい状況になっていることが発覚しました。 (開発中はChromeで確認を行っており、Chromeでは特に問題はなかったので発覚が遅れました。) それからは、狂ったようにパフォーマンスの改善方法をググり、修正する日々が続きました。（最終的には、なんとかマルチブラウザでの動作も担保し、納品まで完了しました。） その案件が落ち着いた後、改めて自分の調べたことを振り返ると、局所的な
たった一行で重いスクロールが軽快に！will-change属性を付けるとFPSが上がる理由 - Qiita
HTMLやCSSのパフォーマンスチューニングを皆さん普段意識されているでしょうか？ フロントエンドはJavaScriptの進化と共にアプリケーションが年々複雑化してきたこともあり、パフォーマンスチューニングのトピックを目にする機会が増えました。 しかしHTMLやCSSも同様にレンダリングの仕組みを少し知り、それに応じた実装することでパフォーマンスを大きく上げることも可能です。 今回は最もシンプルかつ分かりやすい事例として、will-changeプロパティについて紹介したいと思います。 サンプルを使ってFPSを実際に測定してみる 今回はサンプルとして、TwitterのツイートにあたるHTML構造と同じものを4000個縦に並べ、高さ400pxでスクロールできる領域を用意し、スクロール時のFPS(Frame Per Second)を測定してみました。 // この実装は実質たった3行！ const
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Swift 5.1 に導入される Opaque Result Type とは何か - Qiita