オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
GitHubの自分のリポジトリにpushするときに、SSHキーを使ってできるのだが、ちょっとハマったので、備忘録しておく。 ハマったポイントは、 1. ~/.ssh/id_rsa は、他の環境に使ってる 2. 先にGitHubでリポジトリ作ってそれをcloneした状態だった って感じかなー。 1は、id_rsaをGitHub用に使える場合、とくに問題にならないけど、私の場合は、色んなSSH環境に接続する手前、id_rsa_xxxみたいにファイル名で環境を管理してる。 ので、ハマった。 2は、GitHubからcloneしてくるときに、 ここからURLをclipして $ git clone https://github.com/... ってやってしまったもんですから、SSH接続にならないので、1をクリアしても結局、pushできないみたいなハマり方をした。 で、きちんと、整理して、以下の手順を実
ピクシブ株式会社 Advent Calendar 2016の時間です。今回はピクシブ株式会社でエンジニアをしている @catatsuy が担当します。今回は意外と書いてなかったのでGitLabを社内でどう運用しているかの話を書こうと思います。 GitLabとGitHub ピクシブ社内では以下の2つの方法でソースコードを管理しています。 自社でホストしているGitLab GitHub Organization それぞれ以下の特徴があります。 GitLabのメリット 自社でホストしているため、アメリカにサーバーがあるGitHubよりもgit cloneでリポジトリをダウンロードする場合などは速い オープンソースのプロジェクトのため、社内のサーバーにインストールするだけで使える ソースコードを読めば内部でやっていることが分かる ユーザー数やリポジトリ数などで料金がかからないため、気軽に使える G
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら: http://nvie.com/posts/a-successful-git-branching-model/ (翻訳の公開と画像の利用は本人より許諾済みです) このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト(仕事でもプライベートでも)で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
git-lesson.md git初心者への道 Level 1 まずやってみよう - コミットする、ログを見る、差分を見る 初登場するコマンド: init, add, commit, log, config, status, diff Level 2 もうちょっとやってみよう - helpを見る、履歴をたどる、.gitignore 初登場するコマンド: help, clean Level 3 やりなおしたり戻したりしてみよう - 修正を戻す、コミットを戻す、打ち消す 初登場するコマンド: reset, show, revert Level 4 ブランチをつくってみよう - ブランチを作る、マージする 初登場するコマンド: branch, tag, merge, cherry-pick, rebase Level 5 みんなでやろう - リモートリポジトリと同期する 初登場するコマンド: c
Frontrend Vol.6 powered by CyberAgent, Inc. http://frontrend.doorkeeper.jp/events/6907 で発表したプレゼン資料です。 こういう資料に対する投げ銭的なのがどうなるのか気になっていたので、もしよろしければ・・・!15円からできるソーシャルカンパサービスだそうですm(_ _)m http://kampa.me/t/dev
こんにちは、中川です。 Gitを使い始めてから、Subversionを使う機会がめっきり減ったこの頃です。 Gitだとローカルだけで簡単に使い始められるのもいいですが、気軽につくれるbranchや、mergeのしやすさがたまりませんね。 インストール直後の状態でも普通に利用できますが、 ちょっとした設定でさらに使いやすくなる方法をご紹介したいと思います。 ※今回ご紹介する内容はいずれも私のMacBook上での動作確認となり、Windows環境は考慮していませんがご容赦ください。 ■ユーザー名とE-mailアドレスの設定 まずは、最初にユーザ名と、メールアドレスを設定してしまいましょう。 $ git config --global user.name "yoshiki" $ git config --global user.email "yoshiki@example.com"
受託開発やっている、いまの開発スタイルを書く。 この前のブログはわりとフォーカスをしぼったはなしだったので、今回は簡単に全体のはなし。(書く順番が逆っぽい) 今回のプロジェクトではアーキテクトとして、この↓開発スタイルの構築と運用をしていて学び多い。 バージョン管理はGit プロジェクト用サーバーにGitBucketをたててソースコードを管理している。 オフショアと仕事をするなど、開発拠点がわかれることが多い。 ソースコードに対してロックをとったりしちゃうと、他の人が開発すすめられなくなるし、拠点別れて並行開発する大規模案件だからこそ、Gitを使う必要がある。 各開発者がブランチをきって開発をして、プルリクでレビュー依頼、からのマージをすることで、レビューが済んでいるソースしかmasterブランチに取り込まれない、というのもイイ。 弊社の”エンジニア”はみんな当たり前のようにGitを使って
絨毯爆撃pushの例 いまmasterブランチに、未プッシュのコミットがあるとします。 ここで、新たにbr1ブランチを作ってチェックアウトします。 $ git checkout -b br1 master $ git branch * br1 master br1ブランチでコミットを作ります。 echo hello >> hello.txt git add . git ci -m "add file" 引数なしでプッシュします。 git push すると、どこに何がpushされると思いますか? 実は、master -> masterにpushされます。 masterがまだpushできる状態でない場合、これはかなり痛い。すごく痛い。頭が頭痛でおなかが腹痛。 しかもpushしたかった当のbr1ブランチはpushされないというオチ。(リモートにbr1ブランチがない限りは) この挙動は大半のユーザ
世間的に「Gitはコミットログを書き換えられてキモい」と言われ、肩身が狭いので git-rebase の説明を書いてみた。 git help から引用 まずは基本に忠実に、ヘルプを読みましょう。 git help rebase SYNOPSIS git rebase [-i | --interactive] [options] [--onto <newbase>] <upstream> [<branch>] git rebase [-i | --interactive] [options] --onto <newbase> --root [<branch>] git rebase --continue | --skip | --abort DESCRIPTION If <branch> is specified, git rebase will perform an automatic g
git-merge の--ff, --no-ff, --squashの違いをまとめてみた。 git helpから引用 まずは、git helpを読みましょう git merge --helpから引用(抜粋) NAME git-merge - Join two or more development histories together SYNOPSIS git merge [-n] [--stat] [--no-commit] [--squash] [-s <strategy>] [-X <strategy-option>] [--[no-]rerere-autoupdate] [-m <msg>] <commit>... git merge <msg> HEAD <commit>... git merge --abort OPTIONS --ff, --no-ff Do not gene
The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available on Amazon.com. The version found here has been updated with corrections and additions from hundreds of contributors. If you see an error or have a s
MS Wordで書かれた原稿を電子書籍化する作業を行ったのですが、個人的には使い慣れたRe:VIEWで管理したいものです。 そこで、MS Wordをテキストファイル化してRe:VIEWファイルに書き換えることにしました。 docx2txtを使ってMS Wordをプレーンテキストに変換する ワードファイルのテキストをコピペしてテキストファイルに置き換えるのは流石に面倒ですし、ヒューマンエラーも発生しそうです。 そこで、何か良い方法はないかと思って、おもむろにGoogleで『docx2txt』と検索してみると、まったく同じ名前のソフトウェアを発見することができました。 Docx to Text convertor ページはややレトロですが、ツール自体はメンテナンスもされているようで、これを導入することにしました。 リポジトリ作成 まずはリポジトリの作成です。とりあえず、次のようなファイル配置を
Git は、元々 Linus Torvalds によって 2005 年に作られた、無料でオープンソースのバージョン管理システムです。他の SVN や CVS といった中央バージョン管理システムと違って、Git は分散型で、すべての開発者がローカル環境で彼らのコードのリポジトリの完全な履歴を持っています。これは、最初のリポジトリのクローン作成に時間がかかりますが、commit、blame、diff、merge、log といったこれに続く作業を劇的にスピードアップします。 Git は多くの革新的で強力なワークフローやツールにつながる、リポジトリ履歴のブランチ、マージ、および書き換えに非常に役立ちます。プル リクエストは、チームが Git ブランチでコラボレーションを行い、他のコードを効果的に見直すことができる、非常に人気のツールです。Git は現在世界で最も広く使用されているバージョン コント
バージョン管理ツールGitの基礎練習です。 Windows XPのコマンドプロンプトでGitの基本的なコマンドを動かしていきます。 Gitを学び始めるきっかけにどうぞ。 (筆者もまだGitを使いこなしているわけではありません。 誤りのご報告、改善提案などは大歓迎です。フィードバックからよろしくお願いします) 目次 はじめに ダウンロードとインストール ファイルをGitの管理下に置きましょう 新しいファイルを追加します 新しいディレクトリを追加します 編集からコミットまでの流れはこんな風に進みます ブランチを使ってみましょう ここまでの作業ログを見ましょう この文書に書かなかったこと 関連リンク 更新履歴 ぜひ、感想をお送りください はじめに Windows XPのコマンドプロンプトで、 バージョン管理ツールGitの基本的なコマンドを動かしてみましょう。 この文書の通りに実行すると、 基本的
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く