「ランディングページってホームページ運営やWebマーケティングをしていると時々聞くけど、どういう意味？」「ランディングページと通常のページは何が違うの？」

この記事はハワイアンAdvent Calendar 2020 2日目の記事です。ツイートアナリティクスによれば、1日目のブログへのエンゲージメントは32という事だそうです。今確認のためにもう一回開いたので33です。わたしは自分のブログを何回も読み直すので、99%は自分のアクセスでしょう。これまでご愛読頂きありがとうございました。 Advent Calendarの前半では進化的アーキテクチャについて触れてやっていくつもりなので、その為の前提を埋めていきたいと思います。 2020年現在、サービス開発や製品開発の為のソースコードの自動生成が進んでいますが、残念ながら製品開発の根幹となるロジックは人間が書いています。人間がソースコードを書くこの時代において、ソフトウェア設計とはなんの為にあるのでしょうか。リファクタリングはなぜ行うのでしょうか。綺麗なコードを書くのはなんの為でしょうか。綺麗なコード

キーポイント For object-oriented design we follow the SOLID principles. For microservice design we propose developers follow the “IDEALS”: interface segregation, deployability (is on you), event-driven, availability over consistency, loose-coupling, and single responsibility. Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to inte

こんにちは。MackerelチームにおいてCRE（Customer Reliability Engineer）をしているid:syou6162です。主にカスタマーサクセスを支えるデータ基盤の構築や、データ分析を担当しています。 今回は、壊れにくいデータ基盤を構築するため、Mackerelチームで実践していることを紹介します。 なぜ壊れにくいデータ基盤を構築するのか データ基盤が“壊れている”とはどういうことか 壊れてないだけでなく、壊れたら気付ける 前提とするシステム構成 壊れたことに気付けるよう監視する 1. バッチジョブが失敗したことに気付く 2. 投入されたデータの性質を監視する 3. ビューが壊れてないかを監視する 4. 利用状況を監視する そもそも壊れてない状態を保つ 1. データリネージを元に修正できるようにする 2. 使われていないテーブルやビューは定期的に掃除 おわりに 参

ポエム。 つまり？予算やチームのリテラシーに合わせて最速で作れて、チーム内で「俺ら高凝集低結合だなー」と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。Go Bold。 ・DDDやクリーンアーキテクチャがダメとは言ってないです。むしろ自分は直近そこまで厳格ではないクリーンアーキテクチャでAPI書いてます。 ・以前こういうポスト書くくらいにはアーキテクチャのこと試行錯誤してました。 アーキテクチャ導入議論への疲労以前僕は、DDDやクリーンアーキテクチャを導入するという話が出ると積極的に顔を出すようにしていました。でも、最近は「導入しましょう」「既に適用してあるのでキャッチアップしてください」などの議論をするのに少し疲れてしまい、足が重くなったように感じます。もうおじいちゃんなので体力がないん

はじめに現在所属しているプロジェクトではWeb APIやバッチ処理の設計の一環としてPlantUMLを利用しています。効率よく品質高くアウトプットを出すためには、プログラミング言語に対してコーディング規約があるように、UMLに対してもチームで設計するにあたり一定のルールを決める必要があります。 そこでプロジェクト内のPlantUMLを使用するうえでのガイドラインやルールをまとめる機会があり、せっかくなのでそれを記事化します。 記事のゴール シーケンス図設計におけるPlantUMLの標準化 必要最低限のルールだけに絞ってチーム設計の生産性と品質を上げる 記事の前提 ルールの想定の利用シーン： チームで大量生産する業務機能の処理フローを表現するために使う場合を想定。 また、この記事に記載されているルールはRDBを中心的に使用したAPI処理やバッチ処理等を念頭に置き決められたものです。 ルールの

ソフトウェアでもっとも重視すべき品質は「発展性」なんだと思う。 機能要求や非機能要求は、時間とともに変化する。その要求の変化に対応してソフトウェアを発展させていける能力、つまり発展性こそがソフトウェアの価値を大きく左右する。 発展性に問題があり変化ができないソフトウェアと、発展性に優れ変化と成長を続けやすいソフトウェアの価値の差ということだ。 発展性の価値 顧客のニーズは変化する。また、市場の競合関係も変化する。そういう事業環境の変化にあわせて、ソフトウェアにも変化を続ける能力が求められている。 また、顧客のニーズや市場環境の変化がゆるやかだとしても、事業活動をすれば組織は経験を通じて学び成長していく。開発チームに限っても、ソフトウェア開発運用の経験を積むことで、開発の考え方とやり方にさまざまな学びと成長がある。そうやって学んだ知識を適切にかつ迅速にソフトウェアに反映できるほど、事業により

