タグ

関連タグで絞り込む (292)

タグの絞り込みを解除

developmentに関するshimookaのブックマーク (731)

  • 分散キューという名の苦しみ - Software Transactional Memo

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

    分散キューという名の苦しみ - Software Transactional Memo
  • モノリス分割はこうやる!「How to break a Monolith into Microservices」を読んだ - kakakakakku blog

    研修中に「マイクロサービス」の解説をしていると,たまに「モノリス分割」に関する質問が出てディスカッションをすることがある.当然ながら万能な分割アプローチはないけど,例えば DDD (Domain-driven design) などのアプローチを選択するなど,選択肢はいろいろある.そして最近「モノリス分割」に役立つアプローチを紹介した martinfowler.com の記事「How to break a Monolith into Microservices」を読んだ. 具体的には以下の「計8種類」のアプローチが紹介されている.原著を翻訳するのではなく,あくまで個人的なメモとしてまとめる.なお,日語も個人的に載せているため,参考程度にしてもらればと! Warm Up with a Simple and Fairly Decoupled Capability(シンプルかつ分離された機能で準

    モノリス分割はこうやる!「How to break a Monolith into Microservices」を読んだ - kakakakakku blog
  • レガシーおじさん、SPAを始めてみた。そして限界を知る

    はじめに 最近、Webの記事を見てるとReactVue.jsばかりが上がっていてJSPやERBの話をしてる人は誰もいません。jQueryの記事ももちろん見ない。 つまり、Webだけ見る限りではほとんどの人がSPAを使ってるように見えます。 私はWeb界隈には居るもののどちらかというとバックエンド寄り、もっというとそもそもWebとか関係ない領域を見る事が多いので、ちょっとキャッチアップを兼ねていくつかの個人プロダクトにVue.jsを採用してみました。 jQueryくらいで頭が止まってたので。サーバサイドもマイクロサービスでAPI化が進んでるのでフロントもそれに合った技術を選ばないとですしね。 というわけで、今回はその中で得た知見というか、従来型のサーバサイドでのWeb開発をしていた人の視点でVue.jsをキャッチアップする流れで書いていきたいと思います。 まあ最終的な結論は正直「これすごく

    レガシーおじさん、SPAを始めてみた。そして限界を知る
  • PHP-CS-Fixer Configurator

  • 【PHP】CS-Fixerの整形をGithub Actionsで自動化するぞ。 - ポンコツエンジニアのごじゃっぺ開発日記。

    Github Actionsを使うといろんな作業が自動化できます。また、PHP-CS-Fixerを使うと、PHPのソースコードを定義したフォーマット(コーディング規約)に合わせて整形してくれます。 ということで、今回は、「コミットごとにPHP-CS-Fixerの整形をGithub Actionsで自動化すること」を実現したいと思います。 PHP-CS-Fixerのインストール まずは導入したいと思います。 composer require friendsofphp/php-cs-fixer --dev だけと簡単ですね。 $ composer require friendsofphp/php-cs-fixer --dev Using version ^2.16 for friendsofphp/php-cs-fixer ./composer.json has been updated Lo

    【PHP】CS-Fixerの整形をGithub Actionsで自動化するぞ。 - ポンコツエンジニアのごじゃっぺ開発日記。
  • PHP-CS-FixerとGit フックで治安保持活動 - Qiita

    こちらはJoolen Advent Calendar 2019 8日目の記事です。 カレンダーのURLはこちら Joolen Advent Calendar 2019 まえがき PHPを書いてるとコーディング規約とか守らない人出てきますよね。 私も気付かず破ってしまうことがあります。 それを防ぐためにPHP-CS-FixerとGitフックを利用して治安保持を目指します。 PHP-CS-Fixerとは コードの整形ツールと呼ばれるものです。 .php_cs.distという設定ファイルにルールを記述することで、コマンド一つでルールに沿ったコードに整形してくれます。 ルールはPHPの配列形式で設定します。 またFinderと呼ばれるものもあり、こちらを設定すると、整形して欲しくないファイルやディレクトリを指定できます。 例: return PhpCsFixer\Config::create()

    PHP-CS-FixerとGit フックで治安保持活動 - Qiita
  • どんなエディタでもEditorConfigを使ってコードの統一性を高める - Qiita

    よくある会話として下のようなものがありますよね。 「ソフトタブですか?ハードタブですか?」 「インデントはいくつですか?」 ※ソフトタブはタブが半角スペースで、ハードタブはタブがタブ。 そんなものはエディタの設定で統一すればよいからと。頭を悩ませる理由がわからないと。 と、思うんですよね。ひとりで作業しているときはね。 現状、私の周りで何が起きたかというと。 PhpStormVim信者 Atom使いたい派 なぜかときどきSublimeText使う派 と、なってくるわけですね。 エディタ毎に設定していってもよいんですけど、プロジェクト毎にどうのこうのしなきゃいけなくてめんどう。 結果 コードがグッチャグチャになって人間関係までグッチャグチャ となるわけですね。 人をイライラさせたければソフトタブのところにハードタブぶち込んだり、タブ4で統一しているところに2をぶち込めばよくて。簡単だね!

    どんなエディタでもEditorConfigを使ってコードの統一性を高める - Qiita
  • 良いコードの書き方 - Qiita

    概要 チームによる継続的開発を前提としたコーディングのガイドライン。 特定の言語を対象としたものではないが、主に静的型付けのオブジェクト指向言語を想定している。 サンプルコードは別段の定めがなければSwiftで記載。 ガイドラインの目的 生産性を高め、メンテナンスコストを下げる バグが生まれづらくする 開発メンバー(特に新規参加者)がコードを理解しやすくする 初心者プログラマー教育 内容の説明 タイトルの頭についた【数字】は重要度。 高いほどシステムに与える影響が大きいが、低いものの方が影響が小さく改修しやすいものが多い。 【5】変数のスコープを小さくする 変わり得る値は複雑さを生み誤解やバグに繋がるため、プログラムは変数が少ないほど問題が生まれづらい。 プログラミングの大原則として、変数は必要最低限を心がけ、むやみに増やさないようにする。 また、変数はスコープや寿命が大きいほど悪影響が

    良いコードの書き方 - Qiita
  • テストコードが増えるとバグは減るのだろうか? / Does more test code mean fewer bugs? - Speaker Deck

    Transcript ςετίʔυ͕૿͑Δͱόά͸ݮΔͷͩΖ͏͔ʁ�� ʮ���ˠ������ʯͰݟ͑ͨੈքͷ࿩� גࣜձࣾ;0;0ςΫϊϩδʔζ� ;0;0508/෦�J04νʔϜ� ໊औ�߂ฏ Copyright © ZOZO Technologies, Inc. © ZOZO Technologies, Inc. גࣜձࣾ;0;0ςΫϊϩδʔζ� ;0;0508/෦� J04νʔϜ ໊औ�߂ฏ 2019೥2݄ΑΓݱ৬ɻ ZOZOTOWN iOSΞϓϦͷ։ൃΛ͍ͯ͠·͢ɻ झຯͰݸਓ։ൃ΋ɻ 2 © ZOZO Technologies, Inc. 3 ���ˠ������ ʹ ͜ͷ�೥΄ͲͰ૿Ճͨ͠ςετΧόϨοδͷׂ߹ © ZOZO Technologies, Inc. 4 ���ˠ������ ����� ˞ܭଌର৅͸͜ͷ�೥ͷ։ൃͰؔ༩ͨ͠ϑΝΠϧʹߜ͍ͬͯΔ © ZOZO Te

    テストコードが増えるとバグは減るのだろうか? / Does more test code mean fewer bugs? - Speaker Deck
  • PHPでダウンロードさせるファイル名がIEで文字化けする件 - Qiita

    問題はどんな言語で書いても起こることですが、たまたま仕事PHPつかってたときにぶつかったのでメモしておきます。 結論 HTTPのレスポンスヘッダで Content-Disposition: attachment; filename*=UTF-8''URLエンコードされたファイル名を送ってあげる。 追記 2017/11/02: Edgeでも通用するようです。https://github.com/netcommons/NetCommons2/issues/126 ファイル名が化ける PHPでファイルアップローダをつくっていました。 動作確認はUbuntu 14.04のFirefox30をつかっていましたが、社内ではIE11がデフォ。「一応やっとくか」とIE11で動かしたら、日語のファイル名が見事に化けました。 またお前か、IE!チキショー Slim Frameworkをつかっているので、こ

    PHPでダウンロードさせるファイル名がIEで文字化けする件 - Qiita
  • 何故お役所ってオワコンIEが大好きなの?|楠 正憲(デジタル庁統括官)

    普通は役所のシステムって構築してから5年とか7年は塩漬けにして使うもので、一度やらかしてしまうと名誉挽回の機会なんて向こう数年は与えられないんだけど、こと件に関しては高市総務大臣から「今すぐ私がマニュアルなしでも使えるように直しなさい」と叱責いただいて、しっかりと予算的なサポートも得られたことで、たったの数ヶ月で立て直すことができた。 この数ヶ月は外部のセキュリティやPKIの専門家の方から様々なサポートをいただいて何とか実現したんだけれども、役所のシステム開発としては非常識というか、極めて難易度が高い案件だった。「え?単にChromeやSafariをサポートするだけでしょ、難しい訳ないじゃん」と思う諸兄は、もうしばらくこの話に付き合って欲しい。 もともとマイナポータルは日を代表するITベンダーと通信キャリアの3社が開発したんだけど、大臣からの叱責を受け「ちゃんとお金を払うから直してよ」

    何故お役所ってオワコンIEが大好きなの?|楠 正憲(デジタル庁統括官)
  • ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)

    https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン

  • フロントエンド開発の3ステップ(npmことはじめ) - Qiita

    スライド 当記事は以前勉強会でLTしたものです。 スライドは下記にあります。 フロントエンド覚えること多すぎ問題 モダンなフロントエンド開発で、入門記事を探そうとすると、 まずwebpackTypeScript, Babelによるビルド環境構築から始まる記事が多くヒットします。 ですが、Node.jsの初心者がいきなり複数のツールを習得しようとすることが 挫折の原因になっていると感じています。 ですので、まずNode.jsをインストールした直後から、必ず使うことになる、 npmの機能をまず覚えておきましょう。 フロントエンド開発で覚えるべき3つのコマンド 以下の3つだけ覚えておきましょう。 npm init npm install npm run これだけ覚えれば、ひとまずフロントエンド開発を進めることができます。 完璧なワークフローを構築するのは、書いているアプリが大きくなってきてから

    フロントエンド開発の3ステップ(npmことはじめ) - Qiita
  • mailtrapを利用してメール送信のテスト - Qiita

    メール送信テスト用のサービス 開発環境でのメール送信テストで,わざわざメーラとかを見に行ったり,余計なテストメールが増えて後で整理する(消す)のが面倒です. 送信できればOKのテストでは以下の無料のサービスを利用しています. アカウントの登録は,メール,GithubGoogleのいずれで可能です. 使い方 アカウント登録後,Inboxができるので,そちらのSMTP設定をのぞいてみます. そうするとユーザIDやパスワード,HOSTなどが記載されており,また言語ごとのサンプルも記載されています. ■設定 SMTP Host: smtp.mailtrap.io Port: 25 or 465 or 2525 Username: ************* Password: ************* Auth: PLAIN, LOGIN and CRAM-MD5 TLS: Optional

    mailtrapを利用してメール送信のテスト - Qiita
  • 質とスピード(2020春版) / Quality and Speed 2020 Spring Edition

    質とスピード(2020春版) 2020/02/13 @ デブサミ2020

    質とスピード(2020春版) / Quality and Speed 2020 Spring Edition
  • メンバーに恨まれそうな3つのコードレビュー施策を徹底したら、逆にメンバーが爆速で成長した話 - Qiita

    ある程度経験を積んだレビュワーがやりがちな失敗は、 指摘しやすいコーディング規約違反だけ指摘している というもの。 コードレビューで指摘するべき欠陥とは、必ずしも規約違反だけではなく、 仕様考慮もれや機能的なバグ、非機能的なセキュリティやパフォーマンス上の問題点も含まれる。 一つ関数に対して複数の視点でソースチェックをしないといけないが、 人間は同時に複数のことは考えられない。 そこでどうすればいいかと情報をあさっていたところ、 われらがIPAがセキュアプログラミング講座というWEBページで、 四回に分けてレビューすることを提唱していた。 1回目はどこに何があるか、 2回目は可読性が確保されているか、規約にのっとっているか 3回目は機能性 4回目はセキュリティ といった具合である。 IPAの講座では4回目はセキュリティに限定しているが、 担当していたプロダクトは、非機能面はセキュリティはも

    メンバーに恨まれそうな3つのコードレビュー施策を徹底したら、逆にメンバーが爆速で成長した話 - Qiita
  • 脱・CSS無法地帯。FLOCSSで指針のある設計を。 - Qiita

    FLOCSSの導入事例の共有 2017年の6月にリニューアルした転職ナビ、 最も大変だった事の一つはFLOCSSの導入でした。 FLOCSS命名規則にMindBEMdingを採用 ファイル・ディレクトリ構成を定義 カスケーディングと詳細度の管理方法にも言及 という特徴をもった、CSS設計指針です。 FLOCSSのドキュメントは世に数有るけれども導入事例や知見がもう少し欲しかったなと。 こちらの記事では転職ナビがFLOCSSを導入した時のお話をさせていただきます。 そもそも「CSS設計ってなんやねん」って方は、手前味噌ではございますが、よろしければこちらの記事をどうぞ。 CSS設計を勉強するならまずこれを見たら良いかも CSS設計で解決したかった課題 そもそも転職ナビのCSS設計を再定義することで解決したかった課題は2つあります。 オレオレになりがちな命名規則 プレフィックス

    脱・CSS無法地帯。FLOCSSで指針のある設計を。 - Qiita
  • 要件定義~システム設計ができる人材になれる記事 - Qiita

    はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの?」 「要件定義ってなに?」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に4つも壁が存在するのです。 そのため、記事では実装(プログラミング)を開始する前に必要となる、 『企画~設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装(プログラミング)に使用する時間

    要件定義~システム設計ができる人材になれる記事 - Qiita
  • リーダブルアーキテクチャ - usecaseにおける時間軸と抽象度の統一 - Qiita

    はじめに Clean Architectureやレイヤードアーキテクチャでは、どのようにレイヤーを定義するかついては言及されています。 そのような中usecase(レイヤードアーキテクチャではApplication層)をどのように実装するべきかについての議論は少ないです。 しかし私はリーダブルなアーキテクチャを実現するために、一番大切なことはusecaseを適切に実装することであると考えています。 そこでusecaseを実装する上で起こりがちな抽象度の問題を例に、リーダブルなアーキテクチャを考えいていきたいと思います。 サンプル 1:1のチャットアプリでUserとWorkerが存在して会話ができるアプリを例にあげます。 以下の図では青い背景はinfraの関数実行、緑色の背景はdomainの関数実行、赤い背景はusecaseの関数実行を示しています。 usecaseのCreateChat関数

    リーダブルアーキテクチャ - usecaseにおける時間軸と抽象度の統一 - Qiita
  • [和訳] Dropboxアカウントのせいで胃潰瘍になった - Qiita

    こちらのReddit投稿 (https://www.reddit.com/r/sysadmin/comments/eaphr8/a_dropbox_account_gave_me_stomach_ulcers/) の和訳記事です。番環境でやらかしかった人シリーズが盛り上がっていたので波に乗って(?)Twitterにヤバすぎる恐ろしい話が流れてきたのをすかさず和訳してみました。やらかしちゃった人というよりはやらかされちゃった人目線ですがいずれにせよそこら辺の怪談話よりよっぽど怖いです。 Dropboxのアカウントのせいで胃潰瘍になった。 皆は誰もが触れたがらない、会社を紐やガムやクリップでつなぎとめている「例のアレ」を見つけたことってある?そういうのって往々にして大型連休前の金曜午後4:45に落ちるし、般若のような様相を呈した上司が「このままだと第二のスターリングラード攻防戦が勃発するぞ

    [和訳] Dropboxアカウントのせいで胃潰瘍になった - Qiita