オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
![美容内服薬ラボットメディカルクリニック【公式】](https://cdn-ak-scissors.b.st-hatena.com/image/square/e98b45ce37be757a963053a513195e519b607084/height=288;version=1;width=512/https%3A%2F%2Flabot.jp%2Fwp-content%2Fthemes%2Fcocoon-master%2Fscreenshot.jpg)
オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
はじめに 一年前に新人研修でGitを担当してTigの記事を書いたのですが,今年も同じくGitの研修を担当することになりました.新人さんたちにとってはターミナル環境はとっつきにくい人も多いようで,短い研修期間では操作自体に苦戦してしまい,Gitそのものを理解するというところに力を割けない人も少なくありませんでした. それを踏まえて今回はGUIで操作しやすい環境を検討したのですが,以下のポイントを踏まえてVSCodeを使うことに決めました. マルチプラットフォームで使える.(研修はWindows環境で行いますが,業務ではLinuxデスクトップ環境も使うので) Gitの基本的な内容はVSCode上でGUI操作が可能. Gitの内容とあわせて,プログラミング用のテキストエディタの一例として,導入しやすそうなVSCodeを紹介. VSCodeを使ったGitの基本的な操作を一通りまとめていきます. イ
世の中の小説作家と編集者は今すぐ Word や G Suite を窓から投げ捨てて Git と GitHub の使い方を覚えるべきだGitGitHub小説 タイトルは釣りではありません。 最近、小説の執筆にあたって Git を導入して原稿の進捗履歴を管理しました。めちゃくちゃ便利でした。 GitHub を使って友人と一緒に校正校閲の作業をしました。めちゃくちゃ捗りました。 短編 SF 小説が短期間で完成しました。でも広告が目的ではないのでリンクは貼りません。 Git のことを何も知らない奴が Git と GitHub の使い方を覚えたら便利だったし捗ったので、記事にしてしまおうぜという試みです。 2019年1月4日 追記 本記事は「執筆」および「校正・校閲」の段階における Git と GitHub の有用性を主張する記事です。 「組版」や「デザイン」の段階における Git の有用性について
2. 自己紹介 • 本名:宮原 徹 • 1972年1月 神奈川県生まれ • 1994年3月 中央大学法学部法律学科卒業 • 1994年4月 日本オラクル株式会社入社 – PCサーバ向けRDBMS製品マーケティングに従事 – Linux版Oracle8の日本市場向け出荷に貢献 • 2000年3月 株式会社デジタルデザイン 東京支社長および株 式会社アクアリウムコンピューター 代表取締役社長に就任 – 2000年6月 (株)デジタルデザイン、ナスダック・ジャパン上場(4764) • 2001年1月 株式会社びぎねっと 設立 • 2006年12月 日本仮想化技術株式会社 設立 • 2008年10月 IPA「日本OSS貢献者賞」受賞 • 2009年10月 日中韓OSSアワード 「特別貢献賞」受賞 • ガンダム勉強会主宰・好きなモビルスーツはアッガイ 2 4. 日本仮想化技術株式会社 概要 • 社名
背景 サーバーサイド開発のプロジェクトでGitFlow(的な)運用を行っていたが、本番リリースの際に困ることがあったのでgitの運用フローを変えて解消したという話。 まず問題の内容から順番に書いているので、結論(新しい運用ルール)だけ知りたい人はこちら git運用フローについては、GitFlow・GitHub Flow・GitLab Flowなどが有名だがどれとも少し違うように思ったのでまとめた。 <2018/06/10追記> 新フローにも名前が欲しいと思っていたが、同じやり方を「GitFeatureFlow」と呼んでいる記事を見つけた。個人的にもしっくり来たのでこれからはこの呼称を使っていこうと思う。 cf. GitFlowは使わない!シンプルな「GitFeatureFlow」を紹介します </追記終わり> 導入プロジェクトの概要 採用するべき運用ルールはプロジェクトの条件にも依ると思う
2019年7月にGitHubにマージしたブランチが自動削除される機能が入ったためこの記事は内容の非推奨です。 Automatically delete head branches of pull requests - GitHub Changelog ブランチの自動的削除を管理する - GitHub Docs 以下は古い記述 前置き マージ済のブランチは基本的に消しても問題ないので、GitHub上には進行中のブランチだけがあるきれいな状態に保ちたいところ。 PRをマージした後にブランチを消すボタンが出るんですが、チームで開発してるとどうしても消し忘れる人が1人はいるので 1CircleCIで定期的に消すようにしました 前提 GitHub CircleCI 2.0 準備 GitHubにpushするための権限が必要なので「Settings -> Checkout SSH keys」でuser
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
初めに LinusによるGitのinitial commitのREADMEの訳です。 社内のSVNからの移行を促すために資料を整備していたのですが、SVNでやっていたことを移し替えたりコマンドを覚えたりするより内部構造を知ったほうが早いことに気づきました。 それで、gitの内部構造についての解説資料を色々見ていたのですが、データ構造については原作者のこのREADMEに言い尽くされている気がします。のみならず、gitを使うものが抱くべき精神性のようなものが示されており、深い感銘を覚えました(ヒャッハー)。 README: ”GIT - 馬鹿コンテンツトラッカー” コミットメッセージ:git, 地獄からきたインフォメーションマネージャ gitの意味 "git" は何を意味することも出来る、お前の気分次第だ。 3文字で、発音可能で、実際のUNIXシステムで共通コマンドとして使われていないものであ
Gitの良さがいまだに分からないという人がいるようなので、Git派の一人としてSubversion(以下SVN)と比較してのGitの良さ(メリット)について語りたい。 (GitとSVNの違いについては他の人の記事に詳しいのであまり書いていない一方、勢い余ってGitのデメリットも書いた。) 本題に入る前に、冒頭にリンクを貼った記事についてひとつだけつっこんでおく。 つっこみどころは他にも沢山あるけど。 ※話の前提としてgitとSVNを採用している現場に下記のような割と違いがあるとする。 git イシューごとにブランチを切り、ローカルでコミットして、リモートブランチにpushして、GitHub・GitLab・Bitbucket経由でマージリクエスト。コードレビューの後にマージ。 SVN リモートのtrunkに個々人が直接コミット。コードレビューはあまりない。ブランチを切ることもない。 このよう
ここ2年ぐらいで俺が働いた現場はみんなgitを採用している。就職エージェントと面談するときもgit経験の有無をよく訊かれるし、今ではVSSやCVSどころか、SVNですら時代遅れになってきて、SVNを使っている現場は「レベルが低い」「保守的・旧態依然」という雰囲気すら感じる。 俺としては4-5年前からgit(GitHub)を使っているし、gitを使うこと自体に抵抗はない。一通りの基本操作はできるし、人並みにはできると言っても差し支えはない。 …が、正直gitの良さがあまり見えてこない。 もし俺が中規模以上のプロジェクトのリリースを本格的に管理する側であれば全然違った感想を持ったかもしれない。でも一人の開発者として、せいぜい10人程度のプロジェクトで利用する限り、「gitで良かった」という状況があまり思い当たらない。 ではgitの何が気に食わないのか書いていきたい。 ①gitは馬鹿には難しい
動機 ExcelファイルをGitで管理しているときに、差分を見られると嬉しい。Git for Windows (msysgit)は、WordファイルやPDFファイルは差分を見られるように設定済で配布されているが、Excelファイルについては未対応。 できたこと git diffでExcelファイルに加えた変更を確認してからgit commitできる もちろん過去の履歴の差分も見られる 行頭にシート名が含まれていて複数シートにも対応している CUIでのExcelファイルの差分表示例 GUI (Git Extensions)でのExcelファイルの差分表示例 超便利!!! 使ったもの Git for Windows (msysgit) version 1.8.4.msysgit.0 Go 1.4.2 git-xlsx-textconv ab71fc84ecd7ae97b19305ba05159
本記事は当初SVNとGitの比較として「ブランチを用いた開発フロー」のメリット・デメリットについて記載していましたが、 「SVNでもブランチを利用できること」「分散型という言葉に対する記載の誤り」についてご指摘をいただきました。 そのため、ブランチを利用した開発フローに対して感じたことを焦点に記事を修正しております。誤った情報を記載していたこと、SVNに対して誤ったイメージをもつ可能性のある記載をしていたことに対し、深くお詫び申し上げます。 Gitをまともに使い始めて約二ヶ月がたちました。 特に、「ブランチをきる」「修正する」「レビューする」「マージする」という、おそらくGitで想定されている開発フローに沿っての開発はクラスメソッドに入社してからが初めてです。 6月に入社する以前は、開発用のソースコード管理には主にSVNを利用し、1つのバージョンの流れに全ての修正をコミットしていくフローで
こんにちは、mzpです。 今日はMisocaのesaに書いていた「よいコミットメッセージ・よくないコミットメッセージ」という記事を紹介したいと思います。 あらすじ 開発チームでは「コミットメッセージには変更理由を書いて欲しい」「コミットメッセージはWhatよりもWhyが大事」という話を何度かしているのですが、なかなか徹底できていません。 ので、もう少し具体的に「こういうコミットメッセージはよくないですね」というまとめを作ってみることにしました。 ちなみにこの過程でみつけたコミットメッセージに、こんなものがあります。 一切情報がなくておもしろいですね。 ファイル移動を移動した事実しか書かない これは以下のようなコミットメッセージです。 ファイル名を変更 ディレクトリを移動 ファイルを移動したことはコミットメッセージを見なくてもdiffから分かりますが、なぜその移動をしたかが分かりません。 の
プレゼン資料を作っている時に「このコミットグラフをMarkdownかテキストで書けたらな」と思ったことがある人、結構いるのではないでしょうか。 GitGraph.js を使うと、JavaScriptで記述したコミットログをcanvasを使って可視化できることを知りました。なかなかおもしろいです。 準備 まず GitGraph.js の JavaScript と CSS ファイルを読み込みます。GitHub からソースをcloneするなり、bowerを使うなり、CDNを使うなり、お好みで。ここではコミットグラフを定義するコードも別ファイル index.js に書くことにします。 <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>GitGraph.js</title> <link rel="stylesheet" type=
イラストの管理 自分はたまにイラストを描いたりするのですが、以前からその管理方法に苦労していました。 苦労していた点は主に次の 2 点です。 バックアップ 制作過程 Gif をつくるのが面倒くさい 強い人は、短時間でもさらっとイラストを描いてしまいますが、自分は時間をものすごく掛けないとまともなものが描けないので、バックアップは結構頻繁に取ります。 手動でバックアップしようとした場合は、ふつうにファイルを複製する感じになると思います。 ただ、普段からコードを書いていて VCS を利用している身だと、どうしても原始時代かと錯覚してしまいます。 さらに、PhotoShop の psd 形式や CLIP STUDIO PAINT の標準である clip 形式はいろんなデータが詰め込んであるので 1 ファイル当たり平気で 50 MB くらい持って行かれます。これも結構厳しいところです。 VCS を
PHPのようなゆるふわな言語を安全に書くためには、コードの綺麗さや作法などを担保する手段が大切になります。 IDEを使う、JenkinsなどのCIサーバーを立ててチェックさせるなどの方法が考えられますが、今回はgitの pre-commit hook を利用して、一定の条件を満たしていないコードはそもそもリポジトリにコミットができないようにしてみました。 できるようになったこと 今回以下の様な事ができるようになりました。 git commit時に、 コミットされるファイルにシンタックスエラーがあるPHPファイルがる場合、コミットが失敗する。 コミットされるファイルに作法の悪いコードが有る場合、(使用してない変数があるなど)コミットが失敗する。 PSRに則ってないファイルが有る場合(改行コードやインデントの統一など)、整形してからコミットする。 これにより、レポジトリ上にコミットされるファイ
チームで開発を行うときにGitのスキルは必要不可欠なものとなってきています。以前、Git初心者向けにスライドをまとめたものを紹介しましたが、今回はGit(GitHub)をさらに活用するために参考にしたい記事を紹介します。 この記事は以下のような方におすすめです! ・ブランチをどのように運用すれば良いのかわからない。 ・コミットメッセージの書き方にいつも悩んでしまう。 ・issueやPull Requestをもっとうまく活用したい。 ・Git�やGitHubに関する便利なテクニックを知りたい。 ・間違ってコミットしてしまったけど対処法がわからない。 今回は、運用編、コミットメッセージ編、issue編、Pull Request編、テクニック編、問題解決編と5つの内容で分類してみました。実践的な読み応えのある記事ばかりなので、ぜひ参考にしてみてください。 運用編 中の人に聞いたGitHub fl
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く