並び順

ブックマーク数

期間指定

  • から
  • まで

281 - 320 件 / 5932件

新着順 人気順

CIの検索結果281 - 320 件 / 5932件

  • GitHub Actions のベストプラクティス

    1 フロー 1 ワークフロー 一連のフローがある場合は 1 つのワークフローにまとめる。 トリガーしたイベントの JSON が使える needs での制御がしやすい 全体を追える グラフが表示される ファイルを分割したい ファイルを分割したい理由として以下が挙げられると思います。 行数が増えて読みづらい 処理を共通化したい 複合実行ステップアクション や workflow_run トリガー や Reusable workflow 🆕 を使うことになると思いますが、基本的には一連のフロー制御はメインのファイルに書いてその下を Reusable workflow や複合実行ステップアクションで外部ファイルへ分離するのが良さそう。 workflow_run はログが分断するのでおすすめしません。

      GitHub Actions のベストプラクティス
    • Google、継続的デリバリに対応したデプロイ自動化ツール「Spinnaker 1.0」正式発表。GCE/GKEだけでなく、AWS、Azure、OpenStackなどマルチクラウド対応 - Publickey

      Google、継続的デリバリに対応したデプロイ自動化ツール「Spinnaker 1.0」リリースを発表。GCE/GKEだけでなく、AWS、Azure、OpenStackなどマルチクラウド対応 SpinnakerはもともとNetflixが開発し、2015年にオープンソースとして最初のバージョンを公開しています。 参考:Netflix、マルチクラウド対応の継続的デリバリを実現する「Spinnaker」をオープンソースで公開 このときすでにNetflixの開発にGoogleは参加しており、その後もSpinnakerの開発が進められてきました。 Spinnakerはデプロイに求められるほとんどすべての機能を備えていると、次のように説明されています。 In Spinnaker, deployments are orchestrated using custom release pipelines,

        Google、継続的デリバリに対応したデプロイ自動化ツール「Spinnaker 1.0」正式発表。GCE/GKEだけでなく、AWS、Azure、OpenStackなどマルチクラウド対応 - Publickey
      • テストを使いサービス開発を駆動していくために取り組んでいること - クックパッド開発者ブログ

        技術部の松尾(@Kazu_cocoa)です。 最近、 @moroや私を中心に、テストから開発を駆動するという方向で、とある活動を始めました。その活動の中では、 @t_wadaさん を 技術顧問 として巻き込んで活動を進めています。そんな取り組みを少しここにまとめます。 取り組みの前段階 先日、私はテストエンジニアというロールに焦点を当ててテストという言葉に対する2種類の話をいたしました。TDDのようにテストによって開発を駆動していく側面の話と、人の認知・感じ方に寄った仕様自体含めてテストしていく側面の話です。 クックパッドエンジニアトークナイト 〜クックパッドテストエンジニアのあり方〜 を開催しました! クックパッドエンジニアトークナイト 〜クックパッドテストエンジニアvol.2 Testing編〜 を開催しました! その際、会の傍でt_wadaさんらと私たちが開発するWebアプリケーショ

          テストを使いサービス開発を駆動していくために取り組んでいること - クックパッド開発者ブログ
        • 最近やってるRailsプロジェクトのテスト方法 - #詰んでる日記

          Railsエンジニアになってから1年半くらいが経ち、社内のRailsのプロジェクトを全部で5つくらい触って、今やってるAbilie*1でようやく人並みにテストを書いてる気がしてきたので、現時点でやってるテストの方法をまとめておく。 テストのルール的なの rspecでは必ずモデルのテストは書くようにしてる。ヘルパーも大体書いてるけど、コントローラやルーティングのテストはあまり書いてない。 というのも、コントローラーのコードを極力短くしてモデルを太らせているのでコントローラのテストはあんまり意味が無い気がしていて、その代わりにCapybaraでテストを書いておけば十分なんじゃないかなと思ってきたから。Capybaraは書いてるので、そういう意味では書いてるとも言える。 社内の管理者だけが使える管理画面も作ってるけど、そっちはテストあんまり書いてない。ここは動かなくなっても一般ユーザーには影響が

            最近やってるRailsプロジェクトのテスト方法 - #詰んでる日記
          • Terraform + GitHub + CircleCI + Atlasを利用してAWSの操作を自動化した - Glide Note

            TL;DR Terraform + GitHub + CircleCI + Atlas を用いてAWSの操作を自動化した 各ツールの役割は下記のような感じ Terraform => インフラへの変更ツール GitHub => .tfファイルのバージョン管理 CircleCI => CI、Terraformをawsに対して実行 Atlas => インフラの状態を記録するterraform.tfstateの管理 インフラの継続的デリバリー - naoyaのはてなダイアリーにて、言及されていた範囲(Route53の変更、Chefの適用)をAWSの操作全体に拡大した 背景 今までの問題点 AWSの各種操作がブラウザからポチポチ業… 手作業なので誤操作に気づきにくい。事故りやすい インフラの実構成がバージョン管理出来ていない ちなみにRoute53に関してはroadworkerを用いてコードで管理済

            • Webアプリケーションのテストを書くときに考えていること - 車輪を再発明 / koba04の日記

              テストを書く目的 自分の書いたコードが意図した通りに動いてるか確認するために書くのですが、自分が楽をするためと他の人のために書いてます。 自分が楽するため Webアプリの場合、実装した機能がちゃんと動作するかを確認するために何度もブラウザポチポチしてというのは時間がかかります。なのでその回数をなるべく減らすためにテストとして書けるところはなるべくテストで確認して、ブラウザポチポチする回数を必要最低限にしたいと思っています。 ブラウザポチポチするのも立派なテストだと思っています。再現性のない。 他の人のため テストがないと他の人がその機能に関連する機能を変更しようとした時に変更の影響がないのか確認することが出来ず、その機能に対するテストを手動で行わせてしまうことになってしまいます。 テスト書く時間がない問題 テストの話をすると書く時間がないと言われたりしますが、既存の開発の流れにテスト書くこ

                Webアプリケーションのテストを書くときに考えていること - 車輪を再発明 / koba04の日記
              • 『Programming Windows 8 Apps』 の第1章を翻訳しました - Windows 開発統括部 Blog - Site Home - MSDN Blogs

                In Visual Studio 2022 17.10 Preview 2, we’ve introduced some UX updates and usability improvements to the Connection Manager. With these updates we provide a more seamless experience when connecting to remote systems and/or debugging failed connections. Please install the latest Preview to try it out. Read on to learn what the Connection ...

                  『Programming Windows 8 Apps』 の第1章を翻訳しました - Windows 開発統括部 Blog - Site Home - MSDN Blogs
                • Jenkins がもっと便利になるおすすめプラグイン 8 つ

                  こんにちは、開発担当の松本です。 今回は、Jenkins にたくさんあるプラグインの中からおすすめのプラグインをいくつか紹介します。 ジョブ一覧にアイコンを追加できる: Custom Job Icon 今年8月にリリースされた比較的新しいプラグイン。名前の通りプロジェクトごとにアイコンを登録できて、それがプロジェクト一覧に表示されるようにできます。 利用するには、プラグインインストール後にアイコンを登録する必要があります。 「Jenkins の管理」→「システムの設定」ページに「Custom icons」セクションが追加されていますので、そこでファイルを追加しておきます。追加しても「Refresh icon list」をクリックしないと表示が更新されない点に注意。 なお、画像の拡大縮小あまりきれいに行われないので、アイコンのサイズは 24 x 24 にしておくのがよいみたいです。 アイコン

                    Jenkins がもっと便利になるおすすめプラグイン 8 つ
                  • AWS Lambda(Python) の開発環境・テスト・デプロイ・CI 考察 | DevelopersIO

                    作るもの ヒーローを管理する Lambda Function を書きます。ヒーロー情報は DynamoDB の ヒーローテーブルに格納するものとします。リポジトリは以下。 * Python Lambda SAM + SAM Local Project コーディング作業 すべてはコードを書くところから始めます。いきなりプロジェクトルートにファイルを置いて書き始めるのも良いですが、後々テストやデプロイも行うことになるので少し整理してみます。以下のようにしました。 . ├── buildspec.yml ├── deploy.sh ├── docker-compose.yml ├── environments │   ├── common.sh │   └── sam-local.json ├── integration_test.sh ├── requirements.txt ├── src

                      AWS Lambda(Python) の開発環境・テスト・デプロイ・CI 考察 | DevelopersIO
                    • 【翻訳記事】デプロイ戦略の定義 - そこに仁義はあるのか(仮)

                      この記事は2017/11の以下のブログ記事の翻訳です。 blog.itaysk.com まずはじめに、翻訳を快く許可していただいた@itayskさんに感謝いたします。 3年前の記事ですが、デプロイ戦略についてここまで網羅的にまとめられた記事が日本語で見つけられなかったので翻訳してみようと思いました。 初めての翻訳記事であり、かつ翻訳時に多少の意訳を含んでいます。私の翻訳ミスがある可能性も十分にご了承ください。 何か間違いやわかりにくいところがあれば、コメントいただけますと幸いです。 無謀なデプロイ (Reckless Deployment) ローリングアップグレード (Rolling Upgrade) ヘルスチェックと監視 ロールバック 後方互換性 ちなみに ブルーグリーンデプロイ (Blue/Green Deployment) ドレイン スイッチバック ステージ ちなみに カナリアデプロ

                        【翻訳記事】デプロイ戦略の定義 - そこに仁義はあるのか(仮)
                      • 3分でできる!最高のDockerfileを書いたあとにやるべき1つのこと - Qiita

                        概要 Dockerfileを書くためのベストプラクティスを読んで、ベストプラクティスなDockerfileを作った/作りたい人が対象です。 そのDockerfileで大丈夫かを3分でチェックできるツールをつくりました。Hadolintのような、単なるDockerfileのLinterではなく、ビルドしたイメージの中身まで細かく分析します。 通常のLinterでは原理的に不可能な、ベースイメージに存在している危険性も含めて調べることができます。 ←GitHubのStarもらえると嬉しいです。 Dockleの内部で使われているツールはTrivy, Vulsなどと同じなので、そのあたりを踏まえて、動作原理を別記事にまとめました。 人を震えさせるツール「Dockle」の仕組みを解説 なお、DockerHubで人気のコンテナに対して試した結果をサイトにして公開しています。操作方法もふくめて、別記事に

                          3分でできる!最高のDockerfileを書いたあとにやるべき1つのこと - Qiita
                        • CEDEC2014 「ライブラリを作ってはいけない ~それでも作りたいあなたへのアドバイス~」

                          社内ライブラリを8年間に渡って作り、サポートし続けてきた講演者が、1~2年で完成するだろうという当初の想定とは裏腹に、なかなか進まない作業、得られないサポート、バグの押し付け合い、それら数々の修羅場から得られた、技術面およびサポート面でのノウハウをお伝えします。 http://cedec.cesa.or.jp/2014/session/ENG/8073.html ※2014/9/4にCEDEC2014@パシフィコ横浜で行った講演です。Read less

                            CEDEC2014 「ライブラリを作ってはいけない ~それでも作りたいあなたへのアドバイス~」
                          • マイクロソフトの責任者が語る「われわれはどのようにソフトウェアをテストしているか?」 JaSST'12 Tokyo

                            マイクロソフトの責任者が語る「われわれはどのようにソフトウェアをテストしているか?」 JaSST'12 Tokyo ソフトウェアのテストに関わるエンジニアが集まる国内最大のイベント「ソフトウェアテストシンポジウム JaSST'12 Tokyo」が1月25日、26日の2日間、都内で開催されました。 10周年を迎えた今回のイベントの基調講演を行ったのが、開発しているソフトウェアの規模、分野、種類において世界最大の企業、マイクロソフトのプリンシパル テストリードのBj Rollison氏。 「How We Test At Microsoft(マイクロソフトでどのようにテストをしているのか?)」という題で、同社がどのようなソフトウェアテストを行っているのかを中心に講演を行いました。講演の内容をダイジェストで紹介しましょう。 開発者とテスターはほぼ同数 マイクロソフト プリンシパル テストリードのB

                              マイクロソフトの責任者が語る「われわれはどのようにソフトウェアをテストしているか?」 JaSST'12 Tokyo
                            • 実践 Pact:マイクロサービス時代のテストツール - クックパッド開発者ブログ

                              技術部の taiki45 です。 以前「サービス分割時の複雑性に対処する: テスト戦略の話」という記事で、サービス間のインテグレーションテストにおける問題について紹介しました。現在のクックパッドではこの問題の解決のために Pact というツールを導入して運用しています。この記事では、その運用の知見を紹介できればと思います。 Pact Pact は Consumer-Driven Contract testing (CDC testing) を実現するためのツールです。"Consumer"、"Provider" という見慣れない単語が出てきますが、この記事ではだいたい「Consumer = Web API クライアント」、「Provider = Web API サーバー」と対応ができます。この記事では具体的な Pact の利用例を通じて CDC testing がどういうものなのかについても

                                実践 Pact:マイクロサービス時代のテストツール - クックパッド開発者ブログ
                              • 今日からはじめるCI/CD ─ CircleCI + Deployerでテストとデプロイを自動化しよう!【休日個人開発】|ハイクラス転職・求人情報サイト AMBI(アンビ)

                                今日からはじめるCI/CD ─ CircleCI + Deployerでテストとデプロイを自動化しよう!【休日個人開発】 プライベートでも何か作りたい! そんなときの「今日からはじめる休日個人開発」シリーズ、今回はテストやデプロイをGitHubと連携し、自動化させてCI/CDに対応します。 皆さん、プライベートで何か開発していますか? 「何か作りたい」という気持ちはあるものの、いまひとつ何から始めたらいいのか分からず、動けないままの人も多いと思います。 そんな皆さんのために、「仕事以外にも休日に個人で気軽に何かを作ってみよう!」という企画の第3回です。第1回で用意した開発環境と、第2回で作成した画像を加工するツールを用いて、テストとデプロイの自動化を行います。 これまでの休日個人開発シリーズでは、Webアプリケーションを動作させる本番環境にログインし、動作しているファイルを直接修正して開発

                                  今日からはじめるCI/CD ─ CircleCI + Deployerでテストとデプロイを自動化しよう!【休日個人開発】|ハイクラス転職・求人情報サイト AMBI(アンビ)
                                • 40通り以上の自動マルチブラウザテストをSelenium x CircleCI x BrowserStackで実現する| PLAID engineer blog

                                  CircleCI上で、BrowserStackを利用したマルチブラウザJavascript Test,Selenium Test を実現している方法についてご紹介します。Selenium webdriver, CircleCI, BrowserStack

                                    40通り以上の自動マルチブラウザテストをSelenium x CircleCI x BrowserStackで実現する| PLAID engineer blog
                                  • あなたのWeb開発人生を変えるYeoman、Bower、Yoのインストールと使い方

                                    連載目次 前回記事「Gruntで独自タスクを定義し、独自プラグインをnpmモジュールとして作成・公開するには」では、Gruntを使っていろいろな手法でタスクを定義する手法や、独自プラグインを作成してnpmで公開する方法について解説しました。 今回は少し角度を変えて、Gruntを自身の機能として利用しており、快適な開発ワークフローを提供してくれるツール、「Yeoman」について解説します。 3つのツールを統合したワークフローを提供する「Yeoman」 Yeomanとは、公式サイトいわく、「The web's scaffolding tool for modern webapps」とのことです。 訳すと、「今風のWebアプリのための土台/基盤を作ってくれるツール」といったところでしょうか。「scaffolding」はRuby on Railsの主要機能として有名になった言葉で、コマンドを打つだ

                                      あなたのWeb開発人生を変えるYeoman、Bower、Yoのインストールと使い方
                                    • 大規模 Web サービスの ブラウザテスト自動化・高速化

                                      https://atnd.org/events/66159 で実施したプレゼン資料

                                        大規模 Web サービスの ブラウザテスト自動化・高速化
                                      • Great Fonts for Web 2.0

                                        Apache/2.4.29 (Ubuntu) Server at modernlifeisrubbish.co.uk Port 443

                                        • いまからでも間に合う開発者テスト - mixi engineer blog

                                          はじめまして。開発部じゃない加藤和良です。 最近、mixi では Buildbot をつかった継続的インテグレーションをはじめています。安定版の mixi のソースコードにコミットすると Buildbot がそれを検知し、自動的にテストが走るようになりました。 ここでの「テスト」は Test::Simple や prove(1) をつかった、Perl でかかれた開発者テストを指しています。mixi の開発者テストをとりまく環境は、ここ数年でかなり改善されました。今回はその歩みをふりかえりながら、テストの無いコードベースをどこからどうやって変えていったかという話をしたいと思います。 開発環境 はじめに、前提となる mixi の開発環境について説明します。mixi では複数人の開発者がひとつのマシンで作業を行います。それぞれの開発者は、あらかじめ割り当てられたポートで Apache を起動し、

                                            いまからでも間に合う開発者テスト - mixi engineer blog
                                          • テスト書きすぎ問題 - hitode909の日記

                                            テスト書きすぎるとよくないって言ってる人がいた.DHHっていう人.作業時間の1/3以上テストしてたらおかしいとか,ActiveRecordのバリデーションなど,Railsの機能はテストしない,とか. Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で,テスト手抜き派の人に良い材料を与えてしまった.僕は意見ちがって,作業時間半分以上はテスト書いたりしてる. テストたくさん書くと,最初に書くときのコストは増える.けど,あとから読む時や,変更したい時には,読むだけだし,書くのも差分だけで良い.コード本体を理解できれば,要らないテスト捨てるのは,落ちたのを消すだけだから簡単.あとで見て,テスト足りないと分かったときに,明文化されてない仕様からテストを補う

                                              テスト書きすぎ問題 - hitode909の日記
                                            • 変化の時代で勝つための開発組織のあり方 2011 12-22

                                              How Modding Made Bethesda Better: GDC 2015 Level Design in a DayJoel Burgess

                                                変化の時代で勝つための開発組織のあり方 2011 12-22
                                              • 月刊『美術手帖』 最新のアート&アーティスト情報・展覧会情報・評論を掲載

                                                bijutsu.co.jp へアクセスいただきありがとうございます。 bijutsu.co.jp ドメインは現在、株式会社 美術出版エデュケーショナルが所有しております。 かつて存在した美術出版グループの情報については以下をご覧ください。 旧・美術出版ホールディングス 株式会社 美術出版ホールディングスは、現在は活動しておりません。 旧・美術出版社 株式会社 美術出版社は現在、カルチュア・コンビニエンス・クラブ 株式会社のグループ会社として活動しております。詳しい情報は株式会社美術出版社のウェブサイトをご覧ください。 旧・美術出版ネットワークス 株式会社 美術出版ネットワークスは一部事業を株式会社 D2Cソリューションズへ譲渡し、現在は活動を休止しております。 旧・美術出版サービスセンター 2016年9月1日より株式会社 美術出版エデュケーショナルに商号を変更いたしました。旧美術出版グルー

                                                • レガシーコード改善勉強会 開催レポート

                                                  ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog ヤフー株式会社の有地です。 9/27(土)の昼から6時間にもわたり、さまざまな視点から「レガシーコード」について知識を深めるための勉強会を開催いたしました。 「そもそも正しい仕様を知っている人がいない」 「システムのブラックボックス化が留まるところを知らない」 こんな不条理なレガシーコード(テストコードが無いコード)と日々戦うエンジニアも多いことと思います。 今あるレガシーコードをどうやって保守・改善していけばよいのかという課題に本気で取り組んでいる、または取り組みたいと考えている大勢の方々に参加していただきました。 <開催趣旨・目的> テストコードが無いプロダクションコードをレガシーコードと定義し、テストコードによって保護され、

                                                    レガシーコード改善勉強会 開催レポート
                                                  • 社内用GitHub Actionsのセキュリティガイドラインを公開します | メルカリエンジニアリング

                                                    この記事は、Merpay Tech Openness Month 2023 の4日目の記事です。 こんにちは。メルコインのバックエンドエンジニアの@goroです。 はじめに このGitHub Actionsのセキュリティガイドラインは、社内でGithub Actionsの利用に先駆け、社内有志によって検討されました。「GitHub Actionsを使うにあたりどういった点に留意すれば最低限の安全性を確保できるか学習してもらいたい」「定期的に本ドキュメントを見返してもらい自分たちのリポジトリーが安全な状態になっているか点検する際に役立ててもらいたい」という思いに基づいて作成されています。 今回はそんなガイドラインの一部を、社外の方々にも役立つと思い公開することにしました。 ガイドラインにおける目標 このガイドラインは事前に2段階の目標を設定して作成されています。まず第1に「常に達成したいこと

                                                      社内用GitHub Actionsのセキュリティガイドラインを公開します | メルカリエンジニアリング
                                                    • Webページを監視して表示崩れが起きていないか検出できるE2Eテストを実装しました | PSYENCE:MEDIA

                                                      お世話になります、フロントエンド担当をしている小原正大です。Webページの表示を監視して差異があった場合、どのページで表示の変化が起きているかを知ることが出来るプログラムを実装したのでそのことについて書こうと思います。 何につかったの? 僕がフロントエンドを担当しているサービス『料理サプリ』で大規模なフロントエンドコードのリファクタリング行う際に表示テストを自動化するために作成しました。『料理サプリ』はPC・スマホ合わせて大体350-400ページの表示パターンが存在する比較的規模の大きいサイトです。全ページに影響を与えるような作業は大規模な回収となり、今回のリファクタリングでは表示テストの計画などの段取りが必要でした。従来の人手によるQAでは細かいバグを見過ごしたり時間がかかり効率が悪いので、可能な限り自動化しようと考え実装しました。 実装の概要 この監視のシステムは以下の2つ実装を組合わ

                                                        Webページを監視して表示崩れが起きていないか検出できるE2Eテストを実装しました | PSYENCE:MEDIA
                                                      • 自分がロゴデザインをするときに意識していること

                                                        友人であるフリーエンジニアの原さんが、ある日クラウドソーシングのランサーズでこんな依頼を出していました。 Web制作個人事業主のWebサイトロゴの依頼/外注/仕事 | クラウドソーシング「ランサーズ」 ランサーズでロゴを募集してみたの雑記- I.I.S ブログ 原さんには日頃いろいろ仕事を振ってもらったり一緒に野球を見に行ったりと、公私ともに大変お世話になっております。 コンペ形式というのもあり、賑やかしの足しにでもなればと自分もひとつデザイン案を作ってみることにしました。 せっかくですので、これをネタに自分なりのロゴデザインの手順、ポイントをまとめてみます。 1: クライアントの希望を確認 クライアントがロゴにどういうイメージを持たせたいのかを念入りにヒアリングします(当たり前ですけど)。 ロゴは、その会社・サービスの指針を表すものであると同時に、それが使われる全ての媒体(ウェブサイト、

                                                          自分がロゴデザインをするときに意識していること
                                                        • UIテストの自動化!Node.jsとSeleniumでWebアプリのUIテスト環境構築 – ICS MEDIA

                                                          Webアプリケーションを開発する際、みなさんはどのようにテストを行っていますか? Webアプリケーションは、ユーザーごとに異なるブラウザを使用しており、ユーザー操作も必要となるため、手作業でテストをされている方も多いと思います。また、機能改修やバグフィクス後に、リグレッションテスト(改修により既存機能への影響がないかを確認する回帰テスト)が必要となりますが、時間が取れずしっかりとテストができていない方も多いのではないでしょうか。 本記事では、これらのテストを自動化することのできる「Selenium Webdriver」(セレニウム ウェブドライバー)について紹介します。 入力フォームのバリデーション機能をチェックするデモ 簡単な入力フォームのバリデーション機能をチェックするデモを動画で紹介しましょう。入力値に対して期待するエラー文言が表示されているかのテストを実施しています。Seleniu

                                                            UIテストの自動化!Node.jsとSeleniumでWebアプリのUIテスト環境構築 – ICS MEDIA
                                                          • 私のソースコードの書き方 - @kyanny's blog

                                                            note.mu なるほど自分も同じような感じでやっているなぁ、と思った。もうちょっと詳しく書くと、 まず変更しようと思っている部分の周辺のコードを読んで、「ここらへんをいじればよさそう」と当たりをつける(当たりのつけかたにもいろいろあるのだが後述) 土地勘を養ったところで具体的な変更の仕方を考える。必要に応じて紙に下手くそな図を書いたり、考えを箇条書きにしたり、実際にコードを試しに変更してみたりする この方針でいけそう、と道筋が見えたらいよいよコードを書き始める。細かい単位でコミットするかどうかは場合によるが、少なくとも git add はこまめに行う(エディタの undo でせっかく書いたコードを失わないため) 道筋が見えなかったり、プロトタイプ的に書いたコードが望み薄そうだったら潔く諦める。煮詰まっていることを自覚して、コーヒーを買いにいったり、オフィスの外を散歩したりして頭をリフレッ

                                                              私のソースコードの書き方 - @kyanny's blog
                                                            • かっこ悪くて面倒でもテストコードを書こう - 今川館

                                                              Python | 10:08わたしはプログラマーではありませんが、いくつかの仕事でテストコードを見たり書いたりすることがあったので、その過程で思ったことをメモとして残しておきます。コーディングとテストを分けて工数を言う癖をやめようどっちもコードを書くのだから分けて考える必要はないテストコードの重要性は理解しているけど、工数も厳しいし客がテストコードを書くことに工数を割くことを認めてくれない。ありがちな話ですが、それがテストを書かないことの根拠であるならば少し考え直しましょう。コーディングとテストを異なる工程と考えるのをやめてしまえばそんなことに悩む必要はなくなります。つまり、「テストを書きながらコーディングする」のです。だいたい、普段プログラムを書いているときだって手元で動かしながらものを作っているでしょう。それと同じことをプログラムを書いてやればいいだけです。客がテストを書かせてくれない

                                                              • 「金融機関等コンピュータシステムの安全対策基準」(FISC 安全対策基準)に対する Azure の対応状況リストを公開 - MSDN Blogs

                                                                In Visual Studio 2022 17.10 Preview 2, we’ve introduced some UX updates and usability improvements to the Connection Manager. With these updates we provide a more seamless experience when connecting to remote systems and/or debugging failed connections. Please install the latest Preview to try it out. Read on to learn what the Connection ...

                                                                  「金融機関等コンピュータシステムの安全対策基準」(FISC 安全対策基準)に対する Azure の対応状況リストを公開 - MSDN Blogs
                                                                • Framer — The internet is your canvas

                                                                  Use powerful yet familiar tools to create your ultimate website design. Import your designs from Figma.

                                                                    Framer — The internet is your canvas
                                                                  • 「最強」のチームを「造る」技術基盤

                                                                    「最強」のチームを「造る」技術基盤 Presentation Transcript 「最強」のチームを 「造る」技術基盤 Nov/09/2013 Hiroyuki Ito IT Department, Rakuten, Inc. http://www.rakuten.co.jp/ Hiroyuki Ito (伊藤 宏幸、The Hiro) 情報技術部 プロセス・品質課 テスト駆動開発グループ @hageyahhoo 2 アジャイルコーチとして、 開発現場を日々サポートさせていただいています。 3 造る = 栽培する・耕す 4 CI/CD TDD ATDD この3つを軸にした チーム造りについてお話します。 5 Agenda 1. チーム造りの背景 2. 1st Stage : CI/CD 3. 2nd Stage : TDD for Android 4. 3rd Stage : ATDD

                                                                    • ふつうのユニットテストのための7つのルール - ブログなんだよもん

                                                                      最近、久しぶりにコードレビューをすることが増えたのですが、UnitTestのコードを見るとヒドイ部分が多く残念な気持ちになることもあります。 原因のひとつとして、プロダクトコードと違いテストの書き方をあまり書き方を明文化してなかったのが悪かったなと思い、とりあえず明文化してみました。 今回は、命名規則とかそのレベルまではいかず「ユニットテストかくあるべし」ってところまでをまとめます。正直、これ守ってくれたらあとは好みの世界もあるしね。 追記: テクニカルな部分も最低限ですがQiitaに記載しました。 qiita.com 追記: もうちょっと大上段の規約に関してもまとめてみました。 koduki.hatenablog.com 前提 ここではユニットテストを関数レベルのテストをJUnitのような自動テストツールで取り扱う場合に限定します。 また、Mavenでビルド時は常にテストを回すことを想定

                                                                        ふつうのユニットテストのための7つのルール - ブログなんだよもん
                                                                      • rsyncの悲劇 〜本番環境を消し飛ばす前に覚えておきたいこと〜

                                                                        この記事は本番環境でやらかしちゃった人 Advent Calendar 2019 17日目の記事です。 はじめまして、ダーシノ(@bc_rikko)です。 突然ですが、懺悔します。 私は転職して10ヶ月で2回も本番環境をぶっ飛ばしました。お客様をはじめ、関係各位には多大なるご迷惑をおかけしたことを、ここでお詫び申し上げます。 1回目は2015年11月27日、入社27日目のこと。 gitの設定ミスにより壊れたブランチをmasterにforce pushしてしまい、CIが流れて本番環境が壊れた。原因はpush.defaultなのだが、詳しくはすでに記事を書いているのでそちらを読んでほしい。 2回目は翌年9月1日、入社してちょうど10ヶ月たった日のことだ。 またしても本番環境をぶっ飛ばした。しかも、前回より盛大に……。 タイトルにもあるようにrsyncコマンドが原因だ。 当記事では、この「rsy

                                                                          rsyncの悲劇 〜本番環境を消し飛ばす前に覚えておきたいこと〜
                                                                        • DockerでのNodeアプリ構築で学んだこと | POSTD

                                                                          以下に紹介するのは、 Docker を使って node.js 用のWebアプリケーションを開発、およびデプロイする際に、私が四苦八苦しながら学んだ秘訣やコツです。 このチュートリアル記事では、Dockerで socket.ioのチャットサンプル を白紙の状態から本番状態へとセットアップしていきます。このプロセスを通じて、そうした秘訣などを簡単に習得していただければ幸いです。特に、以下のような内容について見ていきます。 実際にDockerでNodeアプリケーションを起動する。 すべてをrootとして実行させない(悪いやり方です)。 開発時のテスト-編集-リロードサイクルを短くするため、バインドを使用する。 再構築を高速にするため、 node_modules をコンテナで管理する(これには秘訣があります)。 npm shrinkwrap で、ビルドを反復可能にする。 開発環境と本番環境で Do

                                                                            DockerでのNodeアプリ構築で学んだこと | POSTD
                                                                          • FREE Logo Maker - FREE Logo Creator - FREE Online Logo Design

                                                                            Make a free logo design in minutes. LogoMaker can make your big idea a beautiful reality.

                                                                              FREE Logo Maker - FREE Logo Creator - FREE Online Logo Design
                                                                            • WantedlyではどうやってiOSアプリ開発しているのか - Wantedly Engineer Blog

                                                                              こんにちは!エンジニアの川崎です。 先週行われた Consumer Service Engineer MeetUp Vol.1 ~iOS編~ というイベントで「WantedlyではどうやってiOSアプリ開発しているのか」というテーマで発表してきました。 僕自身の普段の担当は、全体の設計やサーバ側の開発、プロジェクト進行あたりなので、 今回はWantedlyでiOSアプリを「プロトタイピング」し「開発」そして「テスト」するまでで使ってるツール・取り組みをざっくり紹介させていただきました。 意外とこの手の話をする機会はいままでなかったので、 現在開発中のアプリも含め、今現在うちでは何をどうやっているのかまとめられてよかったかなと思います。 以下、発表で紹介したURLなどです。 プロトタイピング ホワイトボードでアイデアだし moqupsでモックアップ作成 Popを使って実機でプロトタイプを触っ

                                                                                WantedlyではどうやってiOSアプリ開発しているのか - Wantedly Engineer Blog
                                                                              • Redmine, git, Jenkinsの状態を横断的かつリアルタイムに表示する『Dashbozu』をリリースしました。 - みずぴー日記

                                                                                Redmine, git, Jenkins などプロジェクト管理ツールの状態を横断的かつリアルタイムに表示するWebアプリ『Dashbozu』を作りました。 これを使えば、一つの画面でプロジェクトの”今”の状態を把握できます。 WebSocketを用いているので、ただ開いているだけで、次々と情報を得ることができます。 iPadで開きっぱなしにして、机の上に置いておくような使い方を想定しています。 なぜこれを作ったか 一般的なソフトウェア開発現場では Redmineでチケットを作成する gitでコミットを繰り返し、中央レポジトリにpushする JenkinsによるCIが実行される 結果を確認し、Redmineのチケットを閉じる という流れで作業が進んでいきます。 これらの作業の中で、開発者は「適切な」タイミングでチェックとフィードバックをすることを求められます。 例えば、チェックのタイミング

                                                                                  Redmine, git, Jenkinsの状態を横断的かつリアルタイムに表示する『Dashbozu』をリリースしました。 - みずぴー日記
                                                                                • お手軽に静的サイトを構築する - Qiita

                                                                                  後はcontent以下のディレクトリにMarkdown形式でファイルを置いていったりするだけです。 Themeも用意されており、簡単に導入できます。 hugoの導入は以下が詳しいです。 Hugo | Quick Start サイトを生成する hugo コマンドを実行することで、public以下に生成されます。 S3に設置する public以下に生成されたサイトを設置します。 パブリックアクセスを許可したS3 bucketを設置し、public以下をコピーします。 その後、プロパティからStatic website hostingを有効にします。 東京リージョンに設置した場合、以下のbucket名を置き換えることでアクセス出来るはずです。 https://[bucket_name].s3-website-ap-northeast-1.amazonaws.com CloudFrontを通す C

                                                                                    お手軽に静的サイトを構築する - Qiita