マンガメディア開発チームの id:mizdra です。半年ほど前から「フロントエンドエキスパート」という肩書きをもらい、社内でフロントエンドの啓蒙活動をしています。具体的にどんな活動をしているかについては、社内のポッドキャストで少し話しましたので、興味があれば聞いてみてください。 developer.hatenastaff.com 最近、私はReactを採用する社内プロダクトでのCSSの書き方を検討していました。最終的にそのプロダクトでは、CSS Modulesを採用するに至りました。しかしその過程で、CSS Modulesのメンテナンス体制に対して懸念があり、将来的な存続を危ぶむ声が界隈にあることを知りました。 ただし、実際にメンテナンス体制について調べてみたところ、万全ではないものの引き続きメンテナンスがされていて、使用もできることが分かりました。そこで、今回はCSS Modulesに

powershell-gives-you-wrongs.md PowerShell Gives You Wrongs 三年半の格闘の末に僕が見たもの、あるいは試行錯誤の覚書、すなわち二番煎じ。 はじめに PowerShell 3.0以上のバージョンを使用すること。2.0以下のバージョンは、書き捨ては仕方ないとしても、保守対象のスクリプトを書くべきではないし、あらゆる言及に値しない。全力でバージョンアップをしろ。 式と文の常識を超えて PowerShellで、いわゆる三項演算子いうところの条件演算子を書きたい、と思ったところで、そもそもif文が値を返すことに気づく。 > $answer = if($true){"good"}else{"bad"} > $answer good しかし、if は文であって式でない。代入文の右辺には文が置けるので上記は問題ないが、当然、式を置くべきところに文は置

睡眠は大切とよく言われますが、睡眠不足が開発者に与える影響をまじめに調べた面白い論文が、ソフトウェア工学のトップ論文誌 IEEE Transactions on Software Engineering に掲載されていました。ソフトウェア工学研究室助教の Raula 先生から教えてもらいました。 Need for Sleep: The Impact of a Night of Sleep Deprivation on Novice Developers’ Performance - IEEE Journals & Magazine この論文での被験者はイタリアの大学生 45人。Test-First 開発でプログラムを書かせるタスクを行ってもらっています。23人には実験前日に睡眠を控えてもらい、平均で直近20時間程度は寝てない状態になっています。対照群は、前日に平均で6.5時間、通常通り寝た

ファウラーのエンタープライズアプリケーションアーキテクチャパターン(PofEAA)において、 ビジネスロジックのアーキテクチャにはドメインモデルかトランザクションスクリプトかという二択があります。 仮にプレイヤーの名前変更(ゲームでは可能なことも普通にあるので)をするとします。 ドメインモデル var user = _repository.Find(userId); user.ChangeName(name); //バリデーションは中で行われる=ビジネスロジックがオブジェクトにある _repository.Save(user); ドメインモデル貧血症 //ロジックがモデルオブジェクトの外にある if(!IsValidName(name)) { throw new ArgumentException("name"); } var user = _repository.Find(userId)

This page contains links to the slides and code from my talk “Reinventing the Transaction Script”. Here’s the blurb for the talk: The Transaction Script pattern organizes business logic as a single procedure. It has always been considered less sophisticated and flexible than a layered architecture with a rich domain model. But is that really true? In this talk, we’ll reinvent the Transaction Scrip

先日、 という記事を書いたところ、思ったよりも反響がありました。その影響があったかは不明ですが、また値オブジェクトについての話題がちょびちょびと発生していました。 そのやり取りの中で、私は未読だった論文が紹介されていて、その論文を読んだことで「このようにすると値オブジェクトに誤解が生じる」という一つのストーリーを認知できたため、どのようにこの論文を読むと誤解が発生するか、という事について説明します。 なお、前回書いた記事も、この記事も、誤りを糾弾したいとか、誤ったから著者が悪であるといった事を主張しているわけではありませんので、改めて記しておきます。この記事では、単純に事実の指摘と修正の提案、およびなぜ文脈や定義を大事にする必要があるのかという事について述べます。 いい加減、値オブジェクトの話題はしつこすぎるのでは？非生産的なのでは？そんな事よりもっと生産的な事をしたら？というご意見もある

パイプライン処理とは GUIは非常に直感的です。はじめて使うアプリであっても、なんとなくそれなりに動かせてしまうという点で、優れたインターフェイスと言えます。しかし効率を突き詰めると、軍配が上がるのはGUIよりもCLIでしょう。本連載の読者であれば、UnixライクなOSのCLIが持つパワーについては当然ご存知かと思います。 とはいえ、古典的なUnixコマンドの多くは、単体ではそれほど強力なものではありません。というのも、ひとつひとつのコマンドはシンプルに、特定の用途においてのみ上手く動作するよう設計されていることがほとんどだからです。こうしたコマンド群に無限のシナジーを与えるのが「パイプライン処理」です。標準入出力を通じて複数のコマンドを直列に繋げることで、複雑な処理をインスタントに組み立てることができるパイプラインは、まさにUnix哲学の体現であり、CLIの真髄はここにあると言ってもよい

