ブックマーク / blog.tai2.net (6)

  • Utility-first CSS(Tailwind CSS)が合理的であることの説明と、CSSによるUI開発小史

    目次 CSS小史 SUIT CSS - 命名規約ベースのCSS方法論 styled-components - CSS in JS Tailwind CSS - Utility-first CSS なぜインラインスタイルではダメなのか まとめ タイムライン 参考リンク CSS小史 CSSでアプリのUIを実装するための手法は、これまでいくかの変遷を辿ってきた。 はるか昔、CSSが生まれて間もないころには、関心の分離という文脈から、FONT要素などの物理タグはよくないものとされ、 コンテンツ(HTML)とスタイル(CSS)をきっちりと分離することが奨励されはじめた。 そこでは、HTMLはあくまで文書であり、CSSのクラスセレクタという接点でコンテンツと見た目が隔離されることで、それらは別世界のものとして管理されていた。 また、大規模サービス開発においていかにCSSを管理するかという問題意識はまだ

    Utility-first CSS(Tailwind CSS)が合理的であることの説明と、CSSによるUI開発小史
    l08084
    l08084 2024/03/15
  • 人月の神話

    人月の神話 をひさしぶりに読んでみた。 人月の神話は、フレデリック・ブルックスの超有名古典的エッセイ集で、ソフトウェアエンジニアリングに関する多岐にわたるトピック取り扱っている。その中でもとくに有名で、よく世間で言及されるのは、表題にもなってる「人月の神話」と「銀の弾などない」、それから「セカンドシステム症候群」あたりだろうか。 はじめて読んだのは20年くらい前。社会人になったばかりのころ、満員電車にゆられながら、「へー人を増やしても開発ってうまくいかないのねー」などとわかったような顔をしながら読んでいたのを覚えている。当時は職業プログラマとしての経験を積む前で、を読んでも鵜呑みにすることしかできなかった。でも、熟練のプログラマとして経験を積んだいま読んだら、またなにか違った洞察を得られたりするかもしれない。読み返してみた動機はそんな感じ。 目次 現代のプログラマにとって有益か やっぱり

    人月の神話
  • フリーランスプログラマ雑感

    フリーランスプログラマになって、かれこれ10年近く経ってしまった。 昨日をもって退職しました。今日から(しばらくは)フリーランスとしてがんばります。 — 武藤スナイパーカスタム🔫 (@__tai2__) November 30, 2010 会社を辞めて、とくに深い考えもなくなんとなくフリーランスになった。しばらくすればどこかの会社に就職するのかなあ、きっとそうなんだろうなあ、とかぼんやりと思ってたことを考えると、そのまま10年近くも続けてしまったのは感慨深い。 ぼくにとって、ほかの業種、ほかの立場の人の職業生活がどういうもんなのかわからないのと同程度に、ほかの人にとってもフリーランスプログラマがどういうものか、きっとイメージがあまりわかないんだろう。そこで、フリーランスプログラマ生活を振り返って、それがどのようなものだったのかを思いつくままに語ってみたい。フリーランスプログラマという語は

    フリーランスプログラマ雑感
    l08084
    l08084 2020/08/04
  • クリーンアーキテクチャ(The Clean Architecture翻訳)

    Robert Martin (a.k.a. ボブおじさん) による、 The Clean Architecture の翻訳です。似たようなアーキテクチャである ヘキサゴナルアーキテクチャ も翻訳したので参考にしてください。 この記事を翻訳して公開したことは 8th Light, Inc. に報告済みです。いまのところ苦情は来ていません。 ここ数年以上、システムのアーキテクチャに関する実にさまざまなアイデアを見てきた。これには、次のものが含まれる: Hexagonal Architecture (別名 Ports and Adapters) by Alistair Cockburn。Steve FreemanとNat Pryceが、Growing Object-Oriented Software というすばらしいで採用した。 Onion Architecture by Jeffrey Pa

    クリーンアーキテクチャ(The Clean Architecture翻訳)
    l08084
    l08084 2018/07/09
  • Flux Standard Actionで失敗したアクションを識別する場合は、カスタムエラーオブジェクトを作れば良い

    問題 ReduxなどのFluxアプリケーションの実装では、アクションのフォーマットとして、 Flux Standard Action(FSA) を採用しているプロジェクトも多いと思います。 FSAを使って非同期アクションの結果を表現しようとしているときに、以下のような疑問を抱いたことはないでしょうか? たとえば、TODOアイテムの更新をするアクションとして、UPDATE_TODO:REQUESTED, UPDATE_TODO:RECEIVED という2つのアクションがあるとします。これらは、それぞれHTTPリクエストとレスポンスに対応します。 // リクエスト { type: 'UPDATE_TODO:REQUESTED', payload: { id: 100, text: 'Do something!' } } // レスポンス { type: 'ADD_TODO:RECEIVED',

    Flux Standard Actionで失敗したアクションを識別する場合は、カスタムエラーオブジェクトを作れば良い
    l08084
    l08084 2018/02/17
  • React Redux Real World Examples 〜先人から学ぶReact Reduxの知恵〜

    React Reduxを使ってプロダクトを作りはじめて、かれこれ半年くらい経ちます。 しかし、どうもうまく書けていない気がすることがときどきあり、悩んでいたところ、ツイッターで次のような助言をもらいました。 @__tai2__ 達人かどうかは微妙なところがありますが、ある程度の規模のコードはここにリンク集あります https://t.co/B79B5s1DTe — Yuki Kodama (@kuy) 8 December 2016 この記事は、上記のリンク集でまとめられている実際のReact Reduxプロダクトのソースコードを調査することで、筆者がふだんReact Reduxで開発をしていて感じる疑問への答えを探る試みです。 筆者が答えを得たいと思っている疑問は次の3つです 1 Storeはどんな具合に階層化すべきか Store初期化(hydration)用データの定義はどうすべきか

    React Redux Real World Examples 〜先人から学ぶReact Reduxの知恵〜
    l08084
    l08084 2017/02/23
  • 1