大学の研究に役に立った物シリーズ第3弾です 今回は研究のためのプログラミングのノウハウについてです。 特に、研究におけるプログラミングでの悲劇を防ぐために自分が実践していた方法を紹介をしたいと思います。大学や研究室によっては、このような研究のプログラミングのノウハウの伝承が行われているところもあると思いますが、何かの参考になれば幸いです。 大学の研究で役に立ったものシリーズの記事 サービス編 勉強編 研究のためのプログラミングとは まずは、研究のためのプログラミングに求められる特徴をざっと説明したいと思います。自分の経験からですが、こんなところではないでしょうか。 実験結果が出ないと何も議論できないので、とりあえず速く実装することが求められる コードのモジュール化、速度の最適化は後回しになりがち 計算量が多いタスクでは、24時間実行しても実験が終わらないことがあり得る バグによって実験の結

| 書籍紹介 | サイトの目的 | ダウンロード | 更新情報 | 謝辞 | お問い合わせ | 書籍紹介 Git は、 Linux カーネル開発のために Linus Torvalds さんが2005年に公開した分散型バージョン管理システムです。スタートアップのような小規模組織からGoogle、 IBM のような巨大企業で、また数多くのオープンソースプロジェクトで利用されています。現在の Git 開発は、濱野純さんを中心としたコミュニティによって非常に活発に行われています。 本書 Pro Git は、2009年に Apress から初版が、2014年に第2版が出版された、Git の解説書です。著者の Scott Chacon さんは、GitHub 社の CIO、Git のエバンジェリストであり、Git 公式サイトの管理者でもあります。 本書の内容は、出版以降も有志により頻繁に更新されており、

私の独断と偏見によるGit for Windowsのインストール手順です。 最終更新 2022/06/07 Downloadをクリックし、インストーラーのダウンロードを開始します。 ファイルをダブルクリックしてインストーラーを起動します。 ライセンスを確認して、Nextをクリック。 Only show new optionのチェックは、アップグレード時に新規に設定する項目のみを表示させるためのオプションです。 インストール先ディレクトリを確認されるので、Gitをクライアントとしてのみ使う場合にはできるだけこのままで進めます。ただ、オープンソースのTracのようなITS/BTSと組み合わせる場合や、SSHを使ってサーバー公開をする場合などは、C:\Gitのように短めで、間にスペースが入らないディレクトリに設定してインストールをします。 VSのGit拡張や、その他Git関連ツールと組み合わせる

10年以上前は CVS や Visual Source Safe を使っていたのですが、仕事の内容が変わって長いことバージョン管理システムには縁がない状態でした。 しかし、最近また仕事の内容が変わったのを機に (Subversion をスキップして！) git を導入してみました。 仕事環境は Windows がメインなので git も Windows 上に導入しましたが、使ってわかったのは Windows 環境でも全く問題なく使うことができるということです。 Web 検索すると古い情報が多くて Windows で動かすには苦労話が多いように見えますが、現状全く問題ありません。 といってもやはりノウハウが必要な部分もあるわけで、ここまでの自分の経験をまとめてみます。 クライアントは Git for Windows で決まり ちょっと古い記事だと Cygwin と msysGit のどちらを

Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。 今回は、そもそもやらかさないようにしたいよねっていうお話。 コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます 過去に似たようなプロジェクトがあるのならそれを流用しましょう。 ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。 ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。 コミットメッセージのフォーマットを決めておく コミットメッセージのフォーマットを決めておけば書き直したいということも減ります コミットメッセージをやらかして直したいと思うことはよくあります。 そういうのって案外コミットメッセージが自由すぎることが問題だったりします。 ある

何も考えずに書き始めたけど10の方法って書いちゃった。 いくつになるかはわかりません。 一般的なプロジェクト運用でもある程度同じ方法論でイケると思います。 なお、筆者であるvvakameはDefinitelyTypedのメンテナをしています。 そのため、これから先の文章について、TypeScriptやJavaScript関係固有の事象が含まれていると思います。 書かれている内容について、contributeする側、される側、両側へのアドバイスを書きます。 ちなみに、わかめ的にはTOMOYO Linuxに学ぶ説得術とかはすごい参考になりました。 こまけぇことはいいんだよ！まずはやろう！ 貴方が世界に存在するためにはまず誰かに存在を知ってもらわなければいけません。 pull requestを出そう！無理だったらIssueを書こう！ まずはそこからだ！！ pull requestのmergeを拒

分散バージョン管理システムの利用は拡大しています。そのなかでも最も人気のあるツールはGitでしょう。しかし、GitをWindowsで使うのはなかなか困難でした。 Windows向けのGitであるmsysGitは、bashのコンソールを出して、最小限のUnix風コマンドライン環境を提供するものです。これは使いやすくありません。もう一つの選択肢であるTortoise Gitは、Windowsのエクスプローラー（ファイルマネージャ）に統合されたGUIツールですが、僕は「なんか違うな」と感じてました -- これは個人の感性の問題ですが、ファイルマネージャに横付けすることが、分散バージョン管理システムへの良いUIを提供するようには思えないのです。 ところが、最近は事情が大きく変わっています。使いやすいGUIツールとして、2013年6月に正式公開されたSourceTree for Windowsが存在

Help us understand the problem. What is going on with this article?

