はてなブックマーク

ここ数日、こまどさん（@koma_koma_d） が Twiter でクリストファー・アレグザンダーのパタン・ランゲージやそれを参考にしたデザインパターンやアジャイルプロセスなどについて話していて、それにつられて僕もいろいろ考えてみたりしたのでブログにまとめておこうと思う。 ちなみにこまどさんもブログにまとめられており、その記事がこちら。 ky-yk-d.hatenablog.com まあ、僕はあまり大それたことを言うつもりはないのだけど、全体と部分、分析と総合、デザインの民主化、遅延結合などをキーワードに思ったことを徒然なるままに書いていく。Twitterで述べたことをまとめておくかっていう程度のゆるい動機なので、ツイートの引用が多くなること、図を書いたり出典を丁寧に引用したりはできないかもしれないんだけど、そこはあらかじめご容赦願いたい。 パタン・ランゲージとは 読者にどの程度の知識を

タイトルの通り、スタッフをしてきました。1 週間ほど間が空いてしまいましたがそのレポートです。 イベントページはこちらです。 builderscon.io 今回は登壇もさせていただいたのですが、そちらのレポートは以下になります。 a-suenami.hatenablog.com 今回はスタッフ編です。 スタッフ申し込み 上にも書いた通り、今回僕は登壇もさせていただきました。 採択されたのでみなさんご贔屓にお願いします！！！8/30です！！ / ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャ - builderscon tokyo 2019 https://t.co/rGsvJcUNZk— すえなみ (@a_suenami) June 24, 2019 プロポーザルが採択されたこと自体はとても嬉しかったのですが僕にとってはひとつ問題があって、登壇はもちろん一般参加者と

タイトルの通り、登壇してきました。 イベントページはこちらです。 builderscon.io 今回僕はスタッフとしても関わらせていただいたのですが、そちらのレポートは別の記事にしようかと思っており、とりあえず登壇内容に関する話だけしようと思います。 発表資料 資料はこちらです。 2019/09/04 13:26 追記 かとじゅんさんから指摘をもらったのでメモしておきます。 @a_suenami ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャのこのページの前に「DDDのスマートUIアンチパターン」もSoEの目的に合わせて使えばデザインパターンになるという話入れてほしい。https://t.co/qGQmdOs3C2— かとじゅん@MHW復帰勢 (@j5ik2o) September 3, 2019 SoE向けとしては、レイヤーを迂回する話より、スマートUIの話の方が

金曜日に開催された吉祥寺.pm19でタイトルの通りのLTをしたのだけど、ちょっと補足したほうがいいかなと思ったのでブログを書いてみる。 kichijojipm.connpass.com ちなみに資料はこちら。 speakerdeck.com これ、あの資料だけじゃ伝わりにくいかもだし、そもそも5分のLTだったので会場にいた人にも伝わってない可能性なくはないからブログ書くか— 【ありがとうございました】すえなみチャンス暑気払い (@a_suenami) 2019年8月3日 モデルって何？ 「そもそもモデルって何？」みたいなツイートを数日前に見て、僕も最近そもそもモデルって何だっけって考えることが多くなってたのでこのLTをした。僕の中での定義は資料の中にも書いたけど モデルとは解決したい問題領域から必要だと思われる情報だけを抽出し、特徴づけ、記号化や可視化をおこなったもの である。 何のことや

最近フロントエンド書いてて、コンポーネントの設計とかデザイナーとのコミュニケーションには Atomic Design を採用しているのだけど、まあよくある話として「この要素が atoms / molecules / organisms のどれにあたるかわからん！」となる（なった、特に molecules）ので、チーム内に雑にテキストで書いて共有した。で、せっかくならそれを公開して優秀なデザイナーおよびフロントエンドエンジニア諸氏に意見を募りたいと思ったのでブログ書いてみることにする。 ちなみに、現状は実装対象として Web アプリケーションを想定しているけど、ネイティブアプリも視野に入ってるので「HTML ではそうかもしれないけどネイティブアプリだと云々」みたいな意見も歓迎する。 チームに共有したテキストがこちら。 Atom, Molecule, Organismの見極め方 Atomic

経緯 何故なのかまったくわからないんだけど、数ヶ月前からTwitter界隈で謎にタカられるようになった。 以下のようなハッシュタグまでできてもう収拾がつかない状態であった。 twitter.com これはこれでネタとしておもしろいし、僕もいろいろ勉強したいこともあるので逆に利用してやろうと思って、 なんとかさんの金で肉が食べたいというハッシュタグが流行ってるんですが、わりと真面目に、僕とペアプロしてくれたらお肉奢りますって言ったら何時間くらいでどれくらいの肉だったらやってくれる人いますかね？もちろん僕より対象言語とかフレームワークとかに精通してる人限定。— すえなみ＠すえなみチャンス？ (@a_suenami) 2017年12月21日 というツイートをしたのがもう半年くらい前。 ついに先日お声がけいただいた。 すえなみさんの奢りで、肉が食いたい。 Javaかつビジネスルール複雑系であれば、

