タグ

設計に関するWindyWindriyasのブックマーク (11)

  • シングルトンパターンの誘惑に負けない | プログラマが知るべき97のこと

    シングルトンパターンの誘惑に負けない著者: Sam Saariste シングルトン(Singleton)パターンは多くの問題の解決に役立つパターンです。このパターンでは、クラスのインスタンスは必ず1つしか生成されません。そのインスタンスは使用前に必ず初期化されます。そしてシングルトンをグローバルアクセスポイントとすることで、設計をシンプルにできます。こう書いていくと良いことずくめのようですが、この「古典的な」デザインパターンに何か短所はあるのでしょうか 実はたくさんあります。それはよく考えてみるとわかります。確かにシングルトンパターンは魅力的なのですが、私の経験では、このパターンには利点よりも弊害の方が多いと言えます。まずテストの妨げになります。そして保守性の点でも不利です。残念ながらその事実は広く知られているとは言えないため、多くのプログラマを窓きつけているのです。つい使いたい誘惑にから

    シングルトンパターンの誘惑に負けない | プログラマが知るべき97のこと
  • セキュリティを一切考慮しないMMORPGを開発するとどうなるか

    どうもご無沙汰しております。Blogが私の年1回の生存報告、兼、アドベントカレンダー用と相成って久しいですが、今年も一発恒例行事として筆を取らせていただきたいと思います。 今年、私が話題に取り上げますのは、とあるゲームです。Amazon Game Studiosという会社が開発・リリースしました、New WorldというMMORPGについてご紹介させていただきたいのです。ゲームの話題には一切興味がない読者諸君も、どうか少し我慢して、私に騙されたと思って最後まで話を聞いていただけませんでしょうか。そもそも、あのAmazonが開発したMMORPGというのですから、どれほどゲームに興味がなくても、技術に興味のある方でしたら、少しは興味深く感じられるのではないでしょうか? けして後悔はさせませんよ。悪い方向にね。 さて、ゲームに何ら興味知識のない方にもわかるように少し解説を入れさせていただきます

    セキュリティを一切考慮しないMMORPGを開発するとどうなるか
  • 婚活アプリ「Omiai」情報流出の詳細判明、API経由でクラウドに不正アクセス

    ネットマーケティングは2021年8月11日、同社が運営する婚活マッチングアプリ「Omiai」で起こった不正アクセスによる会員情報流出の調査結果と今後の対応策を発表した。調査の結果、同社が契約するクラウドサーバーが不正アクセスを受け、年齢確認書類の画像データが複数回にわたって外部に流出したことが分かった。 Omiaiへの不正アクセスを巡っては、運転免許証や健康保険証、パスポートといった年齢確認書類の画像データ171万1756件(アカウント数)が外部に流出したことが判明している。現時点で流出した画像データに関連した二次被害などは確認できていない。 関連記事: 婚活アプリ「Omiai」、運転免許証やパスポートの画像が171万件も流出した経緯 不正アクセスは2021年4月20日から26日にかけて、同社API(アプリケーション・プログラミング・インターフェース)サーバーを介して、同社が契約するクラウ

    婚活アプリ「Omiai」情報流出の詳細判明、API経由でクラウドに不正アクセス
  • セマンティック バージョニング 2.0.0

    セマンティック バージョニング 2.0.0 概要 バージョンナンバーは、メジャー.マイナー.パッチ とし、バージョンを上げるには、 APIの変更に互換性のない場合はメジャーバージョンを、 後方互換性があり機能性を追加した場合はマイナーバージョンを、 後方互換性を伴うバグ修正をした場合はパッチバージョンを上げます。 プレリリースやビルドナンバーなどのラベルに関しては、メジャー.マイナー.パッチ の形式を拡張する形で利用することができます。 導入 ソフトウェア・マネージメントの世界には、「依存性地獄」と呼ばれる恐ろしいものがあります。あなたのシステムが大きく成長すればするほど、さまざまなパッケージを組み込めば組み込むほど、自分が地獄の底にいることにいつか気づくでしょう。 多くの依存性を有しているシステムにとって、新しいバージョンがリリースされることは悪夢でしかありません。厳密に依存関係を指定し

  • 私がMVCフレームワークをもはや使わない理由

    数ヶ月前、私はなぜここにたどり着き、何が可能かを理解する旅に出ました。この旅は、私にアプリケーションアーキテクチャ、MVCという強烈な宗教に対する疑いをもたらしました。そして、リアクティブ、関数型プログラミングの真の実力に触れたのです。また、シンプルさに集中する旅でもあり、私たちの産業はうまくやっているという考えを捨てる旅でもありました。どんなことを見つけたか興味がある方もいるでしょう。 私たちの見ている画面の背後にあるパターンはMVC –Model-View-Controllerです。まだウェブがなくソフトウエアアーキテクチャも分厚いクライアントが単一のデータベースに原始的なネットワークでアクセスするのがせいぜい、という時代にMVCは生まれました。そして数十年後、MVCはまだ現役であり、衰え知らずでオムニチャネルアプリケーションの開発に使われています。 Angular2のリリースの前にM

    私がMVCフレームワークをもはや使わない理由
  • 「コップに水を入れて」という指示がAIにとって超複雑な理由(2020年11月11日)|BIGLOBEニュース

    AIにはどこまで可能性があるのか。作家の川添愛氏は「実は人間が普段なにげなくやっている行為は非常に複雑。それをAIに対して適切に定義することは非常に難しい」という——。(第2回/全2回) ※稿は、川添愛『ヒトの言葉 機械の言葉』(角川新書)の一部を再編集したものです。 写真=iStock.com/Ociacia ※写真はイメージです - 写真=iStock.com/Ociacia ■「定義された課題」以外はこなせない AIについてよく尋ねられる質問に、「AIには○○ができますか?」というものがあります。 「AIは言葉を理解できますか?」「AIは感情を持つことができますか?」「AIには人間のような思考ができますか?」「AIに哲学はできますか?」……などなど、挙げていけばきりがありません。しかし、こういったことについて考える前に、まずはっきりさせておかなくてはならないことがあります。 それは

    「コップに水を入れて」という指示がAIにとって超複雑な理由(2020年11月11日)|BIGLOBEニュース
  • Engadget | Technology News & Reviews

    'Extreme' geomagnetic storm may bless us with more aurora displays tonight and tomorrow

    Engadget | Technology News & Reviews
  • リファクタリングチームに入ってから学んだ理解しやすいコードを書くための基本的なこと - クラウドワークス エンジニアブログ

    こんにちは! 去年の4月に新卒入社してからお酒ばかり飲んでいるエンジニアのd4teです。 4月から11月まではUX改善チームにてお仕事検索画面のフロントエンド開発を担当しておりましたが、11月からはリファクタリングチームにてcrowdworks.jpのリファクタリングをしています。 現在のcrowdworks.jpの状況 過去の記事にもあるように、crowdworks.jpはサービスインから約8年が経過し、30万行を超えるモノリシックなRailsアプリケーションになってきていて、コード行数の増加量やファイル変更数の推移は年々鈍化してきています。 内部には開発生産性を低下させる技術的負債が溜まってきており、技術的な投資がしづらくなってきているという課題があります。 自分が所属しているチームは、外部から見た動作を変えずに内部のコードを整理するリファクタリングで技術的負債を解消し、開発生産性の向

    リファクタリングチームに入ってから学んだ理解しやすいコードを書くための基本的なこと - クラウドワークス エンジニアブログ
  • 焼肉サブスクの脆弱性 - Qiita

    ※規約違反として限定公開にされました。Qiita運営からのメールに「Qiitaだけじゃなくて他サービスの規約違反もあかんのやで」という文言があったので、そのへんに気をつけて修正しました。 記事はすべてフィクションです。実在する企業とは一切関係ありません 焼肉サブスクに22日通った。 その中で、色々な脆弱性が見受けられたため、詳しく書く。 ※この記事で紹介する脆弱性を実際に突いてサービスを不正利用すると、詐欺罪に問われる可能性があるので、絶対にやらないこと。また、この記事は啓蒙を目的としており、システムの悪用を推奨していない。 焼肉サブスクのシステム サブスクプラットフォームに登録し、クレカでサブスクパスに課金する。 店でパスの画面を見せる。画面には1日1回だけ押せるボタンがあり、ボタンを店員の目の前で押すことで、サービス権を行使する。べ放題が無料になる 最後にレジで会計するが、べ放題

    焼肉サブスクの脆弱性 - Qiita
  • Jenkinsで複雑な処理をするときのjob構成について

    変数やビルド後の通知設定等が違うために、 ほぼ同じ内容のjobを15個ぐらい使っていたら、 だんだんと運用が死んできたのでメモ。 まとめ Jenkinsはプラグインの挙動を変えるのが難しいため、 ほぼ同じだけれど若干違う手順を行う必要がある場合、 似たようなjobが大量に並び、 手順の変更時などに全てのjobを変えきるのが辛くなります。 そこで、可能な限りビルド手順はスクリプトにするのと、 jobを種類別に細かく分け、 最上位のjobにはどの下流jobを実行するかだけを管理させることで、 複雑なjobでも変更に強くすることができるようになります。 前提条件 設定が全部で7種類ぐらいある 1ビルドはCPUをフルパワーで使って30分程度 一部の設定は定期実行やマージ毎でもビルドしたい 設定ごとに用途や使う頻度が違う為、定期実行タイミングは個別に設定したい ビルド後のデプロイ先や通知先、通知条件

  • 現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ

    この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY(クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0) で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです(これであなたもテスト駆動開発マスター!?和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します~現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd|CodeIQ MAGAZINE)。旧記事には当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出

    現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ
  • 1