並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 15 件 / 15件

新着順 人気順

branchの検索結果1 - 15 件 / 15件

  • 美容内服薬ラボットメディカルクリニック【公式】

    オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。

      美容内服薬ラボットメディカルクリニック【公式】
    • ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)

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

      • GitHub上のsensitive dataを削除するための手順と道のり | メルカリエンジニアリング

        Advent Calendar day 7 担当の vvakame です。 予告では Apollo Federation Gateway Node.js実装についてポイント解説 としていましたが、社内各所のご協力によりAdvent Calendarの私の担当日に間に合う形で公開できる運びとなりました。そのため告知とは異なりますが GitHub上のsensitive data削除の手順と道のり をお届けしていきたいと思います。 メルペイVPoE hidekによるday 1の記事で振り返りがあったように、今年、弊社ではCodecovのBash Uploaderに係る情報流出という事案が発生しました。当該インシデント対応において、プレスリリースにも記載のある通り、ソースコード上に混入してしまった認証情報や一部個人情報などの機密性の高い情報(sensitive data)について調査を実施し、対応

          GitHub上のsensitive dataを削除するための手順と道のり | メルカリエンジニアリング
        • 仕様記述テクニック「Promotion」の紹介 - DeNA Testing Blog

          こんにちは、SWETの鈴木穂高(@hoddy3190)です。 私はこちらの記事に記載の通り、形式手法の可能性を模索しています。 現在はツールやゲームの仕様を形式的に記述すること(形式仕様記述)で、仕様の欠陥をなるべく早く見つける取り組みにチャレンジしています。 今回は仕様記述をするにあたりよく使う重要な記述テクニックである「Promotion」を紹介します。 形式仕様記述とAlloyというツールを知っている人を対象にしています。 もし形式仕様記述やAlloyをご存じない方は、以前私がbuilderscon tokyo 2019で発表したときに使った資料をご覧ください。 Promotionとは 一般にソフトウェアシステムは複数のコンポーネントから構成されます。 システム全体としての状態(以下、システム状態)は各コンポーネントの状態の組み合わせからなります。 たとえどんなに奥深くのどんなに小さ

            仕様記述テクニック「Promotion」の紹介 - DeNA Testing Blog
          • git の develop ブランチは必要なのか、またはリリースtagについて

            songmu @songmu feature branchか、feature flagかっていうのは実は結論のない話なんだろうな、とは思ってる。僕はfeature branchに慣れすぎてしまったけど 2019-10-26 15:32:59 Kazunori Otani @katzchang Gitのリポジトリ/ブランチ戦略で確実に言えそうなのは、「分岐した状態をできるだけ短くしよう」で、それを実現するためにはじつはGitだけの問題じゃなかったりするので、みなさんがんばっていきましょう。 2019-10-26 18:03:42

              git の develop ブランチは必要なのか、またはリリースtagについて
            • ひさしぶりにzshに戻りました - ちなみに

              仕事用のマシンをM1 MacBook Proに交換してもらったので、開発環境を整え直しました。 2年ほど fish を使ってきたのだけれど、普段は良いのだけれど、ちょっと自動化したくなったときに、やはりPOSIX準拠じゃないシェルはなかなか難しかった。macOSの標準も zsh になったことだし、久しぶりに戻ってみることにした。 導入 現代なので XDG Base Directory Specification に乗っかっておくことにする。 Arch Linux の Wiki がよくまとまっていて助かるのでこれを参考にして進めた。 zshの場合は ZDOTDIR を指定するといいのだけれど、これをどこで指定するのかという問題がある。zshの起動時に最初に読み込まれるユーザー設定は ~/.zshenv なのだけれど、ここに ZDOTDIR を書くということは .zshenv だけホームディレ

                ひさしぶりにzshに戻りました - ちなみに
              • Gitを使ってやらかした時、git reflogさえ使えればわりかしなんとかなる - Qiita

                これは何 新人プログラマ応援イベントの参加記事です。 gitにはreflogというコマンドがあります。このコマンドを学んでおくとやらかしちゃった時も大体なんとかなるので記事にします。 git reflogってなに? git reflogとは、Gitで操作履歴を見ることができるコマンドです。 例えば branch1にチェックアウト branch1でbranch1.txtを作成し、コミットを作る masterにチェックアウト をすると、以下のようなreflogになります。 $ git reflog 4a4125a (HEAD -> master) HEAD@{0}: checkout: moving from branch1 to master 826a9dc (branch1) HEAD@{1}: commit: Create branch1.txt 4a4125a (HEAD -> mas

                  Gitを使ってやらかした時、git reflogさえ使えればわりかしなんとかなる - Qiita
                • ちょっと複雑なシェルスクリプトをJavaScriptで書く - lacolaco-engineering

                  ちょっと複雑なシェルスクリプトを https://github.com/google/zx を使って書くとJavaScriptプログラマにとってはメンテナンスしやすい /lacolaco/lacolaco.iconはzx歴 3-4ヶ月ってところ (2021-08) 嬉しいところ async/awaitが使える 配列が扱いやすい モジュールで再利用しやすい 他のNode.jsライブラリと併用できる Prettierでフォーマットしやすい Lintしやすい エディタ支援が安心 Made by Google 微妙なところ JavaScriptプログラマ以外にとっては無用 とはいえシェルスクリプトによほど慣れてる人以外はよく整理されたJavaScriptのほうがセマンティクスを読み取りやすいのではないか スクリプト自体はこんな感じ(公式READMEより) code:js #!/usr/bin/en

                    ちょっと複雑なシェルスクリプトをJavaScriptで書く - lacolaco-engineering
                  • git checkout の代替としてリリースされた git switch と git restore - kakakakakku blog

                    2019年8月にリリースされた Git 2.23 から,Experimental(実験的機能)として新コマンド git switch と git restore が使える.今までずっと使ってきた git checkout は機能が多すぎたため,機能を分割し git checkout の代替としてリリースされた.個人的にリリースされてから,できる限り git switch と git restore を使うようにしてるけど,まだ無意識に git checkout を使ってしまうこともある.最近 git switch を教える機会があったため,ブログにまとめておく. github.blog なお,以下の検証は Git 2.26.0 を使った. $ git --version git version 2.26.0 1. git switch を使う git switch を使って「ブランチ操作」

                      git checkout の代替としてリリースされた git switch と git restore - kakakakakku blog
                    • 大規模リポジトリで高速にgit cloneするテクニック - DeNA Testing Blog

                      ニッチな話題ですが、業務におけるCI/CDの現場では避けることのできない大規模リポジトリと戦うためのgit cloneのテクニックを紹介します。 この記事はDeNA Advent Calendar 2020の10日目の記事です。 CI/CDマニアの@Kesin11です。SWETではCI/CDチームの一員として、CI/CDの啓蒙活動やJenkinsを必要とするチームのサポートなどの業務を行っています。 はじめに おそらくどこの会社でも1つぐらいは巨大なリポジトリが存在しているかと思いますが、歴史あるリポジトリはgit cloneするだけで数分を要し、checkout後のリポジトリサイズがGB単位になることも珍しくないでしょう。業務で古くから存在するプロジェクトのリポジトリを触ったことがある方はきっと経験があるかと思います。 git cloneを実行するのは最初のセットアップ時だけなのであまり

                        大規模リポジトリで高速にgit cloneするテクニック - DeNA Testing Blog
                      • GitHub、これから作成するリポジトリのデフォルトブランチ名が「main」に。「master」から「main」へ変更

                        GitHubは、これから新規に作成されるリポジトリのデフォルトブランチ名が「main」になると発表しました。これまでデフォルトブランチ名は「master」でした。 既存のリポジトリにはこの変更は適用されませんが、年内にも既存のリポジトリでもデフォルトブランチ名の変更を可能にする予定だと説明されています。下記は「The default branch for newly-created repositories is now main」からの引用です。 Existing repositories are not impacted by this change. Later this year, you'll be able to rename the default branch for existing repositories for your user, organization, or

                          GitHub、これから作成するリポジトリのデフォルトブランチ名が「main」に。「master」から「main」へ変更
                        • インテルとARMのCPUに脆弱性「Spectre-v2」の悪夢再び、新たな攻撃手法

                          2017年、インテルやARMのCPUに情報窃取の脆弱性が存在することが明らかになった。通常、CPUのプロセスはほかのプロセスの処理しているデータを読み取ることはできない仕組みになっているが、ある機能を悪用することで実行中のプロセスから本来は入手できてはいけないデータを窃取できることが明らかになった。この仕組みを悪用して複数の攻撃手法が開発されたが、「Spectre-v2 (またはBTI: Branch Target Injectio)」と呼ばれる手法が最も危険な攻撃方法と認識されている。 これら脆弱性に対して、オペレーティングシステム側が対策を導入したほか、CPUメーカーがハードウェア緩和策(eIBRSやCSV2など)を導入した。この緩和策は意図した通りに機能するが、どうやら研究者はこの攻撃手法を復活させることに成功したようだ。 研究者らは「Branch History Injection

                            インテルとARMのCPUに脆弱性「Spectre-v2」の悪夢再び、新たな攻撃手法
                          • branch を寝かせるときは TODO.txt を置いている - id:onk のはてなブログ

                            タイトルがすべて。 思いついたら手を動かしてしまう性質なので、秘蔵のブランチを大量に持っている。 秘蔵のブランチというのは、動いたけどチームメンバーを説得するのが面倒とか、テスト書くのが面倒とか、だいたい動いているけどやりきるのが面倒とかで main にマージしていないヤツ。 例えばフレームワークのメジャーバージョン上げるブランチとか、依存ライブラリをより一般的/現代的なものに交換するブランチや、より良い設計を思いついたのでガッと書き換えてしまうブランチが多いかな。 だいたい 1 年所属していると 80 ブランチぐらい溜まるので、週 1 つ以上は何か作りかけてる計算になる。 ローカルブランチの数、プロンプトに出しておくかな……。(秘蔵のブランチが溜まってる— Takafumi ONAKA (@onk) March 28, 2017 もちろん自分でいいアイディアだと思っているから実装している

                              branch を寝かせるときは TODO.txt を置いている - id:onk のはてなブログ
                            • Python最新バージョン対応!より良い型ヒントの書き方 | gihyo.jp

                              寺田 学です。9月の「Python Monthly Topics」は、Python 3.5で導入され、多くの場面で活用されている型ヒント(Type Hints)について、より良い型ヒントの書き方を紹介します。 Pythonの型ヒントとは Pythonは動的型付け言語です。型を指定せずに変数宣言できますし、関数の引数や戻り値に型を宣言する必要はありません。 Python 3.5(2015年9月リリース)で型ヒントの仕組みが入りました。型の指定が不要なPythonですが、型ヒントを付けることで、「⁠コードの可読性向上⁠」⁠、「⁠IDEコード補完の充実⁠」⁠、「⁠静的型チェックの実行」といった静的型付け言語のようなメリットを得ることができます。 Pythonの型ヒントは以下のように記述します。 name: str = "氏名" # 変数nameをstr型と宣言 def f(arg: int) -

                                Python最新バージョン対応!より良い型ヒントの書き方 | gihyo.jp
                              • WebKit on GitHub!

                                On June 23rd, the WebKit project froze its Subversion tree and transitioned management and interaction with our source code to git on GitHub. Why git? git’s distributed nature makes it easy for not just multiple developers, but multiple organizations to collaborate on a single project. git’s local record of changes makes moving commits between branches or reverting changes simple and quick. git’s

                                  WebKit on GitHub!
                                1