どの「時間帯」に行動するかによって、意思決定とパフォーマンスは大きく変わる | 意思決定｜DIAMOND ハーバード・ビジネス・レビュー
また、時間帯は成績にも影響を与えうる。デンマーク社会調査研究センターのハンス・ヘンリク・シーバートセン、コペンハーゲン大学のマルコ・ピオベザンと私は研究で、1日の時間帯が学生の学業成績に影響することを明らかにした（英語論文）。利用したデータは、デンマークの公立学校に通う8～15歳の全生徒による、2009～10年と2012～13年の学年度におけるテストの成績だ。この200万を超えるデータポイントをサンプルとして、1日の時間帯と休憩が標準テストの成績に与える影響を測定した。すると我々の予測どおり、認知疲労によって成績は低下し、休憩によって生徒たちは活力を取り戻していた。 具体的には、分析から次の3点が明らかになった。 1．テストを実施した時間帯が遅いほど、生徒の成績は低かった。 2．休憩によって成績は著しく改善した。 3．1日の時間帯と休憩による影響は、一様ではなかった。つまり、成績が芳しくな
どの「時間帯」に行動するかによって、意思決定とパフォーマンスは大きく変わる | 意思決定｜DIAMOND ハーバード・ビジネス・レビュー
1日の時間が進むにつれて疲労が溜まっていくのは当然の現象だが、それが医師による薬の処方や、判事の判決にも影響するという恐ろしい研究結果が示された。時間管理と休憩の重要性が浮き彫りになる。 出社すると、いつものように、仕上げなければならない仕事が山積している。同僚に共同プロジェクトの件で折り返し連絡。急を要するメールの送信。あの重要な勤務評価を完了しなくてはならない。こちらのプロジェクトを進展させ、別の案件の今後の工程を決めなくては……「To Do（やること）リスト」に取り組むための、最良の策はいったい何だろうか。 さまざまな作業を整理するために、あなたは独自の戦略を編み出しているかもしれない。だが大半の人々と同様であれば、それぞれの作業に取り組むべき「最良の時間帯」がいつであるかについては、あまり考えていないのではないだろうか。 しかし、考えるべきである。なぜなら最近の研究が示すところによ
Ruby 3.3.0+YJIT本番運用カンパニーになりました - Timee Product Team Blog
こんにちは。バックエンドエンジニアの須貝（@sugaishun）です。 今回はタイミーが本番運用しているRailsアプリケーションに対してRuby3.3.0へのアップデートを行った（YJITは引き続き有効なまま）のでその結果をご紹介したいと思います。 昨年弊社のid:euglena1215が書いたエントリーのRuby3.3.0版です。 tech.timee.co.jp 前提 タイミーのWebアプリケーションとしての特性は基本的には昨年と変わりありません。ですので、昨年の内容をそのまま引用させてもらいます。 タイミーを支えるバックエンドの Web API は多くのケースで Ruby の実行よりも DB がボトルネックの一般的な Rails アプリケーションです。JSON への serialize は active_model_serializers を利用しています。 今回の集計では API
Ruby の JSON ライブラリ Oj のパフォーマンス改善を行いました - Repro Tech Blog
Development Division/Repro Team/Feature 1 Unit の Watsonです。Feature 1 Unit は Repro Tool の機能開発と保守を担っています。 弊社でも利用している Oj gem のパフォーマンス改善 PR を送った話と、その PR の内容について共有します。 ことのはじまり 以前、同僚が Ruby on Rails で JSON を返す REST API を作成した際、JSON のエンコード部分のパフォーマンス計測をしていました。JSON のエンコード方法は JSON.generate、ActiveSupport::JSON.encode、Oj gem を利用する方法など色々ありますが、私としては Oj gemの ほうがパフォーマンス的にいいだろうからそちらを利用したほうが良いのではと思っておりました。 計測結果を拝見したら確
Railsをやめても解決しない問題
序文 昨年末くらいからRailsとフルスタックJavascriptの論争の記事がよくバズってましたね。主にORMとパフォーマンスやSPAが論点として多かった気がします。 Rails側のSPA作りづらい問題に対し、hotwireが一つの解として今後どういう受け入れ方をされて行くのか、どう発展していくのかは気になるところです。 未来のフルスタックフレームワークの代表争い さてこの論争、僕は「未来のフルスタックフレームワークの代表争い」だと思っているのですが、結構難しくって視点次第でどうとでもなっちゃうような気がしてます。 というのもこの手の技術選定の問題ってアプリケーション規模やチームの思考、求められるサイト特性などによって合う合わないがあるので、一概に正解がわからないんですよね。 例えば今勉強がてらブログを作ってみたい、という人には迷わず僕はblitz やNext/Gatsby＋外部サービス
Rails appをRubyコードの改善だけで50%以上高速にした話 - Money Forward Developers Blog
この記事は Money Forward Engineering 2 Advent Calendar 2022 18日目の投稿です。 こんにちは。マネーフォワード関西開発拠点でマネーフォワード クラウド会計Plus (以下会計Plus)のエンジニアをしているぽっけです。 この記事では、私が行った高速化について紹介します。 私は最近Railsアプリケーションの高速化を行っており、ある画面のレスポンスタイムを50%以上削減しました。そしてこの改善はRubyレベルの変更のみで達成しました。 この記事での「Rubyレベルの変更のみ」は、MySQLやRedis、Web APIなどへのアクセスには全く手を入れず、Rubyのプロセスが消費する時間のみを変更した、ということを意図しています。 MySQLなどへのアクセスは通常ボトルネックになりがちな箇所です。今回そこに手を入れずに高速化を達成できたのは、1つ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
