あなたのチームの「いい人」は機能していますか?Minoru Yokomichi169.5K views•56 slides 凡庸なSEが、大規模SIerの集団でできること - DevLOVE甲子園 2013Minoru Yokomichi13.8K views•35 slides
あなたのチームの「いい人」は機能していますか?Minoru Yokomichi169.5K views•56 slides 凡庸なSEが、大規模SIerの集団でできること - DevLOVE甲子園 2013Minoru Yokomichi13.8K views•35 slides
アプリケーションエンジニアの id:nobuoka です。 現在は 「少年ジャンプルーキー」 の開発に携わっています。 面白い漫画作品が数多く集まっておりますので、是非ご覧ください! さて、去る 1 月 11 日に 「Jenkins ユーザ・カンファレンス 2015 東京」 が開催されました。 はてなからも 「はてなにおける継続的デプロイメントの現状と Docker の導入」 というタイトルでセッション発表を行いました。 ここに発表資料を公開します。 発表資料 はてなにおける継続的デプロイメントの現状と Docker の導入 from Yu Nobuoka 概要 内容としては次の 3 点です。 はてな全体のサービス開発と Jenkins についての概要 「少年ジャンプルーキー」 の開発プロセスと Jenkins の活用 開発中の機能を確認するための web アプリケーションを Docker
数ヶ月の期間を経た後、git 2.2.0 がリリースされました。これは重大発表です。今回の内容には、あなたの git ワークフローを改善させる沢山の新機能が搭載されているからです。以下、アトラシアンが見出した利点を挙げていきます。 git archive が pathspecs を学習 git archive は、リポジトリ内容の ZIP あるいは TAR アーカイブを特定の修正によって生成させるコマンドです。アトラシアンでは、一部のチームがお客様に対して当社ツールのソースコードを分配する際に、これを利用しています。2.2.0 においては、pathspec (antglob に類似) を利用する事で、生成されたアーカイブにどのファイルを含めるか制限できます。これは、ドキュメンテーションや静的な Web リソース等、リポジトリから一定のファイルを抽出する際に便利です。例えば、git プロジェ
Pro Git第2版の驚くべき冒険と最終的なツールチェーン ほぼ6年前、私はApressから執筆が予定より遅れていたPro Gitと呼ばれる本の手伝いの誘いを受けました。結局原著者が書き続けないことを決めて、私が最初から書き直して2009年8月頃に最終的に出版されました。最初の3章あたりは、私はWordで本を書きました。そして編集者に文書を送って、しばらくして最終的な版を手にしました。 この3章のあとで、私たちが執筆と技術的な編集段階のためにMarkdownに切り替えて、同意された編集のためにだけWordへ戻るように提案したとき、私はやめようとしていました。一旦本が完成したら、私はすべての内容をMarkdownへ再び戻したので、それを私が作成したWebサイトにおいてオンラインで発表できました。幸運にも、原著者は著作をクリエイティブ・コモンズ・ライセンスとすることでApressと同意しました
Your terminal can display color, but most diff tools don't make good use of it. By highlighting changes, icdiff can show you the differences between similar files without getting in the way. This is especially helpful for identifying and understanding small changes within existing lines. Instead of trying to be a diff replacement for all circumstances, the goal of icdiff is to be a tool you can re
GNU Emacsが、プロジェクトで使用するソースコード管理ツールをBazzarからGitに移行させた(Phoronix)。 以前、「オープンソース」という言葉を広めた人物としても知られるEric S. Raymond氏がEmacs開発者向けメーリングリストに「Bazaarは死につつある」としてBazzarからの移行を提案していた(スラッシュドットの過去記事)ことも移行のきっかけになったようだ。 Emacsのソースコードを公開するGitリポジトリ自体は以前から存在したが、Emacsは非常に長い歴史のあるソフトウェアということで、その過去の履歴までを含めてGitに移行させるのは大変な作業だったようだ。 なお、リポジトリの情報やGitを使ったEmacsの開発手順についてはEmacs Wikiにまとめられている。
Top Announcements of the AWS Summit in New York, 2023 It’s probably no surprise that generative artificial intelligence and machine learning were the stars of the show, but there were several other bright lights from the day-long cloud conference. New Seventh-Generation General Purpose Amazon EC2 Instances (M7i-Flex and M7i) Today we are launching Amazon Elastic Compute Cloud (Amazon EC2) M7i-Flex
git init してから一番最初のcommit内容を、2番目のcommitと一緒にまとめたい、と後で思った。 よーし、git rebase -i HEAD~~からのfixupで… $ git rebase -i HEAD~~ fatal: Needed a single revision invalid upstream head~~えっ・・・(ΦωΦ) 一番最初のcommitはgit rebase -i HEADほにゃららでは遡れないのか・・・一番最初のcommitはgit rebase -i できないのか・・・?— TAE ✅ (@ken_c_lo) April 21, 2013 @ken_c_lo それ方法あったら知りたいですねー。調べた限りでは無さそうなのもあって、自分でリポジトリ作る時はgit flow initを使って最初に空のInitial commitを作るようにしてます
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
npmに登録されているパッケージ数は10万、月間ダウンロード数も5億を超えました。7月の段階で月間3億程度ですから、こちらのグラフで見てもわかるように、かなり成長が加速してきていますね。 EdgeConf4において、パッケージ管理をテーマにしたディスカッションに、npmのCTOであるLaurie Vossと、npmのpeer dependencyをつくったGoogle Chrome TeamのDomenic Denicola(ES6のPromiseの取組みでも知られた人ですね。)が参加しています。この二人と、BowerのJosh Peekを中心に議論が進んでいます。ちなみにJoshはGitHubの社員で、最近では、左右に並べてdiffを比較できる便利な機能をつくった人でもあります。 「サーバサイドのパッケージマネジャとしては、CPANやRubygem、npmのように開発言語ごとにプレーヤー
Gitのgrepサブコマンドは通常Gitリポジトリーでしか使えない。しかし--no-indexオプションを付けると、Gitリポジトリーではないディレクトリーでも検索できる(もちろんGitリポジトリーでも)。Vimからももちろん使えるので、ackちょっと遅い、ag入れるのが面倒くさい、MSYS上で使ってるとjvgrepの出力が稀におかしい、などの理由でgrepに戻ったりしてる人はgit grepを使うのも良さそう。 set grepprg=git\ grep\ --no-index\ -I\ --line-number grepformatを編集しないで済ませるためには--line-numberオプションを追加して、行番号を表示させる必要がある。僕はバイナリ・ファイルを無視する-Iオプションも合わせて追加しておいた。パフォーマンスをあげるために--no-colorオプションを付けるのも良さそ
CocoaPodsのgitを利用するアクションが全く成功しなくなります。具体的にはpod install, pod updateなどが全く通りません。 公式ブログにあるとおり、0.34.0以上からCocoaPodsは高速にgitリポジトリをcloneするため--depth 1 (shallow clone) オプションを採用するようになっています。しかしながらGitHub:Enterprise側の技術的問題なのか、GitHub:Enterprise内のgitリポジトリに対するhttpないしhttps経由でのshallow cloneが成功しないため永遠にpod installやpod updateが終わりません。
pre-commit A framework for managing and maintaining multi-language pre-commit hooks. Git hook scripts are useful for identifying simple issues before submission to code review. We run our hooks on every commit to automatically point out issues in code such as missing semicolons, trailing whitespace, and debug statements. By pointing these issues out before code review, this allows a code reviewer
Git開発チームは8月15日、オープンソースの分散型バージョン管理システム「Git 2.1」をリリースした。2系初のメンテナンスリリースとなり、ワークフローや性能が改善されている。 Git 2.1は5月末に公開された2.0に続くもので、ユーザーインターフェイスとワークフロー関連、性能などの強化が行われている。 後方互換性のない変更点として、gitが呼び出すページャを指定するLESS環境変数のデフォルト設定でlessに与えるオプションが「-FRSX」から「-FRX」に変更された。これにより、端末内で1行に収まらないような出力は折り返して表示されるようになる。 また、core.preloadindex設定変数のデフォルト値が「有効」となり、マルチコア環境を活用できるようになった。コメントメッセージでカスタムコメント文字を特定するcore.commentCharでは「auto」設定が可能になって
There are many prompts configurations out there, but here is what makes Liquid Prompt stand out: UX Design: The Liquid Prompt was very carefully design from the beginning, to allow for the best user experience. That is, it displays meaningful information with minimal visual clutter and maximum readability. While most of the other prompts are focused on aligning as much colored "segments" as possib
サイボウズ・ラボの西尾 泰和さんが「エンジニアの学び方」について探求していく連載の第2回(毎週火曜日に掲載、これまでの連載一覧)。「WEB+DB PRESS Vol.80」(2014年4月24日発売)に執筆した「エンジニアの学び方──効率的に知識を得て,成果に結び付ける」の続編です。(編集部) 文:西尾 泰和 イラスト:歌工房 この連載では「エンジニアの学び方」をテーマにインタビューを行い、どういう「学び方」をしているのか探求していきたいと思っています。第1弾は、富士通のエンジニアとしてLinuxカーネルの開発に参加されている小崎資広さんです。 Linuxカーネルは、ソースファイルだけで3万5000個以上、行数にして1500万行を超える、巨大ソフトウェアです。小崎さんが、どうやってこの巨大なソースコードと戦っているかは、きっと「エンジニアの学び方」の参考になるはずです。
誰でも知っていることだけど、LinuxというOSというかカーネルはLinus Torvaldsが学生のときに趣味で作ったのがはじまりだ。それは1991年ころの話で彼が21歳の頃だ。個人の趣味で作ったものが、いつの間にかに世界中のコンピュータだけでなく、携帯や家電や様々な機械の制御に使われている。 Linus Torvalds - Wikipedia 1994年ころには、PCで動く個人向けOSとしては十分な機能を持っていた。Xもあるし、gccなどのコンパイラもあるし、GNU Emacsやbashもあるので、ちょっとしたプログラムを作るには十分な機能を持っていた。 当時、勤め先のマシンはSunのワークステーションで仕事でLinuxを使う機会は全然なかったのだけど、自宅のPCにSlackwareのCDを入れてみたりした。日常的に使うことはなかったけど、1998年にOracleがLinux版を出し
私は GitHub が大好きです。GitHubはオープンソースへの コントリビューション (寄与貢献)を何十倍も容易に、そして楽しいものにしたと思います。ですが、GitHubがPull RequestというwebのUI形式で前面に押し出しているオープンソースの メンテナー のワークフローが、プロジェクト品質とコントリビューションを受けつけるスピードの弊害になるということに気がつきました。そこで、GitHubの Pull Request にある「Merge pull request」ボタンをクリックする前に、少しお話をさせてください。 メンテナーの紹介 ジェーンはそこそこの成功を収めているオープンソースプロジェクトのメンテナーです。彼女は毎週プロジェクトのGitHubリポジトリに上がる新しい Issue を確認し、リクエストに対し速やかにフィードバックを返します。リクエストをすべて実行する時
CompanyEngineeringProductSunsetting AtomWe are archiving Atom and all projects under the Atom organization for an official sunset on December 15, 2022. January 30, 2023 Update: Update to the previous version of Atom before February 2 On December 7, 2022, GitHub detected unauthorized access to a set of repositories used in the planning and development of Atom. After a thorough investigation, we hav
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く