noteのデザイナーの松下です。 昨年はnoteのDAUが倍増するなど、サービスにとって変化が大きい年でした。 以前も、noteのデザインチームとそのサービスへの関わり方について記事を書きましたが、そこからおよそ一年が経過して、デザインチームの動き方も変化がありました。（メンバーも増えました！） もはや、デザインチームというよりも組織自体に大きい変化が起きています。 この短期間でこの変化幅…このライブ感はなかなか味わえるものではなく、エキサイティングな日々を過ごさせてもらっています。サービスも、チームも、ひいては会社も、本当に生き物。フェーズが変わって、育ったり、ルールのアップデートがあったりするわけです。 また、事業の世界観が拡張されると同時に、求められる「デザイナー」像の世界観も拡張された一年でした。 この記事では、前半でチームとしての変化。 後半で、求められるデザイナー像の変化につい

いわゆるGoFの23個のデザインパターン。知っておくに越したことはないが、フレームワーク・ライブラリに溶け込みすぎていて、現代では知らないうちに使ってることになるので、余裕があれば。

Apple reveals how it's made the iPhone 16 series (much) easier to repair

「エンジニアリング」という言葉を聞くと、読者諸賢はどのような仕事を想起されるだろうか。都会的なオフィスで遂行する、理知的な設計とデザインの仕事？　それとも製図板と作業着とノギスをともなう、泥臭い仕事？　あるいは企画と要求仕様だけを与えて、どこか海の外でやってもらう設計の力仕事？ 『エンジニアリング会社』と呼ばれる職場で、もう30年以上も働いている。会社には、机と椅子とPCと、あとは人が並んでいるだけだ。自社の工場は持っていない。建設現場はあるが、建設労働者を雇っているわけでもない。資機材は世界中の製造業の会社に頼んで作ってもらい、物流業の会社に頼んで現場まで運んでもらう。据付け組立工事は、現地の工事業者にお願いしてやってもらう。 わたしの属するエンジニアリング業界には、国内で「専業」と呼ばれる大手が３社あるが、どこもほぼ同じような業態である。もっとも、国内には「エンジニアリング」と名前のつ

第12回 インターネットと運用技術シンポジウム（IOTS 2019）～運用管理する人”も”報われるシステムの構築を考える～ にて招待講演を行った際の資料です。 概要: https://www.iot.ipsj.or.jp/symposium/iots2019/ プログラム: https://ww…

この記事はPLAID Advent Calendar 9日目の記事ですUI改善の前提理解、うまくできていますか？皆さんはこれまで着手してこなかった既存画面のデザイン改善をする時、どのように進めているでしょうか。 自分がプレイドで所属しているreBAISUというチームでは、タタキとして定義したスタイルガイドを旧来の画面に適用しながらUI改善する取り組みをしています。 取り組み方として、改善対象となる画面の仕様を理解しながら課題を見つけ、解決策を検討していく流れになるのですが、この仕様理解が難しいと感じていまして。 なんとか前提理解を促せる方法はないものかと検討した結果、対象画面の構成要素をひとつずつ紐解いていく方法で理解していく「デザインの逆行分析」という方法をとっていました。 デザインの逆行分析とは「リバースエンジニアリング」とも呼ばれる手法で、その考えをデザインでも応用しようというもので

電気回路内の電磁ノイズの起源を大阪大学が解明、電磁ノイズレス回路設計が可能に 大学ジャーナルオンライン編集部 大阪大学の神野崇馬博士後期課程3年生らの研究グループは、電子・電気機器の誤動作や発熱の原因となる電磁ノイズ現象を定量化するための理論を考案し、その発生メカニズムを解明して、電磁ノイズが発生しない回路構造を理論的に導出することに成功した。 今回の研究では、電磁ノイズ現象の記述のために、電気回路を信号の往復路である2本の導線で表し、環境を1本の導線で表した3本線回路を使用。その結果、信号を表すノーマルモードと、電磁干渉を表すコモンモードの定式化が可能になった。さらに、3本線回路の入力や出力での接続関係を考慮し、各モードの振る舞いを表す方程式を導出。その結果、回路と環境の幾何学的な位置関係と、接続される素子との電気的な接続関係により、コモンモードがノーマルモードに変換され、電磁ノイズが発