よくKindleでセールやってる! 50%オフ! 50%ポイント還元! ということがあるけれど、全部無視して出版社のサイトでPDFを購入している。 DRMがかかっていない メールアドレスがPDFのページに刻印されたりはある 好きなリーダーで読める 自分の管理方法は後述 出版社に一番還元できる と勝手に思っている あたりが理由。 購入できるサイト O'Reilly Japan Ebook Store 一部EPUBやmobiもある Gihyo Digital Publishing … 技術評論社の電子書籍 EPUBもある 紙の書籍のおまけをここでダウンロードできたりもして便利 SEshop.com ｜ 翔泳社の通販 定期的にセールをやっていて、最大で50%ポイント還元がある 紙の書籍も50%還元になることがあってびっくりする… 本文とは関係ないけど ILLUSTRATION 2022 のシリー

ログラスでは、チームとして高品質なコードを追求するために「設計標準」というものを定め、チームで育てています。 この資料ではそのような取り組みについてご紹介します。 株式会社ログラス会社紹介資料 https://speakerdeck.com/loglass2019/whats-loglass ウラ凸 - シリーズA 17億円調達のログラスのウラ側へ、カジュアル面談で突撃しよう https://meety.net/articles/t2--zrl4ohf4gx6 外部公開している設計標準の資料 https://little-hands.hatenablog.com/entry/2022/01/28/programming-principle https://little-hands.hatenablog.com/entry/2022/01/24/domain-object-design

Boost Your Performance and Developer Productivity with Jakarta EE 11

（6/22 注：書き足りないと思っていた箇所を補って加筆修正しました） エンジニアのbonotakeです。Ideinに入ってかれこれ3年以上経ちますが、Ideinでブログ記事を書くのは初めてです。 今日は、ソフトウェア設計の全く新しい考え方について書かれた "The Essence of Software" という本の紹介をしたいと思います。 この本の著者はMIT教授でソフトウェア工学の世界的な研究者であるDaniel Jacksonです。形式手法Alloyの発明者、と言ったほうが通じる人には通じるかもしれません。形式手法とは、ありていにいえば、数理論理学を駆使してソフトウェアに潜むバグを論理的に駆逐する手法です。 （個人的な宣伝ですが、彼の書いたAlloyの本を以前翻訳して出版しました。） そんな彼が昨年11月に新著を出版したというので、ほぼその日に買いました。……ですが、本を開いてみる

Developer Summit 2020 発表資料 #devsumi

この記事では、私たちのチームがスプリントゴールの達成とコード品質の低下を防ぐために行っているプラクティス、「死亡前死因分析」について紹介します。 スクラムチームと計画 変化への適応が強調されるスクラムですが、だからと言って事前の計画をないがしろにすることはできません。 私たちのチームが大切にしているキーワードのひとつに、“Measure twice, cut once” （二度測って、一度で切る）があります。もともとは優れた大工の仕事を指す言葉で、注意深く計画し一度で仕事を済ませる、手戻りのない状況を表現する言い回しです。 私たちにとっても、“Measure twice, cut once” の大切さは大工にとってのそれと変わりません。手戻りはデリバリの速度だけでなく、実装の素直さやコードの端的さにも悪い影響を与えるためです。ソフトウェアのバグが一番現れやすい箇所は「苦労と試行錯誤の末にな

キーポイント Design System Opsは、デザインシステムとその構成要素を運用し、標準化するための方法である チームの非効率な作業を減らし、ワークフローを最適化し、デザインシステムを普及させ、システムの拡張を簡単にすることができる Design System Opsは、ただユーザーを特定し、取り除きたいDesign System Opsの問題を定め、解決策を実行し、その効果を測定するもので、誰でも始められる UXPin MergeはデザインシステムからUIコンポーネントをインポートし、そのコンポーネントを使ってデザインエディターでプロトタイプを作成しやすくするツールであり、Design System Opsに最適 企業や部署が効率性を追求し、運用コストを削減するにつれて、より多くのOpsの役割が見出されています。DesignOpsという言葉は聞いたことがあると思いますが、Desi

C# 6 の機能である null 条件演算子を式ツリーに入れようとしたら、図のようにコンパイルエラーが発生しました。メッセージは、「式ツリーのラムダに null 伝搬演算子を含めることはできません。」です。 「ラムダ式から式ツリーの変換って何か制約あったけ？」 「どうして三項演算子での書き方（図の後者の記述）だとOKなのにこれはだめなんだろう？」 といろいろ分からなかったので整理しました。 調べた結果、このコンパイルエラーの原因は次のことが原因でした。 null 条件演算子は式ツリーデータに変換できない null 条件演算子と例の三項演算子は、同じことではない ラムダ式のすべてが式ツリーデータに変換できるわけではない また、null 条件演算子を式ツリーデータに変換するように対応すれば幸せ、という話でもない 言葉について ここまで画像と文章にいろいろな言葉がでてきますが、参考リンクを置いて