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

Microsoftは本日、巨大なGitリポジトリを快適に管理するための専用ファイルシステム「GVFS(Git Virtual File System)」を発表しました(slashdot)。 GVFSはGitリポジトリを格納するための専用ファイルシステムで、リポジトリを仮想化し、巨大なリポジトリでも高速な動作を可能とすることを目指して開発されているものです(具体例としてあげられているWindowsのコードベースは350万件を超えるファイルが存在し、サイズは270GBを超えている模様)。 必要なファイルだけをダウンロードすることでcloneを高速化し、リポジトリの状態を積極的に管理することで、checkoutやstatusなどに必要な時間も短縮します。例えばcloneにかかる時間が12時間から数分に、checkoutは2〜3時間から30秒に、statsuは10分から4〜5秒に短縮されるとしてい

背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること

「Gitのブランチ構成どうしましょうか？」 「とりあえずdevelop切ってやっていきますね。」 そのdevelopブランチ本当に必要でしょうか。 developブランチだけ使われていて、masterが全く使われていなかったりしないでしょうか。 よく聞かれるブランチ戦略としてはgit-flowやGitHub Flow、、GitLab Flow等があります。 git-flowにおいてはdevelopやhotfix、releaseといったブランチがありますが、GitHub Flowにはmasterブランチと機能開発ブランチの2つしかありません。GitLab Flowはmasterを中心に開発を行い、productionブランチを安定させていくスタイルです。 実際に新しいプロジェクトを始めるとしたら、どの構成が良いのでしょうか。 今回はカウルを開発するにあたり採用したブランチの構成とその背景につ

断固としてコンピュータ言語を拒絶する 私の知っている最も一般的な .gitconfig は、ユーザ名の設定だけが記されたものです。そして、その次に一般的なものはこれです。 [alias] ci = commit cia = commit -a cam = commit --amend cama = commit --amend -a cl = clean cldf = clean -df res = reset resa = reset HEAD ... # 82 more 4-character aliases このコンフィグは、要するにあなたの頭の中のスペースをキーストロークに置き換えます。短縮コマンドのエイリアスを覚えれば、タイピング数の節約が可能です。しかし私はこれが好きではありません。私はタイプミスをしますし、睡眠不足なこともたまにあるので、このエイリアスではやりづらくなってしま

「Learn Git Branching」はGitの使い方をアニメーション付きで学べるサイトです。Gitを使い始めて間もない方には重宝するサイトだと思われます。Gitでいまどういったフローになっているかを視覚的に分かりやすく解説してくれます。ブラウザがあればいつでも学習できる点も助かりますね。 以下に使ってみた様子を載せておきます。まずLearn Git Branchingへアクセスしましょう。いくつかの学習項目が用意されていますので気になったものを選んで学習できますよ。 自分でコマンドを打って動作確認できます。間違えても大きな失敗にはなりませんので、安心して気軽に取り組めますね。Gitを学習し始めた方はもちろんのこと、そろそろ復習しておきたいなという方もおすすめできるサイトです。ぜひご活用ください。 Learn Git Branching （カメきち）

まえがき 私はGit好きの人間です。 もっと言えば、Gitを愛している（Git Lover）と言ってもいいくらいです。 そんな私がなぜこんなタイトルの記事をいまさら書こうと思ったかというと、 いまだにGitの便利さを知らず、Subversionを強い理由もなく使い続ける開発者が多いからです。 そんなわけで 「会社にGit/GitHubを導入するための説得する」 という目的でこの記事を書こうと思います。 Gitの良さってなんだろう？ 実は私もこれまで強く意識して考えたことはありませんでした。 Gitを使い出したら、 それがあるのが当たり前でGitなしの開発など考えられなくなっていたからです。 そういう意味では、Gitって 中世における自動車 に近いものがあるのかもしれません。 その時代、移動手段といえば馬が普通であり、 自動車などが普及するとは誰も考えなかったわけです（たぶん）。 それが今で

今まで TortoiseGit を使って SVN のノリでだましだまし使ってたけど、そろそろちゃんとコマンドを覚えようと。 環境 OS Windows 7 64bit SP1 インストール Git for Windows をインストールする。 リポジトリを作成する git init でカレントフォルダを Git のリポジトリにできる。 .git という名前の隠しフォルダが作成される。 カレントフォルダが、そのまま 作業ディレクトリ にもなる（SVN とちょっと違う）。 以下のようにフォルダ名を指定することもできる。

