PHPアプリケーションでEvent Sourcing、CQRSを実践する場合の ミドルウェアとの組み合わせ、基本的な考え方 実例を交えた資料です

表題の通り、お恥ずかしい限りではありますが、人生ではじめて警察（神奈川県警！）のお世話になる運びとなりました。 罪状としては「不正指令電磁的記録 取得・保管罪」、通称ウイルス罪とのことで、まさに青天の霹靂の思いです。 以下ではこの度起こったことを可能な範囲でありのまま共有できればと思います。 この記事の目的まず、この記事を公開した目的は「他のクリエイターの人に同じ経験をして欲しくない」という一点に尽きます。 手前味噌ではありますが、私はこれまで多くの尊敬するクリエイターの方々と同じように「良いクリエイターであろう」と腐心し、できうるかぎりの努力をしてきたつもりです。 今回の件に関しても決して私利私欲のためではなく、あくまでユーザーのためにできることを、と模索した結果でした。 それがこのような形で取り沙汰されることとなり、残念という他ありません。 忸怩たる思いではありますが、この件から何かし

こんにちは、開発部の id:yszk0123 です。最近、フロントエンドで使っていたツールを Flow から TypeScript に移行したので、そのお話をしたいと思います。 背景 一年半ほど前にとあるページを React に移行したのですが、その際に、型チェックツールとして Flow を採用しました。 採用の理由は、簡単に導入できて、いざとなれば簡単に捨てられるからです。 それからしばらく運用する中で、ある程度の規模であれば型の有用性を実感できたため、本格導入することになりましたが、次に挙げるような理由により、Flow をやめて TypeScript に移行しました。 理由 Flow の問題 1. 型定義ファイルの管理が複雑 ライブラリの型定義ファイルの管理がそこそこ複雑です。 flow-typed という型定義の管理ツールを使えば管理はできますが、インストールしたファイルを git

サグーワークス開発チーム PM の横道です。 サービスを運用していると利用者や運営メンバーから不満や改修依頼を受けることが少なからず発生してきます。一方で、開発からも運用を楽にするための提案をしているため、優先度をしっかりと判断して進めていく必要があります。そこでサグーワークスではどうやって要望を吸い上げて対応しているのかを紹介します。 要望の吸い上げる方法 １．定常的に発生する運営メンバーからの要望や依頼 業務を行っているとシステムに関する要望や質問が出てくるはずです。そうした内容を漏らさず対応するために要望を上げるときは下記の運用ルールに沿って運用しています。 要望の内容 依頼方法 補足 簡単なデータ取得 / 変更 Google フォーム 「簡単」の目安は 30 分以内に終わる規模 質問 Slack 相談チャンネル 開発要望 Slack 相談チャンネル システム不具合 Slack 相談

こんにちは。2018年度の4月に新卒で入社したエンジニアの小澤です。入社して２ヶ月が経とうとしています。 学生時代は、情報セキュリティについて専攻している4年制の専門学校に通っていましたが、自分の作ったものが他人に使ってもらえるwebの領域に興味を持ち、在学中はweb開発をしているインターンシップなどに参加していました。 今年度は新卒14人の中から、私を含めた6人が開発グループに配属されました。入社してすぐに新卒社員全体の研修とエンジニア全体の研修があり、エンジニア研修は、「全体研修」と「チーム内研修」の2つに分かれていました。 今回のブログでは、チーム内研修についてまとめていきたいと思います。 企画からサービスを作る「チーム内研修」 チーム内研修では、業務に慣れるためにチームで実際に使っている技術やツールを使い、サービスを1から作ってみる、といった内容で、私は趣味に関して情報発信や意見を

ブラウザはGUIアプリケーションプラットフォームではない Flexboxについて React DOMはGUIアプリケーションフレームワークではない React NativeはGUIアプリケーションプラットフォームの抽象である React Native for Webがブラウザに持ち込んだもの コンポーネントが便利 スタイル周りも良い感じ TouchableOpacityでタップ表現もラクラク 他にもいろいろあるけど プロダクション事例が強すぎる 作者のnecolasも語ってた まとめ 余談：React系のアプリケーションフレームワーク React Native for Webは、React NativeをWebに持ち込む試みです。 しばしば、こういった試みに対して「わけがわからない」「本末転倒である」といった意見を見かけますが、筆者は妥当な試みであるという印象を持っています。ちょっと頭の中

