タグ

architectureに関するluccafortのブックマーク (10)

  • 新QiitaでReactをやめてhyperappを採用した背景 - Qiita

    12/1 に Qiita のトップページをリニューアルしました。これまで React を使っていましたが、それをやめて hyperapp を採用しました。まわりを見てもあまり採用事例が見当たらないので、この記事では一体なんで今をときめく React ではなく hyperapp を選択したのか、どういうところが魅力的なのかについて プレゼンテーション層を実装するためのツールとして 学習コスト の観点から書きたいと思います。なおこの記事に書かれていることは全て個人の感想であり、はっきりいって個人の日記レベルです。 それと hyperapp の開発者が社内にいるという事情もあるので、そこら辺さっぴいて読んでください。 TL;DR プレゼンテーション層を実装するためのツールとして React は機能過多だし、機能不足 hyperapp は過不足ない 学習コスト 仮想 DOM は学ぶ価値のある知識

    新QiitaでReactをやめてhyperappを採用した背景 - Qiita
    luccafort
    luccafort 2017/12/28
    Reactがいいhyperappがいいという話ではなくて周辺ツールの変遷が大きいReactからよりシンプルでやりたいことに直接的にアプローチできる方法を取ったという意味合いで受け取ったけど違うの?
  • 技術的負債と向き合う

    オープンセミナー2017@岡山での発表スライドです

    技術的負債と向き合う
    luccafort
    luccafort 2017/05/15
    "技術的負債の問題は組織やシステムに固有のもの"基本的に問題の本質をきちんと把握出来ているか?というその一点が死ぬほど重要なんだよね。資料だとわからないかもだけど生で聞けたときの情報量がすごかった。
  • 無理しないRails

    社内Techカンファレンスで発表した資料です。

    無理しないRails
    luccafort
    luccafort 2017/03/08
    なかなか大変そうな話だった。
  • Redisアプリケーションパターン | おそらくはそれさえも平凡な日々

    この記事は、はてなエンジニアアドベントカレンダー2016の12日目の記事です。 先日こういうツイートをしました。 Redisはキャッシュ用途のミドルウェアだと思わない方が良いと思う — songmu (@songmu) 2016年12月10日 言いたかったのは、Redisはキャッシュのためだけのミドルウェアだと誤解されがちなのですが実際はそうではないということです。実際、公式サイト を見に行くと以下の様なことが書かれています。 Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. つまり、Redisは多彩なデータ構造を保持できるインメモリーのデータストアで、様々な活用法があり、キャッシュとして「も」使える、とい

    Redisアプリケーションパターン | おそらくはそれさえも平凡な日々
  • 綺麗なAPI速習会 - Qiita

    Wantedly Engineer blogに速習会資料を閲覧向けに再編しました! ぜひご覧いただけると幸いです! 記事は、綺麗なAPI速習会@Wantedlyの資料として作成されたものです。 同時にこちらのコードも参照してください。 マイクロサービス 流行りのマイクロサービス、何がいいのか 各々自由な言語やArchitectureでサービスを立てられる 障害の影響が部分的 変化に強い 個別デプロイ etc... マイクロサービス化をすすめるにあたり、やりとりは全てAPIで行う 内部のAPIであっても外部に公開できるようなクオリティのAPIを作成し、それを元にサービスを作っていくことが重要 APIGatewayとBFF API Gateway Pattern 公式サイトより 「見た目はモノリシック、実装はマイクロサービス」 一箇所見に行けば全てのAPIを見つけられる 細かい権限管理も可

    綺麗なAPI速習会 - Qiita
    luccafort
    luccafort 2016/08/06
    そうかGoでAPI用意すればフロントエンドが「鯖立てて欲しいんっすけど…」みたいなやりとりなくなるし、ローカルで叩けるので開発段階初期から中期あたりまでなら良さありそう。
  • Martin Fowler's Bliki in Japanese - 犠牲的アーキテクチャ

    @@ -0,0 +1,37 @@ +http://martinfowler.com/bliki/SacrificialArchitecture.html + + +会議の席であなたは考えている。自分のチームが二年間かけて書いてきたコードのことを。そして決断に至る。いま打てる最善の手は、あのコードをすべて投げ捨てまったく新しいアーキテクチャを再構築することだ。死にゆくコード、それに費やした時間、自分が下し続けてきた判断。この決断は、あなたはどんな気持ちにするだろう? + +多くの人にとって、コードを捨てるのは失敗の証だ。ソフトウェア開発の探索的な性質を考えれば、わからない判断ではないかもしれない。けれど失敗には違いない。 + +ところが、いま書ける最良のコードは二年経ったら捨てるつもりのコードだということはよくある。 + +私たちは長命なソフトウェアとして偉大なコードを思

    Martin Fowler's Bliki in Japanese - 犠牲的アーキテクチャ
  • Rails、あんたなんか嫌いよ - Rails での OO 設計について - tomykaira makes love with codes

    2013-06-25 Rails、あんたなんか嫌いよ - Rails での OO 設計について ruby rails 最近はずっと Rails 書いてるんですが、書けば書くほど嫌いになってくるんです。 倦怠期的なやつなんですが、 Rails さんの悪いところばっかり見えてきて、もう一緒にいたくないんです。 でも別れるほどじゃないし… という愚痴にみせかけた Rails での設計についての議論です。 長いけどコードは一切出てこないので通勤中にでもよんでください。 注意 一部にはげしい言葉遣いがでてくるので、読んで不快になるかもしれません。 不快になったとしても責任は負いかねます。 次のような方の期待に沿う結論はでません。残念でした。 Sinatra, Padrino の人 関数型の人 静的型付けの人 C の人 TL;DR Rails にだまされない。 自分の道を見定める。 欺瞞にみちた Ra

    luccafort
    luccafort 2013/06/26
    ダークサイドに落ちた者のみが称賛しなさい的なタグがなかった…とりあえず言ってること自体は正しいというか至極マトモだた。最後のほうが若干同意できないけど。
  • 効果絶大!重文をふん害から防いだピンクの… : 文化 : 社会 : YOMIURI ONLINE(読売新聞)

    福岡県大川市と佐賀市を結ぶ国指定重要文化財・筑後川昇開橋(全長507メートル)で、野鳥のふんだらけになって悩みのタネだった手すりが、橋を管理する財団職員のちょっとしたアイデアで美観を誇るようになっている。 鳥を寄せ付けなくなった強力な武器は、長さ500メートルで500円もしないという工事用のナイロン糸。橋は現在修理中で、16日の通行再開を前に財団関係者は「これで安心して観光客を迎えられる」と喜んでいる。 昇開橋の一帯は、付近を飛び交うサギやカモメなどの野鳥が羽を休めるため、アルミ製の手すり(高さ1・2メートル、幅12センチ)がふんで汚れ放題だった。国の重要文化財に指定された2003年から、橋を管理する筑後川昇開橋観光財団の職員がたわしとぞうきんで毎日拭いていた。2人で1~2時間かかる重労働で、大きな負担になっていた。 財団では対策として、鳥が嫌う塗料や太陽光を反射するCD、針状の鳥よけなど

    luccafort
    luccafort 2013/06/10
    ビフォーアフターがないとどれくらい効果でたかわかんなくね?
  • 「これからのWeb(バックエンド)」を自分の頭で考えてみた - As a Futurist...

    ふと今更、年初のCROSS 2013の「次世代 web セッション」の動画を見て、うんうん唸ってしまった。プロトコル編の方は知識不足であんまり分からなかったですが、アーキテクチャ編の方はグサグサくるものがあった。「自分の頭でこれからの web を考えてブログに書くまでがこのセッション」という宿題が出ていたので、せっかくなので最近考えてることをつらつらと書いておこうと思った次第。特にまとまりはないですし、戯言です。 これからの Web の話をしよう。 (次世代 Web セッション @ CROSS2013) – Block Rockin’ Codes 前提 僕はコード書いてない&サーバサイドしか見たことない&WEB サーバはあんまり見たこと無くて、それより後ろ側ばっかり見てた人なので、ユーザ側とかアプリ開発者がどうなっていくかについて特に尖った意見はありません orz SPDY とかもまだ手を

    「これからのWeb(バックエンド)」を自分の頭で考えてみた - As a Futurist...
    luccafort
    luccafort 2013/05/30
    後で読む。なんか今日は長文エントリが多い気がする。
  • Instagram のスケール正攻法 -- Kosei Kitahara's Blog

    Instagram がどこに買収されたとかは他のニュースサイトにお任せして、Django アプリケーションを正攻法でスケールして "成功" してるのがとても興味深いです。現時点で Instagram Engineering で紹介されていることと TechCrunch にも掲載されたスライドから個人的なメモとしてまとめてみました。 Instagram の哲学は シンプルであること オペレーション負荷を最小化すること すべて装備 とのこと。 Instagram は以下の OSS, サービスで構築されているようです。 >>> OS / ホスティング Ubuntu Linux 11.04 を Amazon EC2 にホスティング。以前のバージョンは高トラフィックになると固まる問題があったようです。運用は 3 人。EC2 にホスティングしている理由は、調査結果によるものではなく、"まだ進化途中だか

  • 1