はじめに ソースコードを静的解析することでSRP（単一責任原則）を定量的に算出します．*1 svn blameによるSRP算出*2を参考に、git blameによる算出をshで行ってみました． このSRP値が最大のモジュールが王様モジュールに相当します． # 単一責務性の違反指数（SRP） # SRP＝R＋U＋((L/100)－5) # R：修正リビジョンのユニーク数 # U：修正ユーザのユニーク数 # L：モジュールのライン数 function get_SRP() { local target_filepath=$1 echo $(( \ $(git --no-pager blame --line-porcelain $target_filepath | sed -n 's/^summary //p' | sort | uniq -c | sort -rn | wc -l) + \ $(

もはや開発者のマストツールとなりつつある分散型のバージョン管理ソフト「Git」。柔軟性の高いツールですが、複雑なコマンド体系を持ち、初心者泣かせのツールでもあります。 本日紹介する「Git Cheat Sheet」は、Gitの基礎的な知識を一枚の画像にまとめたチートシートです。あらゆる機能を網羅とはいきませんが、Gitの勉強を始めた入門者の方なら参考になりそうな情報が凝縮されています。 チートシートには、リポジトリの作成から始まり、リポジトリの観察、ブランチの操作、変更管理、リモートリポジトリとの同期といったGit操作に欠かすことのできない操作がまとめられています。 ▲またWorking / Staging / Local Repository / Remote Repositoryという、Git特有の概念を分かりやすく理解することができる図表も掲載されています。 今年こそGitを使いこな

などにすごく時間がかかる、ということがあります。 いろいろ調べて、ある程度は改善できたので、メモ。 preloadindex 設定 こちらを元に

はじめに RubyのコミッターでもありRailsなどの多くのOSSで活躍されているMarc-André Lafortune さんのブログに面白い記事があったので筆を取りました. （許可は取りましたヨ） Why I Won't Squash My Commits *注釈 [...] で記された文章は原文には存在しない私の注釈であるので留意されたいです. 翻訳に至らない所があれば編集リクエスト待ってます. 要約 PR,feature単位でcommitをまとめるかどうかでRailsのプロジェクト上などで揉めた. それぞれのcommitは独立してるいるはずだからまとめる必要はない 仮にどうしてもまとめたいなら自分でやるべきだし人にその考え方を押し付けるな (まあ実際は皆いい人だから理解してくれるけど） この方は徹底してcommitを最小の変更単位で分けて、 それぞれが独立してテストを通るように心が

diff --git a/idol.js b/idol.js index bedbede..a17b5ec 100644 --- a/idol.js +++ b/idol.js @@ -3,11 +3,17 @@ var mongoose = require('mongoose'); var idolSchema = new Schema({ - name: String + name: { + first: String, + last: String + } }); var Idol = mongoose.model('Idol', idolSchema); var otome = new Idol({ - name: 'Otome Arisugawa' + name: { + first: 'Otome', + last: 'Arisugawa' + } }); otome.save

なにが嬉しいのか？ gitのbranchを楽に選択できる。 checkout, push, pullなどが楽にできる。 git checkoutをpecoで行うpecoの関数はあったのですが、 汎用的にしたいよなーと思いましたのでbranchのみを選択するスクリプトを書きました。 ソース function peco-branch () { local branch=$(git branch -a | peco | tr -d ' ' | tr -d '*') if [ -n "$branch" ]; then if [ -n "$LBUFFER" ]; then local new_left="${LBUFFER%\ } $branch" else local new_left="$branch" fi BUFFER=${new_left}${RBUFFER} CURSOR=${#new_

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

ウッ ここで詰まる事は往々にしてあります. 特に急いでる時の煩わしさは甚だしいです. どうせならそれっぽい英語を使いたいのでOSSや同僚のコミットメージの語彙の出現確率を調べてみましたら、 もちろんfeatureによってコミットメッセージの付け方など数多あるものの、一定の頻出パターンは見い出せたので筆を取りました. （英語勉強しないと..） 方法 github.com/rails/railsのコミットメッセージ内における各動詞の出現確率を求め、 またOSSと仕事でのコミットメッセージの趣向も変わってくる事も勘案するため、 （仕事でDeprecateとか滅多に使わんし） 同僚に聞きつつ10つあげてみた. 以下列挙 （例は実際の同僚やOSS上でのコミットメッセージです.） Add *A to *B AをBに加える

便利ですよね、stash。 普通に使ってるだけでも便利なんですが、知っておくと更にサクッと使いこなせるTipsをQ&A形式で紹介します。 おまけとして、Tipsで紹介したオプションを実現するstashの仕組みにもチラっと触れています。 Q. add済みなファイルだけゴニョゴニョしたいからnot stagedなファイルだけを退避しておきたい A. stash --keep-index (-k) オプションを使う 今の状況 ： add済みなファイルだけをゴニョゴニョしたいのにnot stagedなファイルがあって邪魔、ちょっと消えてて欲しい。 $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: bar # #

これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情

git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴

2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。