@rana_kualuさんの2018年の最先端バックエンドエンジニアになろうという翻訳記事がとても興味深かったのですが、記事内で提示されているロードマップに関して微妙に違和感を感じる部分もありましたので、 記事に記載されているスキルは現場でどの程度必要なのか 記事に記載されていないが現場において重要なスキルは何か といった辺りを、自分なりの意見を交えてちょっと書き出してみました。 自分をエンジニアとして最先端だとは全く思っていないのですが、最近のバックエンドのトレンドに一応多少なりともきちんとキャッチアップしてるかなとは思うので、若い方や、まだ経験の短いエンジニアの方たちのご参考になりましたら幸いです。 言語 ロードマップに記載されていた言語のうち、私は一応 Elixir Scala Java .NET (C#とVB.NET) Python Ruby PHP TypeScript Gola

怒り、という下らない快楽 怒りという感情は、人間が持つ他の感情と比較してもかなり強い力を誇る感情であると思う。瞬発力、瞬間最大風速でいえば、あらゆる感情の中で最も強いものなのではないかとさえ感じる。 さて、そんな怒りという感情はどんな時に生まれるのだろう。僕が経験則から導き出した結論としては、理不尽や納得のいかないこと、弱みを突かれた際の防衛、自己正当化の拠り所として生まれるのではないかと考えている。 仮にこの仮説を正とすると、怒りという感情は非常に独善的なものであると言える。相手を打ち負かす為や自身を守る為、という由来には客観的な観点が存在しない。つまり怒っている人間の視野は非常に狭く、自身のことしか見えていない。盲目的であり、建設的な思考が出来ない状況にあるといえる。 では、怒ることは悪いことか。それ自体が悪いわけではない。人が生きていく以上、自身を守ることはこの上なく重要なことである

はじめまして、2018年入社の田島です。 今回は入社まで web アプリケーション開発にほとんど触れてこなかった私が、新人研修に参加した模様についてお届けしたいと思います！ はじめての web アプリケーション開発 web アプリケーション開発の基本の「き」も知らない私が取り組んだのは、CakePHP を利用して二週間で web サービスをシステム要件から設計して実装するということでした。すなわち、web アプリケーションの実装はもちろんのこと、どのような人を対象とした何のサービスを作成するか考え、必要な機能の洗い出しや DB の設計まで一通りの行程を全て行いました。もちろん一人では分からないことばかりであったため、メンターの先輩に適宜教えていただきつつ進めました。 実装は実際の業務と同様に実装内容をタスクに分割し、実装予定時間を決めてスケジュールを立てながら行いました。また、Bitbuc

技術的負債の問題は全世界でおそらく課題になっていて（笑）皆さん頭を悩ませているんじゃなかろうか。私もずっとそうだ。プログラマとしてもマネージャーとしても、直接的にも間接的にも苦しめられてきた。 そんなこんなで、うまく行かなかったり多少改善したりしつつ、ドメイン駆動設計に出会って、これが突破口になるとは感じて、取り組んできたり研究したりしてきた。とはいえ、目の前の大きな負債に向かうのはモチベーションもわかないし、組織戦略としてどうするかは本当に悩ましい。問題は「技術的負債」と一言で言えるほど単純ではない。組織も人もサービスもシステムもビジネスも絡まり、大きくて複雑だ。 そんなこんなで、増田さんとうなぎを食べに行って、増田さんのその辺の見解を伺ったり、ディスカッションしたりしていたんだが、増田さんが木工職人の例を話しをされていたときに、 「木工職人たちは「一手間」を大事にしていた」 ということ

DDDネタです。 DDD Community-JPのDiscordで「複数の集約（Aggregate）をまたいで整合性をどう担保するのが良いのか？」という話がされていました。 この話を読んでいて、 yoskhdia.hatenablog.com でもサラッと触れた「トランザクション」をもう少し掘ってみようかなと思い立ったので書いてみるエントリです。 先の記事では次のように書きました。 実業務、ドメインを見れば、本当にまとめて処理しなきゃいけないものは、結構少ないはずです。 働く人たちは、どういう会話をしているのか、仕事の単位は何なのか、によってトランザクションを設計することが、メッセージングシステムを考えるうえで有用だと考えています。 「トランザクション」という言葉は、開発者にとっていくつかの意味を持ちます。 ここでは、 DB操作のトランザクション（以下、DBトランザクション） 業務のうえ

Speaker Deck の仕様 Speaker Deck に発表資料を公開するとき「タイトルから URL が生成される仕組み」になっている．タイトルが全て英語なら問題はないけど，タイトルに日本語が含まれる場合は「中国語のようなローマ字」になってしまうという裏仕様があり（以下に例を載せた），今まで「内容は素晴らしいのに URL が残念すぎる資料 💦」を多く見てきた．知っている人は知っている仕様だと思うけど，まだまだ普及していなさそうなので，今回ブログに書くことにした． プロジェクトをリードする技術 puroziekutoworidosuruji-shu 最高の URL を生成する技術 今回「Speaker Deck で最高の URL を生成する技術」を紹介したいと思う．と言っても本当に簡単なことで，以下のように「スラッシュ区切りで英語タイトルを追加する」だけ！最高すぎる！ 日本語タイトル

・樹木セルロースナノファイバー由来の「透明な紙」とセルロースパルプ繊維由来の「白い紙」を用いて、電気で表示する電子ペーパーを作製。 ・従来絶縁性であった紙に導電性高分子またはイオン液体を複合化することにより、透明性に優れた電極と視認性に優れた白い電解質を作製することに成功。それらを組み合わせてフレキシブルな電子ペーパーを実現。 ・手書きや印刷で表示してきた従来の紙に、電気で表示するディスプレイとしての新たな価値を生み出す成果。

サグーワークス開発チームの池添です。 今回はチーム目標「Comfortable development / 2.0」の取り組みの中から Bitbucket Pipelines (CI) の活用内容をお話していきます。 チーム目標に関しては下記記事に書いてありますのでぜひ読んでみてください。 tech.willgate.co.jp Bitbucket Pipelines 利用に至ったきっかけ チーム内では以前からコードレビューの時間短縮、負荷軽減のためにCIツールなどの導入を検討してきていました。 しかし、なかなか導入できなかった背景としてサービスの利用技術が古く、Composer が導入できない PHP のバージョンだったため、コードスタイルチェックのツールである phpcs やユニットテストのためのツールである phpunit が導入できないという状態が続いていました。 以前の記事でも紹

今日，社内勉強会で話す機会があり，過去1年間を振り返りつつ「プロジェクトをリードする技術」というタイトルにした．今回は参加者がエンジニアだけじゃなく，ビジネスチームのメンバーもいたため，できる限り，技術的な用語を使わないようにした．質疑応答とディスカッションもあり，1時間非常にワクワクした時間だった． 関連する領域 僕がプロジェクトをリードするときに意識しているのは，スクラムなど特定のプラクティスに依存しすぎないことで，チームの特性によって，関連する様々な領域からプラクティスを集めている．ザッと挙げるだけでも，こんなにたくさんある． チームビルディング ファシリテーション マネージメント 3.0 アジャイル (スクラム / カンバン / XP) 組織論 育成 心理学 メンタリング プロジェクトマネジメント 資料 過去1年間に取り組んだことを全て詰め込んだ！プレイングマネージャーとして頑張っ

AWS データベースブログの記事 「Amazon DynamoDBによる CQRSイベントストアの構築」 を勝手に読み解く

はじめまして、インフラチームの内田です。主に社内ネットワークを担当しています。 ウィルゲートでは「兼チャレ」「兼任」という制度があり、私は前年度に両制度を活用して開発室以外の部署に兼任していました。 「兼チャレ」「兼任」という制度について、またその時の感想をご紹介いたします。 「兼チャレ」「兼任」という制度 「兼チャレ」「兼任」とは何か？ ウィルゲートでは「兼チャレ」と「兼任」という2つの制度があります。 「兼チャレ」「兼任」共に自分が所属する部門以外の部署への兼任に挑戦できる制度となっており、社員が多様な経験を通して自分、事業、組織を成長させるための挑戦機会を制度として実施しています。 2つとも部署を兼任するという点で同じですが、稼働と予算に対する考え方が違っています。 「兼チャレ」は主にチャレンジの意味合いが強く、ミッションや稼働工数は定められていません。 兼チャレ先事業部の上長と相談

プロモニスタでは、Webマーケターの皆さんに有益な情報を届けるべく、人々の消費行動や検索行動を分析してお届けしています。 前回は「渋谷109で働くギャル」、いわゆるF1層にスポットを当てた記事を公開しました。 渋谷109ギャルとSEO対談！！「Googleは終わらない！いまどきの検索スタイルとは？」 若者の利用実態を知るために感度が高い20代のギャル･･･ギャルといえば渋谷･･･渋谷ギャルといえば109！ということで109の有名ショップ「LIZ LISA」さんの渋谷カリスマギャルに、いまどきの検索の活用状況についてリアルな声を聞いてきました。

Googleが中心となってオープンソースで開発されているGo言語は、WindowsやmacOS、Linux、FreeBSD、iOS、Androidなど、さまざまなOSやCPUに対応したバイナリを生成できることが特長の1つとなっています。 そのGo言語のコンパイラが生成するバイナリにWebAssemblyが追加されました。WebAssemblyは、Webブラウザ上でネイティブコードに近い実行速度で高速に実行できるバイナリフォーマットです。 WebAssemblyのサポートは昨年2月から検討がはじまり、先月末に最初のコードがコミットされた状態で、現在も開発が進んでいます。 GOの今後のバージョンアップで正式にWebAssemblyがサポートされる見通しです。 Go言語はサポートするOSやCPUの種類をそれぞれ「GOOS」と「GOARCH」の値で示しています。例えばWindowsのGOOS値は「

はじめに Laravel5.6 でログの仕様が変わり(Laravel 5.6 Release & 5.5 機能差分メモ)、Laravel5.5 までの手法が使えなくなりましたので、Laravel5.6 での手法についての覚書です。 バージョン 5.6.3 時点でのバグ 「ルーティングのグループ単位でログを分割したい」といった時にミドルウェアで新しいログハンドラを追加したりしたいと思っても正常には動作しません。 Monolog のインスタンスを取得し、変更を行ったとしても Monolog のインスタンスを保持している Illuminate\Log\Logger インスタンスそのものがキャッシュされていないため、次回インスタンス呼び出し時(ログ出力毎)に再度新しいインスタンスが作成されてしまうためです。 「[5.6] Fix cache for loggers」で修正されたものが既にマージされ