週末の午前中、カフェでアイスコーヒーを飲みながらふとポエムでも書いてみようかと思い立ってしまったので、ちょっと前からよく考えていることを書く。本当に思いつきで書くので乱文になる可能性が高いけどご容赦いただきたい。そもそもブログを書くこと自体が相当久しぶりだ。 僕ももう 30 をすぎて、プログラマの世界ではさすがにもう若手とは呼べなくなり、教育っていうのはおこがましいけど、まあ自分より若い人たちの指導みたいなことをやらないといけない立場になってきたからこそ、「いいプログラマとはどういう人なんだろう。この人たちはどういうことを学べたら幸せだろう。」ということをよく考えるようになった。そういう話をする。 プログラマは手段のスペシャリストである 世の中には目的・手段論みたいな論調が存在する。 「それは手段だよね。目的をはき違えたらダメだよ。」という話はいたるところでよく耳にするんだけど、僕はこれを

2015/11/14(土) に TDDBC 仙台 5 に行ってきたので忘れないうちに書いておきます。 きっかけ TDDBC 仙台には 2 年前に TA として参加したんですが昨年は参加してなくて仙台の皆さんにはすっかりご無沙汰してしまっているなと思っていたところで今年もやりますというアナウンスが TL に流れてきた感じでした。 そこでサポート言語の中に Go があることを確認して参加を決めた感じです。 今仕事で Go を使ってるのでもっと慣れておきたかったのと、Go のテスト文化は特殊すぎるので一度 TDDBC で議論してみたかった感じです。 うおおお、 #tddbc 仙台やるのかー。観光がてら行こうかな。（参加かTAかは未定）— シングルベル (@a_suenami) 2015, 10月 1 #TDDBC 仙台申し込んでみた。Goでいきたい。— シングルベル (@a_suenami) 2

昨日飲みながらドメイン駆動設計（以下、DDD）についてしゃべっていて思ったことを書く。 ドメイン駆動設計（DDD）って？ DDD とは何かという説明についてはぐぐったらたくさん出てくると思うので割愛。 Wikipedia の引用だけしておきます。（雑） ドメイン駆動設計 - Wikipedia ドメイン駆動設計（英: Domain-driven design, DDD）とはソフトウェアの設計手法であり、'複雑なドメインの設計はモデルベースで行うべきであり'、'また大半のソフトウェアプロジェクトではシステムを実装するための特定の技術ではなくドメインそのものとドメインのロジックに焦点を置くべき'とする。この名称は Eric Evans が同名の著作で用いた。 興味がある人はこちらを読んでください。 エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェ

これを読んでなんとなく思ったことを書く。 僕は「ソフトウェアプロセスが盛り上がってこれから普及するぞ(でも下火になった)って時期」を知らないので、元記事で使われてる言葉をかいつまみながら想像を膨らませて書くことになります。なので、紹介されてる書籍を読んでから書けよという話ではある*1のですが、とりいそぎ忘れないうちにポエム程度に書いておこうかと思います。 ただ、明らかな事実誤認等があればどなたかご指摘ください。 プロセスは人に依存するようになった 「ソフトウェアプロセス技術」というものがそもそもどういうものなのか僕はイメージがわいていなくて、なのでそれが流行りかけて下火になったことに対しても何も言えないというか僕として意見はないのだけど、それらが技術として体系化されたものでなくもっと人に依存するものになった可能性はあると思っている。 ソフトウェアの開発プロセスが技術的に体系化されて管理され

社内の Qiita::Team に投稿したポエムなんだけど、公開して欲しいという声もあったし、別に公開して問題のあるところはないので公開することにした。 長らくデータベースの主流として使われてきたリレーショナルデータベース（RDB）のスキーマ設計は、事象の存在と向き合うことである。そういう意味ではとても深遠で哲学的な営みだ。 いや、待って欲しい。僕の頭はおかしくない。ちょっと説明する。 データベースの用語と存在論の用語は近い 例えば RDB のテーブルのことを「エンティティ」と呼んだりする。存在論において「実体」を表す用語だ。 カラムのことを「アトリビュート」と呼んだりする。これは存在論においてエンティティの「属性」を表す用語である。 このように用語だけとってもみても RDB と存在論が近い関係にあることがわかる。 「人間」の主キーは一体何か 以前、おもしろい議論をしたことがある。 「人間