会社関係の勉強会向けに作った資料です。 パラパラマンガ調のためページ数は多いですが、内容は基礎的なものです。 このスライドを読み終わった人にオススメ： 「図解gitworkflows(7)」 資料一覧: https://docs.google.com/spreadsheets/d/1VZMz_31Z7FQBnK139o8yMqzwrTJgZWtPqgoG-mx1zh0/edit?usp=sharingRead less

コードには1行ごとに隠しドキュメントがあります。 次のコードスニペットの4行目を書いた人は、何か理由があってDOMノードの clientLeft プロパティにアクセスしたのでしょうが、結果的に何もしていません。これはかなり不可解です。なぜこうしたのか、あなたは説明できますか？　今後、この呼び出しを変更したり削除したりしても安全でしょうか？ // ... if (duration > 0) this.bind(endEvent, wrappedCallback) this.get(0).clientLeft this.css(cssValues) 私ではなく他の人があなたにこのコードを見せたとして、誰がこの行を記述したのか、どんな理由があったのか、このままの状態にしなければいけないのか、あなたはおそらく説明できないでしょう。ただし、プロジェクトを進めているときは大抵の場合、バージョン管理シス

キャリア1年未満だった僕が、社内にGitの運用を布教するために読みあさったもの ( +ちょ〜簡単に各Gitの運用方法のメリット・デメリット )Gitgit-flowforkteamGithub-flow いろいろな方々とお話していると、「Gitでバージョン管理をしてみたい！」というような意見を多く聞きます。（Qiitaユーザーは「すでに使ってるよヽ(´ー｀)ノ」という方が多いとは思いますが…） 今回は、キャリア1年未満の時にgitの社内での運用についていろいろと制定していた際に、勉強した記事(+α)などを紹介したいと思います。 読んでほしい方 gitをチームでこれから導入しようとしている方 とりあえずgitを使ってみて、突っ走ってしまい、意味の分からないブランチが乱立したりして、運用に困っている方 新入社員の方など、バージョン管理って何なんだろうと思っている方 そもそもGitとは？基本的な

Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 （2014年12月17日追記） 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど！と思ったコメントをもとに少し修正・加筆してみました。 （2022年1月4日追記） 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目：変更内容の要約（タイトル、概要） 2行目 ：空行 3行目以降：変更した理由（内容、詳細） 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 （多すぎても悩むので

Gitのコミットログには、現在形で書く流派と過去形で書く流派がある。 どちらにすべきか決めかねていたが、Should I use past or present tense in git commit messages? - Stack Overflowを見て現在形、より正確には命令形を使うことに決めた。その理由は Gitの公式ガイドラインがそう言っているから である。 git.git - The core git plumbing は以下のように述べている。 Describe your changes in imperative mood, e.g. "make xyzzy do frotz" instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", as if you are g

多分、Gitを使い始めて詰まる（というか悩む）ところの大多数が、「コミットコメント」だと思う。 これについては色々な人が色々なことを書いていて、結構どれも正しいので、それらを参考にしてもらうのが良いと思う。 じゃあ俺はこれから何を書くのか、というと、 こういう風にコメントするとチーム開発が捗るよ というのを書こうと思う。 俺自身も出来てないことが多いので、自戒を込めて書くことにした。 ※注意！ この記事は「ウチのチームで俺はこういうのを意識してコミットコメントを書いている」というものであって、 万人にドンピシャリと来るものではないというのを予めお伝えしておく。 コミットが何を変えるのかを明確にする たとえばこんなコミットコメントがあったとする。 アウト。ダンゴで試合終了。 "Fix some bugs"、直訳すると「いくつかバグ直したぜ！」である。どこの、どんなバグを、何個直したのかが全く

このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.

はじめに こんばんは。突然ですが皆さんGitをご存知でしょうか？ 一言でいうと”ファイルの履歴を管理するソフト”なのですが インターネットで調べると難しそうな説明ばかりでてきます。 （かく言う私も敬遠してました) そんなGitですが、使ってみると超便利！ プログラマさんやデザイナさん、モデラーさんなど データを創る作業をされる方であれば間違いなく役立ちます！ 先日、運良くGitを説明させていただく機会があり一気に覚えました。 数日しか使ってないので細かな間違い等あるかもしれませんが 折角覚えたのでまとめておきたいと思います。 とにかく簡単に！ プログラマじゃない人向けにまとめます。 この連載記事の概要 目標 Gitの便利さを知る。 Git怖い怖い病を治す。 個人でGitを使えるようになる。 チームでGitを使えるようになる。 Unityプロジェクトを個人/チームで使えるようにする。 特に読

まだ使ってない人向けです。WordPressの場合は、Jetpackが提供してくれるMarkdownを利用することで、普通にタグを書くよりもずいぶんブログを書く時間が短縮できますよ。 見出し [code lang=text] # h1 ## h2 ### h3 // 増やした数だけ数字が増える [/code] リスト [code lang=text] – リスト – リスト – 子要素(先頭にタブインデント1つ) – 孫要素(先頭にタブインデント2つ) – 子要素(先頭にタブインデント1つ) – リスト [/code] 数字のリスト [code lang=text] 1. リスト 2. リスト 3. リスト //数字を増やさなくても同じ結果になる 1. リスト 1. リスト 1. リスト [/code] リンク [code lang=text] [リンクのテキスト](http://hoge