認知負荷および認知負荷理論 (Cognitive Load Theory) をもう少し正確に理解するための心理学研究・知見の紹介
認知負荷および認知負荷理論 (Cognitive Load Theory) をもう少し正確に理解するための心理学研究・知見の紹介 この記事の目的 ここ数年で、ソフトウェア開発やプログラミングの文脈で、「認知負荷」 および 「認知負荷理論」 という用語をよく見聞きするようになりました。私が今思い出せるだけでも、以下のような書籍や Podcast で重要なキーワードとして取り上げられています。 A Philosophy of Software Design, 2nd Edition チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ fukabori.fm 102. A Philosophy of Software Design (3/3) w/ twada この「認知負荷」ですが、少なくとも近年見聞
Engineering Career Ladderを作るときに気をつけたこと 其の一 - LayerX エンジニアブログ
この記事はLayerXテックアドカレ2023の4日目の記事です。 昨日は@shun_takさんが「バクラクのデータは難しくて面白い」を書いてくれました。 明日は機械学習チームのyakipuさんの記事が公開予定となっています。楽しみですね！ こんにちは、すべての経済活動をデジタル化し、ハタラクをバクラクにしたいmakogaです。 私のチームであるEngineering Officeは「人とチームの観点からエンジニアリング組織のパフォーマンスを最大化する」というミッションを持ち、組織の仕組みの設計や運用改善を行っています。その1つにEngineering Career Ladder*1の策定があり、10月から一部のRoleで仮運用を開始しています。 Engineering Career Ladderは上手に運用すれば強力なツールとなりますが、下手をすると生産性の悪化や成長の妨げになる可能性があ
『B/43 Tech Talk 〜 Fintech×サブスクリプションサービス立ち上げの裏側〜』を開催します - inSmartBank
こんにちは！本記事は弊社が2023-08-03に開催するオンラインイベント『B/43 Tech Talk 〜 Fintech×サブスクリプションサービス立ち上げの裏側〜』の紹介をします。単なる概要紹介では味気ないので、イベントの見どころが伝わるように解説していきます。 smartbank.connpass.com B/43のサブスクリプションサービスとは？ 弊社スマートバンクはVisaプリペイドカードと家計簿アプリがセットになった新しい家計管理サービス「B/43」を提供しています。登録いただいたユーザーにカードを発行し、カードで決済を行うとアプリ上でリアルタイムに明細が見られる、という手間いらずの支出管理ができるサービスです。 2023年7月12日、B/43をコアに使っていただいているユーザーの声をもとに、新たにサブスクリプションサービス「B/43プラス」をリリースしました 🎉 b43.
Two Person Teams
← all episodes Listen now If you’ve been following along with the podcast, you’ve heard the mention of two-person teams and how 37signals makes the most of its software features and productivity with just two people working together—one programmer and one designer. In this episode of the Rework podcast, 37signals co-founders Jason Fried and David Heinemeier Hansson sit down with Kimberly Rhodes to
ソフトウェア工学を学びにアメリカへ - pco2699’s blog
はじめに お世話になった方々への謝辞 参考にしたブログ・その作者の方への謝辞 私のスペック なぜ米国大学院を志したのか まとまった時間でCS、エンジニアリングの勉強をしたかった 英語で学ぶという経験をしたかった アメリカで働いてみたかった ソフトウェア工学修士とは何か 計算機科学修士とソフトウェア工学修士の違い 大学院の選び方 専攻 何を専攻するか 研究するか？しないか？ 授業料 おわりに Appendix: そのほか参考になる記事 はじめに こんにちは、一昨年からアメリカの大学院への入学を目指し勉強してきました。 結果、アメリカのピッツバーグにあるカーネギーメロン大学のソフトウェア工学修士課程（Master of Software Engineering）から合格通知をいただき、今年の8月からアメリカに行くことになりました。 合格通知をいただいたのは昨年の3月なのですが、仕事や家庭の事情
2022年におけるフロントエンド開発のベースライン
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog TL;DR:2022にフロントエンド開発で最も考慮すべきユーザー環境は、パフォーマンスでは低スペックのAndroid端末、標準仕様では2年前のSafari、そしてネットワークでは４Gです。それに対してはJSへの過剰依存などが原因で主にパフォーマンスの面でのウェブ全体の対応がよくありません。 こんにちは！LINEフロントエンド開発室のダバロス アランです。この記事のタイトルを見て「釣りタイトルですね〜」と考えている方がいると思いますが今回に限ってはそれを大目に見てください。それはなぜかと言いますと、2021年から2022年にかけて私たちフロントエンドエンジニアが全体的に考え方を改める必要が出るほど大きな変化がありました。 その変
踏み台EC2を廃止してSession Manager接続に置き換えました
こんにちは、エウレカ SRE チームの原田です。 今年 (2021年) エウレカでは、公開鍵認証で接続するEC2の踏み台サーバを廃止し、代わりに各サーバへの接続をIAMで認証できるSSM Session Managerへのリプレースを行いました。本記事ではそのモチベーションや、実装のポイントを紹介していきたいと思います。 旧来の踏み台サーバ 旧来の踏み台サーバエウレカで長く運用されていた踏み台サーバ (Gateway) は以下のようなものでした。 各開発者は、自分の秘密鍵を使って踏み台サーバへSSHを行う ( 踏み台サーバ上には各開発者の個別ユーザーおよび公開鍵が登録されている )踏み台上では、接続が許可されているSSH対象のサーバの秘密鍵がユーザー毎に配置されており、その鍵で各サーバにSSHするMySQL / Elasticsearch / Redis など、Private Subnet
レイテンシーを計算する技術の話 - LINE ENGINEERING
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog こんにちは、LINEメッセンジャーのサーバーサイドとモニタリングプラットフォームの開発を担当しているフィ（@dxhuy）です。この記事はLINE Advent Calendar 2017の20日目の記事です。 今日は、モニタリングシステムでよく使うレイテンシーやその計算方法などについて紹介したいと思います。LINEでは、日々ユーザが楽しくメッセージを送れるように、システムの安定性を第一に考えています。安定したシステムを保つためにたくさんの指標を見守る必要がありますが、その指標の1つが「レイテンシー」です。 ウィキペディアでは、レイテンシーは以下のように定義されています。 デバイスに対してデータ転送などを要求してから、その結果が
質の高い技術文書を書く方法 - As a Futurist...
大学や大学院で論文の書き方を鍛え上げた人たちには遠く遠く及ばないが、僕の様なはぐれもの1でも最近は Amazon 社内で文書の質が高いと評価してもらえるまでにはなった。Software Engineer として、コードでのアウトプットはもちろん大事だけど、文書のアウトプット(およびそれによって得られた実際のアウトプット)は同じだけ重要である2。今回は自分が最近どういうところに気をつけて技術文書を書いているのか、ということについて数年後の自分が忘れてないことを確かめられる様にまとめておく。 そもそも文書とは？ 英語だと document。ここで指す(技術)文書とは、人間が読む文体で書かれた技術に関連する情報、といったものだ。具体的に言うと以下の様なものを想定している: 新しいプロジェクトの骨子を説明する資料 会議の叩き台となる 1 枚ペラ 本番環境に変更を加えるにあたっての包括的な情報や具体
Engineering Manager になってから身に沁みた12のアイデアと言葉 part2 - これはただの日記
2019/12 にこんな記事を書きました。 kths.hatenablog.com あれから一年たち、日々積み上げた新しいアイデアをみなさんとも共有したいと思います。 システム操作性スコア 私が勤めるスタディストでは、一部のサービスがマイクロサービスとして稼働しています。また、それ以外にも稼働している別プロダクトがあったりと、徐々に組織の管理対象となるサービスの数が増えつつあります。また、今後もその数は増加していくことが予想できます。 2020/12/26に発売されたばかりの書籍『モノリスからマイクロサービスへ』では、マイクロサービスが引き起こす可能性のある痛みの一例として、孤児サービスという言葉が登場します。これは文字通り、所有権や責任を負う人がいなくなってしまったサービスのことで、孤児サービスに対するトラブルシューティングは困難になることが予想されます。単に一部機能の停止で済めばマシで
Webアプリケーションのログに関するいくつかの考察 - Hatena Developer Blog
こんにちは、はてなでWebアプリケーションエンジニアをやっている id:polamjag です。 最近のはてなでは、若手エンジニアを中心として、いろいろな技術を見つめ直すワーキンググループをやっています。先日、id:onk も「デプロイ今昔」という記事を書きましたが、このエントリーはそのシリーズの続きで、ワーキンググループの「ログ」の回で議論したこと・話題になったことをまとめました。 Web開発におけるログを見つめ直す ログを4つの目的で分類する 目的ごとに求められる取り扱いの要求水準 いまどきのログフォーマットについて まとめ：どう実装するかを模索していく Web開発におけるログを見つめ直す Webサービス（Webアプリケーション）の運用には、多種多様なログがついてまわります。多くのミドルウェアは何もしなくてもそれなりの量のログを出力しますし、クラウド上のマネージドサービスも然りです。行
Webサービスの障害対応のときの思考過程 - ぱいぱいにっき
起こってほしくはないのですが、あらゆるWebサービスは完璧に動作する状態を維持することは難しく、やはり障害対応・トラブルシューティングといった作業が発生します。 筆者は普段仕事で障害対応を不幸なことによくやるのですが、障害対応のスキルというのはスピードや判断の正確さが求められるせいか、今までやったことがある人・ノウハウがある人に集中し、それ以外の人は眺めるだけ・あとからログを見返すだけの状態によく陥ることがあります。 これはWebサービスを開発・運用するチームとしてみたときにそういった苦労が特定の人に集中するのは良くないので、それを緩和する目的として、筆者が障害対応時に考えていることを記述してみます。なお、これが唯一の正解ではないとは思っているので、ツッコミや、自分はこう考えているよというのを教えていただければ幸いです。 具体的な手法を避けて思考の方法を述べているのは、障害というのはパター
モノリス分割はこうやる！「How to break a Monolith into Microservices」を読んだ - kakakakakku blog
研修中に「マイクロサービス」の解説をしていると，たまに「モノリス分割」に関する質問が出てディスカッションをすることがある．当然ながら万能な分割アプローチはないけど，例えば DDD (Domain-driven design) などのアプローチを選択するなど，選択肢はいろいろある．そして最近「モノリス分割」に役立つアプローチを紹介した martinfowler.com の記事「How to break a Monolith into Microservices」を読んだ． 具体的には以下の「計8種類」のアプローチが紹介されている．原著を翻訳するのではなく，あくまで個人的なメモとしてまとめる．なお，日本語も個人的に載せているため，参考程度にしてもらればと！ Warm Up with a Simple and Fairly Decoupled Capability（シンプルかつ分離された機能で準
継続的なソフトウェア・アップデートのためのDevOpsベストプラクティス・アンチパターン / DevOps Patterns and Antipatterns for Continuous Software Updates
Cloud Native Days Tokyo 2020
業務知識と計算機科学の知識 - 発声練習
aikeの日記：スーパークリエイターがSI業界で即戦力になれない理由 この記事の企業側の発言で「コンピュータ・サイエンスの学科を増やさないと問題は解決しない」というのがあったが、これは嘘だ。SI業界に限っていうと、仕事で必要になるコンピュータ･サイエンスの知識量は大したものではない。本当に必要なのはいわゆる「業務知識」と、それを通常どのようにコンピュータで実現するかという知識だ。 そもそもプログラミングとは目的ではなく手段だ。だから何かシステムを開発する場合、手段（プログラミング）だけでなく、目的にも詳しくなくてはならない。SI業界だと分かりにくいのであれば、たとえばＣＧ作成ツールの開発会社に、グラフィックやモデリング、ベクトル計算にはまったく知識のない天才プログラマーが入ったとしたらどうか？ あるいは今まで一回もゲームをやったことがないスーパークリエイターがゲームソフト開発会社に入ったと
2019年SRE考 - ゆううきブログ
この記事では、自分が数年Site Reliability Engineering (SRE)を実践しつつ、SREについて考えてきたことをまとめる。 先月開催されたMackerel Drink Up #8 Tokyoと先日開催された次世代Webカンファレンス 2019では、SREについて集中的に議論する機会に恵まれたため、脳内メモリにキャッシュされているうちに、SREに関する私的な論考をまとめておく。 (以降では、SRE本の原著にならい、技術領域名を指すときはSRE、職種名を指すときにSREsと表記する。) SREとの関わり なぜSREに関心をもったのか 2015年にメルカリさんがSREチームを発足したときに、SREsの存在を知り、SREsはシステム管理者、Webオペレーションエンジニア、インフラエンジニアといった既存の職種を置き換えていくものだと理解した。 当時、自分が注目したのは、SRE
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サブスクリプションサービスをつくる時にエンジニアが考えること / Behind the Scenes: Engineering a Subscription Service
DB外の副作用をトランザクションから分離しよう / Isolate out-of-DB side effects from transactions
Engineering Ladder | メルカリエンジニアリング
ストレージの基礎