週末になごやのこわい人*1が東京に来てたのでいろいろ話したんだけど、そのときにちょろっと出た話について忘れないうちにまとめておく。 タイトルの件だけど、結局僕らはテストをやりたいというよりはいいプロダクトやいいサービスを作りたいのであって「テスト」という言葉を使っちゃうといろいろ誤解されることもあるなーと思った。 ソフトウェアの世界で「テスト」と言うといわゆる単体テストとか結合テストとかシステムテストとかのことを暗黙的に示してしまうわけで、それは仕様通りにソフトウェアが実装されているかどうかを確かめる行為であると認識されることが多い。実際にはさらにその先にそのソフトウェアがどの程度の価値を生み出したかという重要な指標があるんだけど、それは「マーケティング」と呼ばれたり最近だと「UXデザイン」と呼ばれたりしてソフトウェアテストとは別のものとして扱われたりする。 でも、機能上のバグだろうと、性

先日、前職の先輩と一緒に飲んでたときにスキルの境界線の話したのでそれについて思ってること書いてみる。 以前にも似たようなこと書いた。 結局言いたいことはこのエントリと同じことなんだけど、転職して（まだ数日だけど）チームのあり方の違いとか考えるところとかあるのでもうちょっと詳しく書いてみる。 忙しい人のために先に結論 アーキテクチャは市場で何が求められているかによって最適な形が変わる。 アーキテクチャのあり方が変わるとそれを効率的に設計・構築するために最適なスキルのあり方も変わる。 Conway の法則によれ組織のあり方はアーキテクチャのあり方によって規定されるべきである。つまり市場のあり方が変われば理想の組織のあり方もスキルのあり方も変わる。 似たようなスキルセットを持った人たちによってエコシステムが形成される。 要求の変化や技術の変化 アーキテクチャは基本的にその時代によって変わる。たか

なんか朝ふと考えたこと特にまとまってない状態で書いてみる。もしかしたら今年最後のエントリになるかもしれないエントリがそれでいいのかっていう気がしなくもないけど。 僕たちのようにソフトウェアをつくている人たちは本質的に複雑性に立ち向かうことが主な営みである。世の中というのは複雑であり、その複雑な世の中で問題とされていることを解決しようとするとその中でもとりわけ複雑な領域を取り扱わなければならない。そうでなければそもそもソフトウェアなど必要ないことになる。人間がそれをやるにはワーキングメモリが少なすぎるとか、時間がかかりすぎるとか、原因は何かわからないけど何らかの理由によりちゃんと遂行できないものこそソフトウェアをつくって解決するべきなのだということになる。 逆に言えば僕たちソフトウェア産業従事者が今も仕事を手に出来ていてちゃんとご飯が食べられているのは世の中が複雑であることの恩恵かもしれない

このエントリは UX Tokyo Advent Calendar 2014 の 4 日目のエントリです。 前日は fumiya さんの「UXデザインのための、ポストデザイン思考」でした。 お詫び 前日の fumiya さんのエントリと盛大にネタ被りしてしまった感じがしています。 ただ、ちょっと他のネタが思いつかないのと言葉を変えれば違う伝わり方をするかも知れないのでおそらくほぼ同じ内容になってしまうと思いますがそのまま書きます。ご了承ください。 自己紹介 すえなみと申します。漢字で書くと末並です。「末波」とよく間違われますが「末並」です。 とても希少な名字なので勉強会等で「すえなみ」と名乗ってる人間がいたら間違いなく僕のことだと思ってください。 オンラインでは a_suenami とか a.suenami とかで活動してます。 Twitter: https://twitter.com/a_

プログラマとして働きだしてからの僕はTDDだったり、オブジェクト指向だったり、RDBだったり、DDDだったり、いろいろなものに没頭して、いわゆる「プログラマの麻疹」をいろいろ経験してきた。 ただもっと昔にさかのぼると僕は以前から「チームのあり方」に興味があって、それはずっと変わってないと思う。僕は学生の頃にビジネスコンテストを運営する団体のスタッフをやっていたのだけどそのモチベーションも組織に属して何かしらの役割を担うということがどういうことなのかを経験してみたいという思いが強かったし、その後にその団体の先輩たちと一緒に作った会社があるんだけどそれに参画しようと思った理由も掲げてる理念がチームのあり方を説いていたからだ。今の会社に魅力を感じたのだって技術力というよりはどっちかという組織のあり方が素敵だったというのが素直なところである。今もアジャイルだ！リーンだ！と言ってるけどそれも開発手法

