タグ

2017年7月5日のブックマーク (6件)

  • 「Open Source Friday」をGitHubが提唱。金曜日は自分の好きなオープンソースに貢献しよう - Publickey

    「Open Source Friday」をGitHubが提唱。金曜日は自分の好きなオープンソースに貢献しよう これはもともとGitHub社内で行われていた運動を広げ、誰でも参加しやすいようにしたもの。 下記はOpen Source Fridayの提唱を紹介する同社ブログの記事「Contribute on Open Source Friday · GitHub」からの引用です。 Over the last three years, we've encouraged GitHub employees to take time at least every fourth Friday to work on open source and share what we're working on with each other. Open Source Friday has grown from t

    「Open Source Friday」をGitHubが提唱。金曜日は自分の好きなオープンソースに貢献しよう - Publickey
    t-wada
    t-wada 2017/07/05
    これは良い金曜日の使い方
  • 2017年のformの話

    teppeis_sushi でした。てっぺーさん、おめでとう。

    2017年のformの話
    t-wada
    t-wada 2017/07/05
    セオリーから言うと Ephemeral な状態は React の state を使うべきだが、管理上は Redux の state に寄せた方が便利で、その上でパフォーマンス上必要なバッファとして React の state を使う。現場感があって良い。
  • #teppeis_sushi でクライアントサイドDDDについて発表した

    #teppeis_sushiというイベントで、Faao - ドメイン駆動設計で作るGitHub Issue Client -という話をしました。 Electronやブラウザなどで動くfaaoというGitHubクライアントを書いていてそれの技術的な話です。 クライアントサイドでDDDを取り入れた設計になっていて、その設計や規約の作り方やそれを守る方法についての話をしました。 azu/faao: Faao is a GitHub issue/pull-request client on Electron. Living Documentation by design, with Domain-Driven Design by Cyrille Martraire [PDF/iPad/Kindle]という無料から買える書籍では、ドキュメントとコードを同じ速度で成長させていくためにはドキュメントに対

    #teppeis_sushi でクライアントサイドDDDについて発表した
    t-wada
    t-wada 2017/07/05
    良い sushi でした。私は翻訳された技術書を読む際の注意点を LT しました。
  • ES Class Fieldsのプライベートフィールドがハッシュな変態記法なのは何でなんだぜ?

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    ES Class Fieldsのプライベートフィールドがハッシュな変態記法なのは何でなんだぜ?
    t-wada
    t-wada 2017/07/05
    "encapsulationをゴールとする場合、後方互換性、他の仕様との整合性、実装時のパフォーマンスを考慮すると、ほぼ消去法的にthis.#fooしかないという結論" ASI hazard なあ……
  • マイクロサービスはもう十分 | プロダクト・サービス | POSTD

    モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。要旨 モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。 – Martin Fowler 明確に構造化されたモノリスを構築できない時、なぜマイクロサービスがその答えだと思うのか。 Simon Brown 始めに マイクロサービスの利点と欠

    マイクロサービスはもう十分 | プロダクト・サービス | POSTD
    t-wada
    t-wada 2017/07/05
    "非干渉化と分散を混同してはいけません" "現行システムに対して迅速にプロビジョニング、デプロイ、モニタリングする能力がないなら、マイクロサービスへの移行を検討する前にその能力を獲得しなくてはなりません"
  • ソフトウェアの世界での slug / スラグ / スラッグの意味 - valid,invalid

    かつての自分と全く同じ気持ちを持った質問者によるurl - What is the etymology of 'slug'? - Stack Overflow('slug' の語源は?)が気に入ったので抄訳。 python - What is a "slug" in Django? - Stack Overflowよりも質問の仕方が良い。 ちなみに今の自分が「'slug' ってなに?」と聞かれて説明するなら「ヒューマンリーダブルな ID」あたりが妥当な回答だろうか。 Q: ‘slug’ の語源は? ‘slug’ は特筆すべき理由のない言葉なのか、それともやはり何らかの意味がある言葉なのでしょうか?あるとき私は会話の中でこの言葉を使用したのですが、「なぜ ‘slug’ って呼ばれているのか」と聞かれたときに私も意味を理解してないと気づきました。 もちろんそれがどのように使われているかは知って

    ソフトウェアの世界での slug / スラグ / スラッグの意味 - valid,invalid
    t-wada
    t-wada 2017/07/05
    "Q: slugの語源は? A: 由来は新聞業界です" "記事が担当記者(もしくはそれ以前)から編集者を経て印刷機に至るまでの道のりでの呼び名です"