28. 技術選定の審美眼(1) w/ twada | fukabori.fm
話したネタ Worse Is Better - 過去を知り、未来に備える。技術選定の審美眼 2019 edition フロントエンド疲れとは？ 大筋でのトレンドは変わってないが、目が養われていないと疲れてしまう Gruntとgulp.js、ReactとVue.js イメージ的には選球眼 変わるもの、変わらないものを見極めるモチベーションは何か？ 技術の世界は変化が緩やかで手堅い部分と変化が激しい部分がある 振子のように見えていた変化は、角度を変えて見れば螺旋であり、その差分を見るのが大事 ベテランエンジニアの唯一のアドバンテージとは？ プログラマとしての可処分時間はどんどん減っていく ベテランプログラマに求められる役割としての、語り部と老害のボーダライン Unix哲学 小さいのは良いことだ(Small is beautiful) 一つのことを上手くやる(Make each program
アプリケーションにおける権限設計の課題 - kenfdev’s blog
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
Goodbye, Clean Code — Overreacted
It was a late evening. My colleague has just checked in the code that they’ve been writing all week. We were working on a graphics editor canvas, and they implemented the ability to resize shapes like rectangles and ovals by dragging small handles at their edges. The code worked. But it was repetitive. Each shape (such as a rectangle or an oval) had a different set of handles, and dragging each ha
GoF デザインパターン チートシート - Qiita
ここまで読んでくださった皆さんに、ちょっとしたクリスマスプレゼント。マンガでわかる GoF デザインパターン 23 種チートシートです。これでもうデザインパターンは完全にマスターしましたよ。やったね! (注: ここからはあとがきポエムです) ところでみなさん、せっかくデザインパターンを学んだので、これを使ってプログラムを書こう、チートシートがあるからなんでも書けそうだぞ、なんて思っていませんか。ダメですよ。そんなことしたら 2000 年前後に起きた失敗を繰り返してしまいます。 実は GoF のデザインパターンは、ビジネス的には成功したけど、教育には失敗しました。最初に出版された本に「オブジェクト指向における再利用のための」という肩書が付いていましたが、これが本当に良くなかった。 あの頃 (ポール・グレアムが LISP と Ruby を褒めるまで) は、「オブジェクト指向様こそが良い設計のす
MVCとはなにか｜tenjuu99
この記事は、2019年12月1日に開催されたPHPカンファレンスでの「MVCとはなにか」という題の登壇内容の書き起こしです。スライドはこちらです。 1. はじめに MVCの悪かった点は、わたしたちがどう実装したかという点だ。それはあまりに機械的だった。 https://news.ycombinator.com/item?id=8841428 ある人がアラン・ケイに対して「MVCについてどう思うか」という質問をして、それに対するメールでの回答がHacker Newsというサイトにのっていました。前提をお話すると、MVCというアイデアは、だいたい40年以上まえにパロアルト研究所というところで、アラン・ケイがパーソナルコンピュータの開発をしていたときに、客員研究員としてトリグヴェ・リーンスカウクさんという人が訪れて、そのとき他の研究所のメンバーとも話あって作ったアイデアがMVCになります。 MV
様々なrate limitアルゴリズム - Carpe Diem
概要 インターネットに晒されているWebサービスでは TV等で紹介されたことによる大量流入 悪意ある人物からの攻撃 クライアントのバグに依る大量リクエスト など、本来想定していた以上のトラフィックが来ることはよくあります。 単純にシステムを構築すると大規模トラフィックに対応できずシステムがスローダウンしてしまうため、何かしらrate limitをかけておいた方が良いです。 ただしrate limitと一口に入っても色々あるため、今回は主なrate limitアルゴリズムを紹介します。 Leaky bucket Leaky bucketはデータ転送レートを一定にする（＝上限を設定する）アルゴリズムです。 下の図のように、様々な流量の水流がそのバケツに流れ込んでも小さな穴からは一定の水流が流れ出す仕組みです。 ref: What is the difference between token
ミノ駆動 on Twitter: "クソコード動画「共通化の罠」 https://t.co/MM750CNXc2"
クソコード動画「共通化の罠」 https://t.co/MM750CNXc2
概念に触れることから、創造性は生まれる——OOUIの目当て #WIAD2019｜designing
2019年2月23日、Information Architecture Instituteが主催する、『World IA Day（WIAD）』が開催された。本イベントは、情報アーキテクチャ（以下、IA）の観点から情報のあらゆる場面における課題の発見と定義、考察や議論の深化を目指す。 2019年は「IA in IxD（インタラクションデザインにおけるIA）」をテーマに、オブジェクト指向UI設計（Object Oriented User Interface、以下OOUI）とUIデザインの関係についての考察と議論がなされた。 イベントのメイントークでは、OOUIに造詣の深いソシオメディア取締役の上野学氏が登壇。『OOUIの目当て』と題し、「オブジェクトとは何か？」を問うところから始まり、OOUIと非OOUI的なUIの裏側の違いや、その目的について語った。 本記事では、上野氏がイベントで話した言葉
新雑誌「n月刊ラムダノート」の『「コルーチン」とは何だったのか？』の草稿を公開します - まめめも
『Ruby でつくる Ruby』などでお世話になっているラムダノートが、新しい雑誌「n月刊ラムダノート」を創刊しました。 www.lambdanote.com コンピュータ関係の技術情報の記事だけが載るそうです。創刊号は、『TCPの再送制御機構』、『「コルーチン」とは何だったのか？』、『MLOpsの歩き方』、の 3 本です。 『TCP の再送制御機構』は、パケットを送ってから返事が来るまでの RTT (Round-Trip Time) を計測する方法や、RTT を使った再送のアルゴリズムや、RTT を使わない再送のアルゴリズムなど、TCP の再送に関する仕様・実装の歴史から最新提案までを、日本語話者の中では間違いなく世界一詳しい第一人者である西田佳史さん（@nsd）が広く深く紹介しています。 『「コルーチン」とは何だったのか？』は、ぼくが書きました。伝統的なコルーチンの説明から、JavaS
ドメイン駆動設計を理解する３つのキーワード - ソフトウェア設計を考える
ドメイン駆動設計との出会い １０年前に、エヴァンスのドメイン駆動設計を初めて読んだ時は、書いてある内容がほとんど理解できなかった。 あまり、面白いとも思わなかった。 当時は、現場でバグだらけのコードと格闘していた。障害が報告されるたびに、リファクタリング本を参考に、該当個所の長いメソッドや大きなクラスを片端からリファクタリング。その結果、コードがわかりやすくなり、やっかいなバグが単純な修正で解消できてしまうことの効果に驚き、設計の重要性を再認識していた。 それ以前は、UNIXとC言語、OracleとPL/SQLという、オブジェクト指向ではない世界で技術を身に着けてきた。 どちらかというとオブジェクト指向には、ネガティブな印象を持っていた。現場では役に立たんだろうと。 バグとの格闘の中で、リファクタリング（設計改善）の威力を肌で感じ、その考え方とやり方がオブジェクト指向に由来するということを
クライアントとサーバーどちらに実装するかの設計指針をチームで持つこと - tomoima525's blog
モバイルアプリケーションを開発していると、この要件や仕様はクライアントとサーバーどちらに置くべきか、という議論がチームでなされることがしばしばあります。例えば、 あるレスポンスAを受けて処理Bを行い、その結果をユーザーに提示する 登録処理などで、処理C,処理Dという異なる処理を並列して行い、それらが完了したらユーザー側に通知する やろうと思えばクライアント側で処理を全て持つこともできますし、サーバー側で実装もできますね。 このような仕様のディスカッションが起きたとき、チームで統一した判断基準を持っていますか? 自分の場合、クライアントアプリはロジックをなるべくサーバーに移譲すべき という設計指針をチームに提案します。 上の例で言うならば、 サーバーから処理Bも踏まえたレスポンスA'を返してもらい、ユーザーに提示する クライアントは1リクエストをサーバーに投げる。サーバー側で処理C,Dを投げ
ヤフー株式会社におけるWebフロントエンドの技術選定 - Yahoo! JAPAN Tech Blog
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog Yahoo! JAPAN Tech Advent Calendar 2018の6日目を担当します、Webフロントエンドエンジニアをやっている向井(@sakito)です！ 今回はヤフー株式会社でWebフロントエンドエンジニアがどのような取り組みを行なっているのかをお伝えします。 ヤフーの組織体制 Webフロントエンドエンジニアの取り組みを紹介する前に、ヤフーがどのような組織体制なのか紹介します。 冒頭画像のようにヤフーではカンパニー制度を取り入れており、それぞれのカンパニーにサービスを開発する事業本部があり、この事業本部単位でデザイナーやエンジニア、そのほかにもさまざまな職種の方が所属し、サービスごとで日々開発に取り組んでいます。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Building a newbie-friendly codebase
The Ship of Theseus to NOT rewrite a legacy system from scratch
オブジェクト指向のその前に-凝集度と結合度/Coheision-Coupling
めんどうくさいゲームセキュリティ
Repositoryによる抽象化の理想と現実/Ideal and reality of abstraction by Repository
入門 名前
設計ガイドライン
コードをどまんなかに据えた設計アプローチ - Speaker Deck
