2019年にもなって未だに非同期I/Oを使わずPHP、Python、Ruby等でProcessを浪費しているサービスが増える理由とは！RubyPythonPHPRails非同期IO はじめに 間違えている箇所があれば指摘していただきたい 特にPHP,Python、Rubyを本格的に開発した経験が少なく 間違ってたら私のために教えていただきたい ただ1つ　私の中でも正しい用語定義がわからないので 非同期と書いたときは　非同期I/O、ノンブロッキングI/O　両方のことをさし マルチスレッドは並列などと表記する 現在の状況 2019年。Webサービスはどんどんローンチされている Java、nodeといった非同期のサービスも増えてきたが 未だに　PHP、Python、Rubyといった非同期ではなくプロセスを立ち上げるサーバが多い （asyncioとかeventmachene等の非同期機能はあるが、

テスト駆動開発の過去・現在・未来 XP祭り2018 基調講演 2018/09/08 http://xpjug.com/xp2018-session-keynote/

この記事は DMM.com Advent Calendar 2018 - Qiita の25日目です。 About CircleCIとCode兄弟を使いCI/CDを作っていこうというものです。 単純に環境を作るわけではなく、CloudFormationを使って本番環境を想定した構成にしていきます。 ターゲットとしては既にCircleCI・CodePipelineをざっくり知っている人で、本番向けのCI/CDをどのように構築していくかについて自分なりのプラクティスを紹介します。 サンプルコード 今回の構成を再現するためのコードを用意しました。 https://github.com/y-ohgi/ci-cd-example CloudFormation 環境はCloudFormationで管理しているため以下のコマンドで再現できます。 VPC、Aurora、ECS、CodePipelineなど

主にUI設計やプログラミングのAPI設計について、「わかりやすい」というのは主観的で合意が取れないのでクソという話。 定量的な指標が示されてない そもそも趣味が合わない場合はそこで終わり 〜の本来意図された機能が隠れてしまっている ↑によって隠れてしまった機能を呼び出すのが、最終的にコストが掛かる 何が言いたいかと言うと、「指標の伴わない変更に意味はない」「APIの呼び方を変える程度のラッパーライブラリやヘルパーには、特に意味がない」ということです。 ここからプログラミングの話に絞りますが、特にショートハンドしたいだけの場合、ショートハンドするAPIの実装は、必ず本来の機能を呼び出す脱出ハッチも必要となります。 よく練られていない「わかりやすさ」は、次第にこの脱出ハッチを使うことを要求するようになり、結果として捨てられることになります。この破棄までの過程は、結果的に「技術的負債」と表現され

Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んでます。モデリングに関しては成分薄めですが、よい本だと思います。はい。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 作者: Robert C.Martin,角征典,高木正弘出版社/メーカー: KADOKAWA発売日: 2018/07/27メディア: 単行本この商品を含むブログを見る 本書の大筋から少し逸れるが、「5章 オブジェクト指向プログラミング」の「カプセル化」が面白かったので、これを切り口にモデリングについて考えてみる。 OO言語のカプセル化はすでに弱体化している オブジェクト指向の三大要素の一つである、カプセル化について、以下のようなことが書いてあります。 「カプセル化」がOOの定義の一部となっているのは、OO言語がデータと関数のカプセル化を簡単かつ効果的なものにしているから

TL;DR 分散システムにおいてキューを導入する場合、本当にキューが必要なのか再考すべき。そこが地獄の入り口だから。 システムの抽象 コンピュータの世界は、本来は0と1の信号の羅列が飛び交う無機質なものである。でも人類は信号だけですべてを語らず、様々な喩えを定義してきた。それはデスクトップ・ウィンドウ・マウスカーソルといったグラフィカルな表現に留まらず、パケットやカプセル化といった用語にロック・キュー・リスト・木などのアルゴリズムやデータ構造の世界にも自然に溶け込んでいる。これらはすべて人間の理解を助けるための喩え話に過ぎず、この喩えこそが人間のより直感的な理解をもたらす一方で、発想の制約を生み出してきた。 人間が大きなシステムを作るときも何らかの喩えを用いてシステム全体を整理する。アーキテクチャの「ポンチ絵」を描いて情報共有をするのは企業に勤めていれば経験した人も多いだろう。パワーポイン

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

2017/12/19 Tech Night @ Shiodome # 6 https://techsio.connpass.com/event/72585/

本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション

PHPの現場 にて、DI 談義を行うので、頭を整理しておくためのメモです。 DI についてきちんと知りたいのであれば、参照に挙げたリンク先に有用な記事があるので、そちらを参考にして下さい。 PHP を念頭に置いてますが、Java など他言語でも大枠は同じだと思います。この内容は、いずれ整理するかもしれませんし、そのままかもしれません。 DI という言葉 「DI」が差す意味合いが、依存オブジェクトの注入だけなのか、DI コンテナによる注入を含んでいるのか、DIP まで意識しているのかが、人やコンテキストによって違っていそうで、そこを揃えてから議論しないと。— Masashi Shinbara (@shin1x1) May 19, 2017 DI について話す時に、何を差すのかが異なると話が噛み合わない。そこで、それぞれに名前を付ける。 DI パターン = 依存オブジェクトを注入することを差す

最近また管理画面に近いものをつくったりしていて感じたのですが、事業会社において管理画面がどのタイミングで実装されているかというのがすごく重要だなと感じたのでちょっと書いてみようと思います。 社内向けの管理画面の実装って割と後に回りがちで、最後に仕方なくなんとか実装するようなケースが多いと思うんですよね。そして、ある程度発生してきたオペレーションの実態に合わせて実装するみたいな流れになるのではないかなと。 それはそれで一つの実装の手法だと思うのですが個人的には逆のほうが良いのではないかなと思っています。 管理画面からオペレーションを設計する まず、以下の理由から管理画面ありきでオペレーションを設計したほうが良いと思っています。 既存のオペレーションありきで管理画面の要件を出すため、イノベーションがうまれづらい 組織の最適化より管理画面の最適化のほうが合理的に行える エンジニアの合理的な思考が

ひとことで言えば、「レビュー文化は良くない」ということになるだろうか。 Slack導入、そして同時期に開始した服装の自由化、バイモーダルという考え方の浸透、AIやブロックチェーンを活用したPOC等の取り組みによって、SIerとしてのセゾン情報システムズは、社内の雰囲気もずいぶんと変わってきた。 しかし、こうした取り組みだけではどうにもならないものも少なからずあった。 そのひとつは、「悪い報告がしづらい」ことだった。 これは他のSIerでも同様のことが多いのではないかと思うが、問題プロジェクトに認定されると、品質管理部のモニタリングが強化されたり、第三者によるプロジェクト監査が始まったり、経営会議での定期的な報告が求められたり、何をやっているのかとレビューでこっぴどく叩かれたり、、、。 そうした責任感から、遅れをキャッチアップできるよう少しでもがんばろう、と励まし合う中で、それなのに四方から

Kさん、久しぶりにメールありがとうございました。お元気とのこと、何よりです。ご活躍中の様子が、行間からあふれていました。生産管理の現業をかかえた上に、新規システム導入プロジェクトのメンバーの一員としてアサインされたとは、たしかに大変だろうとお察ししますが、それだけKさんが周囲から期待され一目置かれていることの証左だと思います。 ところで、Kさんからメールをいただくたびに、難しい宿題を投げられたように感じるのですが、今回は格別です。『設計思想に関して』のご質問とは！　なるほど、たしかに新しい基幹業務システムを考える出発点として、“その設計思想はどうあるべきか”を問うのは、とてもオーソドックスかつ当然の発想と思います。自分達が製品を設計開発するときも、成功した製品には明確な設計思想があった。だから、プロジェクトを成功させたければ、当然システムにも設計思想がなくてはならないはずではないか。－－設

若手エンジニアを不幸にしないための開発の「べからず」集を書いてみました。 「若手エンジニアを不幸にしないため」とは書いていますが、若手に限った内容ではありません。 いろんな開発の「べからず」のために不幸になるのは、とりわけ若手が多いということを意識したためだと思ったからです。 ・若手には、方針の決定権がない。 ・若手は、組織の中で道具のように扱われてしまう場合がある。 ・(今の）若手は、将来も働き続けるための力を付けるための組織内での教育が、（昔ほど）なされなくなってきている。 ・コスト意識が乏しいので必要性が乏しいことについてまで残業前提の仕事のスケジュールを組織がたてることが多い。（その分野の理論を知っていれば自明のことを実験で証明することを要求されるのは苦痛である。） 設計指針の「べからず」 何ができれば十分かを明確にしない 開発目標は、何ができれば十分なのかを明確にしないまま、追加

渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。

平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識