このエントリは Ruby on Rails Advent Calendar 2014 の 7 日目のエントリです。 前日は seri_k さんの「Turbolinksさんと上手く付き合う10の方法」でした。 お詫び WIP です。公開期限に間に合わない可能性があるため、まだ途中ですが先に公開してしまいました。 サンプルコード等を後ほど追記する予定です。 → 12/08 18:10 追記しました。 Rails のファットモデル問題 Rails で構築したアプリケーションが大規模になり機能が増えていくにつれてモデルが大きくなり、そのうち手がつけられなくなる問題は古くから指摘されています。これについてはもはや詳細を述べるまでもないと思うので割愛しますが、この問題は 2014 年になった今でも多くの開発チームを悩ませていると感じています*1。 このエントリでは、普段 Rails を業務で使いながら

このエントリは ソフトウェアテストあどべんとかれんだー 2014 の 6 日目のエントリです。 前日は Yuji Yamamoto さんの『より「普通に」書くためのTest Doubleライブラリ「crispy」 #ruby #SWTestAdvent』でした。 Ruby Advent Calendar と同時寄稿というのはおもしろい試みですねー！僕も Rubyist の端くれなので大変参考になりました。 さて、僕は具体的なテスト実装の話ではなくもうちょっとプロセス論寄りの話をします。もっと率直に言うとポエムに近いです。 自己紹介 すえなみと申します。漢字で書くと末並です。「末波」とよく間違われますが「末並」です。 とても希少な名字なので勉強会等で「すえなみ」と名乗ってる人間がいたら間違いなく僕のことだと思ってください。 オンラインでは a_suenami とか a.suenami とかで

このエントリは Selenium/Appium Advent Calendar 2014 の 3 日目のエントリです。 前日は Kazu_cocoa さんの「七転び八起きなAppiumを使ったモバイルテストのたしなみ」でした。 僕自身は Appium を使ったことがないのですが、そろそろスマホアプリのテストも自動化していかないといけないと考えていたところなのでとても参考になりました。 さて、 3 日目の僕はシステムテストの自動化に関して現在取り組んでいることを書こうと思います。Selenium を使っているというだけで、Selenium ならではのノウハウとかではありません。すいません。なので、Selenium の Advent Calendar にふさわしくないかも知れませんがご容赦ください… 自己紹介 すえなみと申します。漢字で書くと末並です。「末波」とよく間違われますが「末並」です。

おもしろい記事だったので思ったことを書いておきます。（というか、 Twitter でいろいろ書いたのでまとめ。） ウェブサービス開発の現場におけるデザイナー不要論と5〜10年後の生存戦略 - 情報建築家 石橋秀仁 ただし、元エントリで提案されている「アートディレクター」と「フルスタックウェブデザイナー」にはあまり触れるつもりはありません。それは興味がないとか否定的とかって意味ではなく、僕自身がデザイナーと呼ばれる職種で仕事をしたことが一切ないのでよくわからないという感じです。 とりあえず思ってること 最近、スキルの境界線が変わったんじゃないかなーとか思ってる。] / 他25コメント http://t.co/C60f1AFsE3 “ウェブサービス開発の現場におけるデザイナー不要論と5〜10年後の生存戦略 - 情報建築家 石橋秀仁” http://t.co/nQDF0nBDmC— 末並晃＠半日

以下のような記事が昨日話題になりました。 はてなブックマーク - 保守性・管理性が劇的に上がるPHPのスマートなコードの書き方12選 | BULK SERVER blog 現在では記事自体は削除されていますが、魚拓がとられているのでまだご覧になってない方は以下のリンクをどうぞ。 http://bulkserver.jp/blog/2014/08/07/php-code/ - 2014年8月12日 09:28 - ウェブ魚拓 すでに消されてる記事に対して、アレコレ言うのはちょっと悪趣味かなとも思ったのですが、ブコメを見ると「もうすこし優しく教えてあげなよ」「括弧の省略がなんで嫌いなんだろう」といった記述があったので書いてみることにしました。 元記事を書いた方にこのエントリが読まれることを切に願います。 自分の立場 なんというか某記事、そんなにDisりたくないし、自分だって間違った理解でブログ

なんとなく最近思ったこと*1。（ポエムです。） 言いすぎな気がするけどプログラマに向いてるかどうかを判断するのが難しいのは同意。初心者が「プログラミングやってみたいんです」って言ったときに背中を押してあげるべきかどうかはいつもすごく悩む。— 末並晃 (@a_suenami) 2014, 7月 29 あ、言いすぎってのはRTが言いすぎってことやで。— 末並晃 (@a_suenami) 2014, 7月 29 LLの台頭によってこの10年くらい(？)プログラミングの敷居はすごく下がったと思う。その点からはPerlやPHPが果たした役割はすごく大きいと思うんだけど、それが再び複雑化しているような印象はあって、これから勉強しますって人が想像してるほど華やかではなくなるのではないか的な。— 末並晃 (@a_suenami) 2014, 7月 29 まあ、でも自分が期待しているそのさらに先の世界は、D