【PHP】PHPでも静的型付けっぽい使い方をしたい😭⇦厳格モードがあります！
はじめに 「戻り値の型を指定したのに、勝手にキャストされたくない😡」 「エラーを吐いてくれないせいで、不具合の原因究明に時間がかかってしまった;;」 そんなことはないでしょうか? 今回はPHPで厳格モードを使用する方法から、使用しない場合phpがどのくらいゆるゆるな挙動をするかについて解説させていただきます。 ファイル一つだけ厳格モードにすることもできるので、元々のPHPの手軽さも残しながら、重要な箇所のみ厳格モードで記述することができます🤗 この記事を見るメリット 厳格モードについて理解できる PHPの型の挙動がわかる 厳格モードのエラーのおかげで不具合が起きにくくなる！ 対象者 この記事は下記のような人を対象にしています。 プログラミング初学者 駆け出しエンジニア PHPを固く使用したい人 PHPの型の挙動に惑わされる人 結論 ファイルの先頭の<?phpの下に以下の記述を追加するだ
プレスリリース駆動開発のすゝめ - LayerX エンジニアブログ
機械学習・データ部 / データチームの @irotoris です。こんにちは。 データチームでは社内で使うデータプラットフォームやデータマートの開発をしています。今日は弊チームの開発スタイルの中から「プレスリリース駆動開発」を紹介します。 データチームの開発スタイル データチームの開発は1週間のタイムボックスで、月曜日にバックログやプロジェクトから今週取り組むタスクを計画し、金曜にスプリントレビューを行っています。デイリーでは夕会を行っています。ベロシティの計測などは今のところできていませんが、いわゆるスクラムっぽい開発です。 その月曜朝の計画会で、まずプレスリリースを書いています。 プレスリリースとはなにか？ 本来プレスリリースは新商品や新サービス、経営・人事などの企業情報を、ニュースとしてメディアに掲載する文書ですが、ここではデータチームが開発・提供する機能や改善をユーザーに伝えるため
10年もののRailsアプリの持続可能性を求めて -なぜ初手でCoffeeScript廃止を選んだのか- - Money Forward Developers Blog
シニアソフトウェアエンジニアのusadamasaです｡ マネーフォワード クラウド会計とそれに関連するマイクロサービス群の開発運用を担当しています｡ 本記事では､クラウド会計という10年もののRailsアプリの持続可能性をいかにして確保していくかの取り組みをご紹介します｡ TL;DR 私が所属するチームでは､クラウド会計の開発運用における課題を整理し､それぞれの課題に対して解決策を検討し､実行するための取り組みを進めています｡ 最初にクラウド会計の全体の構造を明らかにし､課題を可視化､組織の共通認識としました｡ その上で銀の弾丸を求めるのではなく､有期かつ漸進的な改善のプロジェクトとして計画することが成果に繋がります｡ クラウド会計の現状 クラウド会計はマネーフォワード クラウドの代表的なプロダクトの一つです｡ 2013年にリリースされてから10年､多くの機能追加や改善を重ね､現在では沢山
SaaS アーキテクチャ概要
SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか？をまとめました。
QAイベントに参加して - Qiita
背景 先日、デブサミの後に参加してきたQAイベントでの議論と、 その次の日の業後にあるマイクロサービスメインで扱われている企業のQA部長の方 とディスカッションしてきて感じた内容や発見をここに残す。 前提 ビジネスアーキテクトとして品質管理も担っている自分としては、 ビジネスサイドから品質を考えないなんて言語道断！というマインドがある。 エンタープライズアーキテクチャモデルの4階層を見てもらうのが一番早い。 私たちは、日々手作業のアナログな業務活動に加えて、 情報システムなどを使った業務プロセスと込みで、 全体としてサービス全体を成り立たせて、それをエンドユーザーなどに提供している。 BtoCだろうが、BtoBだろうが、この本質部分は一緒である。 そのビジネスの中で、「ここの連携早くしたい」とか 「この情報は、企業の存続のために死守したい」などという EAの最上位層であるビジネスアーキテク
技術的負債イベントに参加して - Qiita
前置き 業後に技術的負債のイベントに参加してきました。 内容がそれぞれバラバラであるかに見えて、自分の中ではすべてが有機的に繋がって感じました。 ただ、懇親会に参加できなかったのは残念です💦 開発サイドの方や、テスト設計されている方、組織構造と絡めて話されている方 などそれぞれが違った観点で技術的負債についてアウトプットされていました。 技術的負債の定義 「コードを書くというのは、借金をするようなもの。 少しの借金は速やかに返済(リファクタリング活動により)される限り開発を加速させるが、 危険なのは借金が返済されない状態が続くこと。」 という文が紹介されました。 つくっているプロダクトで得られる売り上げよりも、 変更などにかかるコストが上回っている状態なわけだから、 お金という定義が明確な数値として、負債曲線グラフ的なもので定期的にチェックできる体制が望ましいですね。 で、事前に負債解消
Java Persistenceを使ったアーキテクチュア：パターンと戦略
図1：データベースとJavaプログラミング言語のミスマッチ このギャップを埋め、Javaアプリケーションとデータベースのシームレスな接続を実現するために、私たちはさまざまなデザインパターンとアーキテクチャアプローチに依存している。これらのパターンはトランスレータとして機能し、インピーダンスのミスマッチの影響を軽減し、2つの世界を調和して動作させるのに役立つ。 これらのデザインパターンは、車輪の再発明ではない。これらは、アプリケーションとデータベースのパラダイム間のインピーダンスのミスマッチを緩和するのに有効であることが証明されている、確立されたソリューションである。Driverパターン、Mapperパターン、Active Recordパターン、Repositoryパターンなどがある。 Java Persistenceにおけるデータパターンのナビゲート このセクションでは、アプリケーション開
女友達 - 椎彩人 | 少年ジャンプ＋
JASRAC許諾第9009285055Y45038号 JASRAC許諾第9009285050Y45038号 JASRAC許諾第9009285049Y43128号 許諾番号 ID000002929 ABJマークは、この電子書店・電子書籍配信サービスが、著作権者からコンテンツ使用許諾を得た正規版配信サービスであることを示す登録商標(登録番号 第6091713号)です。
What it was like working for GitLab
I joined GitLab in October 2015, and left in December 2021 after working there for a little more than six years. While I previously wrote about leaving GitLab to work on Inko, I never discussed what it was like working for GitLab between 2015 and 2021. There are two reasons for this: I was suffering from burnout, and didn't have the energy to revisit the last six years of my life (at that time)I w
運用設計における設計項目の体系化 / 20240207-ssmjp-operation-design-items
ssmjp ssmonline #38 "第四回はたのさん祭 オンライン"( https://ssmjp.connpass.com/event/307397/ )での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
最近のGoの後方互換性について（2024年も積極的にバージョンアップしよう） - Money Forward Developers Blog
こんにちは！マネーフォワードエックスカンパニー 個人サービス開発部 バンキングアプリ開発グループの仲川です。 みなさん2024年は気持ち良くスタートを切れたでしょうか？私は年始の初売りセールでスマートロックを購入して自宅に取り付けたんですが、施錠が機能していないことに全く気づかず、1週間ほどノーガード状態で「鍵のある生活から解放された！」と浮かれて過ごしていました。 さてソフトウエアエンジニアにとって鍵より煩わしいのは、後方互換性のないソフトウエアのバージョンアップ作業だと思います。今回のテーマはそんな後方互換性についてです。 Goでは2023年にリリースされたv1.21で後方互換性を向上させるための機能が含まれ、公式ブログで後方互換性に関して改めて言及されました。また2024年2月にリリース予定のv1.22では標準ライブラリで初めてv2パッケージが導入される予定であるなど、後方互換性に関
t_wadaさんと「単体テストの使い方/考え方」の疑問点についてディスカッションしました - DeNA Testing Blog
こんにちは、SWETグループの田熊です。 現在SWETグループでは書籍「単体テストの使い方/考え方」の輪読会を実施しています。 輪読会ではメンバー同士で活発に意見が交わされていますが、著者の主張に疑問を感じる箇所もあり、一度グループ外の方とも意見を交換したいと考えていました。 そこで、t_wadaさんをお招きし「単体テストの使い方/考え方」についてディスカッションする機会を設けました。 本記事では、SWETメンバーとt_wadaさんとのやりとりを紹介したいと思います。 ディスカッションの流れ ディスカッションは事前にSWETグループのメンバーが書籍を読んで疑問に感じたテーマを挙げてもらい、t_wadaさんの意見を聞くという流れで行いました。 今回は次のテーマについて話をしました。 「退行に対する保護」があるテストとはなにか 「リファクタリングへの耐性」のトレードオフはあるのか 統合テストの
チームの機能と配備を考えるための7つのチーム責務定義ガイドライン - mtx2s’s blog
前回の記事ではチーム中心の組織づくりの設計原則について書いた。今回は、それらの原則に基づくチームをソフトウェアプロダクト組織内にどう配備し、どのような機能を持たせるかについて考える。これは言わば、チームの責務を定義することに他ならない。本記事ではこれを、7つのガイドラインとして書き出してみることにした。 前回の記事：『チーム中心の組織作りのための6つのチーム設計原則 - mtx2s’s blog』 mtx2s.hatenablog.com 1. ストリームアラインド 2. オーナーシップ制 3. バリエーション分割 4. 技術横断型 5. DevOps 6. 機能横断型 7. マルチスキル 組織設計とはアーキテクティングである 1. ストリームアラインド ソフトウェアプロダクト組織の開発フローは、ユーザーや市場の観察をもとにアイデアを生み出すことから始まる。そのアイデアを仮説として、それを
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アプリケーションエンジニアこそ「監視」だよね！と私が考える訳 #phpkansai
ロストメロウ 1話 - ジャンプルーキー！
DX DevEx 360 | Technology Radar | Thoughtworks
Feature FlagsのDX/UXの 頂点「 DevCycle 」に 辿り着くまでの道のり
実録レガシーコード改善 / Working with Legacy Code: the True Record
Beyond API Compatibility: Understanding the Full Impact of Breaking Changes