By DragonImages プロのソフトウェア設計者の働き方や習慣をまとめた本「Software Design Decoded」から、ソフトウェア設計者がステップアップするために身につけるべき8つの習慣がピックアップされています。 Eight Habits of Expert Software Designers: An Illustrated Guide | The MIT Press Reader https://thereader.mitpress.mit.edu/habits-of-expert-software-designers/ ◆1：ユーザーと関わりを持つ 優れた設計者はユーザーに対して鋭い洞察力を持っています。ユーザーを調査したり、会話したり、意図的に設計プロセスや中間設計のテストに関与させたり、さらには設計チームで積極的な役割を担うように依頼して、ユーザーの意見を引

自分が本格的に設計を意識するようになったのは、2015年の夏に現職であるFringe81株式会社で開催されていたサマーインターンに参加してからだ。 インターンではDDDとクリーン・アーキテクチャ*1を一から勉強してAPIサーバーに実装する、というカリキュラムであったが、いま思うと2週間という比較的長いインターンで僕が学べたことと言えば本当に微々たるものだった。つまるところ、それくらいには設計というものは奥が深い。常になんらか特定のデザイン・パターンなりアーキテクチャ・パターンを適用することでアプリケーション開発がうまくいくということはなく、それらの様々な知識から少しづつ応用されたものが最終的なアプリケーションの設計に対して真の洞察を与えてくれるものというのが、僕自身のいまの認識である。 設計はまさに Connecting the dots そのものだ。多くを知れば知るほど、アプリケーション

この記事について 先日 DDD-Community-Jp の DDD Talk MeetUp #2 というイベントでトーク枠にて参加させて頂き Flyweight DDD というアーキテクチャスタイルの提案とする一つのスライドを発表させて頂きました。 https://speakerdeck.com/hirodragon112/ddddao-ru-nita-miqie-renaifang-hezeng-ru-2ceng-plus-cqs-akitekutiya-flyweight-ddd ただ、本稿はこのスライドの「内容」とは全く関係ありません。 本稿で取り上げたいのはこのタイトルに登場している CQSという単語についてです。 このスライドをきっかけにCQSとCQRSの違いについて自分なりに思考の整理を記載したいと思います。 CQS ? CQRS ? きっかけは twitter にて @j5

健全なnoteコミュニティを設計するうえで、チーム向けの多様性に関するメモ。多様性は色で考えるとわかりやすい。 昨今、多様性に関する議論が活発化してきている。不利な人々に優遇措置を与える、アファーマティヴアクションなども、どんどん増えてきてる。 でも、ちょっと怖いのが、「多様性」と「均一性」の違い。これが、あまり議論や区別されないまま、ドンドン進められているに思える。 多様性は色で考えてみようわかりやすいモデルとして、多様性を色で考えてみましょう。パレットや絵画をイメージしてください。 赤1色。これは全く多様性のない状態。意見や行動が完全に統一された世界です。これは一切の選択肢のない世界です。 様々な色を列挙した図。同じ職場に、白人と東洋人と黒人とヒスパニックの人々がいるようなイメージですね。一見多様性があるように見えますが… 実は、これをさらに離れて俯瞰をしてみると、こうなります。 ミク

たとえば設計について議論するときや、コードレビューで指摘をするときに、「なぜその設計が良いと思うのか？」について言語化するのが上手だと、確実に良いことがあります。 言語化が上手にできるかが一つの壁なのではないか、と感じることもあります。後輩を育てたりチームをリードするような立場になると、特に必要性を感じるのではないかなと。 自分も、うまく言語化できたことですんなり議論を進められていると感じることは多いですし、逆に直感的な良さを言語化できなかったことで直感に反する方向に進んでしまい、結果よくなかったというような苦い経験もあります。 前提: ソフトウェア設計の良さは静的には決まらない良い設計・良いコードとは何なのか。という質問に一言で答えるなら、「保守性が高い」ことだと思います。つまり、今後の変更・拡張を、高速にバグが少なく行えるような状態が良い設計・良いコードです。(一般的にはこれで70%く