タグ

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

タグの絞り込みを解除

運用とqiitaに関するslay-tのブックマーク (9)

  • 要求定義と要件定義の違いを考える - Qiita

    要求定義と要件定義についての記事というのは需要があるようですね。 検索されるだけなのか？そもそも話し合いの中では、その「定義」を確定して、話しておくことが大事なのですよね。言語を学ぶ上で、まずはひらがなからカタカナからそしてローマ字など文字を学ぶように、プログラミング用語や現場で使う単語などというのは意識して使っていかないと追いつけなくなってしましますからね。 役割分担、期日を決めるなどマネージメントの方もプロジェクト進行では、考えていきたいですね。 ##最近の近況 バーチャルな世界に興味があり、バーチャルSNSなどにも顔を出しながら作業してます。 ##はじまり はぁ… なんでシステム開発が失敗するんだろう… 仕様の変更が多くて… 言った言ってないのトラブルから避けたい… システム動かしてみても全然使えない… 実は．． 事業運用をオペレーションレベルに展開しないままに、 システム開発をして

    要求定義と要件定義の違いを考える - Qiita

  • コンフリクトの解決を記録して再適用する git rerere - Qiita

    はじめに Git を使う場合、ブランチの作成とマージを頻繁に行うような運用が多いと思います。例えば、機能追加やバグ修正を行う場合には本流ブランチからトピックブランチを作成して、作業はトピックブランチにコミット、作業が終わったらトピックブランチを本流ブランチにマージ、といった運用です。 この場合、トピックブランチは細かい単位で作成して、作業が終わったらすぐマージする、というのが良いプラクティスであろうと思います。すぐマージすると、コンフリクトは起こらない場合が多いです。とはいえ、やはりコンフリクトが起こる場合はあります。 コンフリクトが起こる場合とは、feature/12345 ブランチを作成して作業して master ブランチにマージしようとしたところ、別の誰かによる変更が既に master ブランチに取り込まれており、しかもその変更箇所が feature/12345 ブランチでの変更箇所

    コンフリクトの解決を記録して再適用する git rerere - Qiita

  • クラウドエンジニア(AWS)ロードマップ2021 - Qiita

    お知らせ 2022年初頭に本記事を元にしたAWS書籍が技術評論社より全国出版決定いたしました。 関係者各位のご協力に深く感謝いたします。 タイトル：AWSエンジニア入門講座――学習ロードマップで体系的に学ぶ 本書籍出版までの制作プロセス、チーム執筆の方法論などをまとめました チームで技術書を出版して学べた共同執筆メソッド はじめに インフラ初学者がAWSを用いた設計・構築レベルに到達するため、学習の全体像をロードマップ図にまとめました。 背景 パブリッククラウド全盛期においてAWSは全エンジニアにとって「常識」となりました。 しかしながら、情報過多によってAWS学習に必要な情報がネット上のノイズに埋もれてしまい、初学者の直感による判断が誤った学習に行き着くこともあります。 このロードマップはAWS学習の全体像を俯瞰でき、パブリッククラウドを用いた設計・構築レベルに到達するまで導く体系的なス

    クラウドエンジニア(AWS)ロードマップ2021 - Qiita

  • ニコニコで12年運用した決済システムを移行する上で必要だったこと - Qiita

    はじめに 今日は、ニコニコのプレミアム会員サービスを支える「プレミアム課金システム」を動画システムのモノリスから切り出し、変更可能にしていった過程について書きます。プレミアム課金システムは金銭を扱うシステムですので、「（特に、失敗した）話を聞くのは面白いけど、自分で触りたくない」と思われる方も多いのではないでしょうか。 この記事では、決済にかかわるシステムでも一般的なシステム改善の方法が適用できることをお伝えしたいと思います。また、コストを抑えつつ着実なシステム改善を行う方法論としてもご理解していただけると嬉しく思います。 背景 プレミアム会員サービスについて 月額500円（税別）のプレミアム会員制度には159万人（2020年9月末現在）の方が加入してくださっており、ニコニコ事業を支える主要な有料サービスです。 ニコニコ動画は2006年にサービスを開始し、2007年にプレミアム会員サービス

    ニコニコで12年運用した決済システムを移行する上で必要だったこと - Qiita

  • Bolt for Python が FaaS での実行のために解決した課題 - Qiita

    Bolt とは & 自己紹介 近年、Slack のプラットフォーム機能開発チームは、Slack 連携アプリを作るための公式フレームワークである「Bolt（ボルト）」の開発と普及活動に力を入れています。私はこの Bolt の開発を担当しています（特に Python と Java は大部分を私が手がけたので、思い入れもひとしおです）。 Bolt を使うと Web API を使ってメッセージやファイルを投稿して通知するだけのシンプルな連携ではなく、ボタンやモーダルを活用したインタラクティブなアプリを簡単に作ることができます。また、そのような UI 部品を使わない場合でも、Bolt を使うと Events API の受信とリスナー関数の実装を非常に簡単に実装することができます。 今年のアドベントカレンダーは、まだそこそこ空きがあるようなので、埋まらなかった日については、この Bolt のノウハウを

    Bolt for Python が FaaS での実行のために解決した課題 - Qiita

  • プルリクに対して検証環境を自動で起動/終了するプログラムを作ったら、検証が捗った話 - Qiita

    記事の概要 GitHub Flowでの開発、つまり単純なプルリク運用での開発を、営業も巻き込んで実践したいと思い、そのような環境を作りました。その際、いくつか足りない機能を補うウェブアプリを作って公開したので、それに関する様々な話を書きます。 （実際にこのウェブアプリを使えるかどうかというよりは、似たようなフローで開発を改善できるといいなというような目的の話です。） ウェブアプリのリポジトリ このウェブアプリの使い方と機能については、一応README.mdに書いていますが、この記事では少し背景的な話も含めて順番に書きます。 issue対応やその他追加開発などは絶賛募集中です。 背景 開発に関するよくある課題 これまで、既存のウェブアプリ（サービス）の機能追加開発において、以下のような課題がありました。 検証が十分にできていない機能がある 追加した機能の使い方を十分にレクチャーできていない/

    プルリクに対して検証環境を自動で起動/終了するプログラムを作ったら、検証が捗った話 - Qiita

  • SSMのススメ〜運用自動化への一歩〜 - Qiita

    1.はじめに みなさん、運用業務の自動化は進んでいますか？ クラウドが一般的になってきてから運用の自動化がすごい勢いで進んできていますね。 先日私も運用自動化するために色々と試行錯誤をしているところ、「AWS Systems Manager(以下SSMと呼ぶ)」に出会いました。 AWSを使っている方へおすすめしたいので、今回はSSMについて書いていきます。 2.SSMとは？ SSMとは、オンプレ環境にも適応可能なインフラ管理ツールです。 AWS公式ドキュメントでは、SSMを以下のように紹介しています。 "AWS Systems Manager は、Amazon EC2 インスタンス、オンプレミスサーバーと仮想マシンや他の AWS リソースを大規模に設定および管理する機能のコレクションです。Systems Manager には、AWS リソース間で運用データを簡単に一元化し、タスクを自動化で

    SSMのススメ〜運用自動化への一歩〜 - Qiita

  • [EC2]サーバのリソース監視入門 - Qiita

    ■概要 AWSでEC2を使う際に、見ておく必要があるであろう項目を、洗い出して監視を実践する。 ■取っておきたいメトリクスについて ◆EC2を建てると標準で取得されるメトリクス一覧 「(公式)インスタンスの利用可能な CloudWatch メトリクスのリスト表示」に詳細が書いてあるが、一般的なアプリケーション監視に使う項目が標準ですべてとれるわけではない。 ※自分が運用/監視で標準メトリクスから使っている項目は下記くらい。

    [EC2]サーバのリソース監視入門 - Qiita

  • GitFlowをやめて本番リリースが楽になった話 - Qiita

    背景 サーバーサイド開発のプロジェクトでGitFlow(的な)運用を行っていたが、本番リリースの際に困ることがあったのでgitの運用フローを変えて解消したという話。 まず問題の内容から順番に書いているので、結論(新しい運用ルール)だけ知りたい人はこちら git運用フローについては、GitFlow・GitHub Flow・GitLab Flowなどが有名だがどれとも少し違うように思ったのでまとめた。 <2018/06/10追記> 新フローにも名前が欲しいと思っていたが、同じやり方を「GitFeatureFlow」と呼んでいる記事を見つけた。個人的にもしっくり来たのでこれからはこの呼称を使っていこうと思う。 cf. GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します </追記終わり> 導入プロジェクトの概要 採用するべき運用ルールはプロジェクトの条件にも依ると思う

    GitFlowをやめて本番リリースが楽になった話 - Qiita
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.