Fukuoka.go#11で発表した資料です。 https://fukuokago.connpass.com/event/87684/
  
  AWSの各種サービスやSDKのドキュメントがオープンソースとしてGitHubに公開。誰でもコントリビュートや再利用が可能に Today we are adding over 138 additional developer and user guides to the organization, and we are looking forward to receiving your requests. You can fix bugs, improve code samples (or submit new ones), add detail, and rewrite sentences and paragraphs in the interest of accuracy or clarity. 今日、私たちは138以上のデベロッパーガイドとユーザーガイドを追加し、みなさんの要望を心待ち
      
  TL;DR プログラムのネーミングで迷ったら GitHub でキーワードを検索して、ヒットした件数が参考になるのでは? 複数キーワードを検索して結果の一覧を表示する CLI 作りました https://github.com/kyoshidajp/ghkw ネーミング迷いますよね? みなさん、コードを書いていて変数やメソッド名のネーミングって迷いますね。 こんな時に自分たちはチームを横断して「こういう名前考えたんだけど、これってどうかな?」という確認を Slack 上で行っています。先日、この Slack チャンネルを見ていて考えました。 「**GitHub で検索すれば世の中のコードでどのぐらい使われているかざっくり分かるので参考になるのでは?**説」 GitHub で検索できるという条件付きではありますが、コードの規模からするとある程度期待できそうです。 GitHub で検索 例えば「除
      
  最近日々のタスクをこなす上で、「議論をどこで行うべきか」について考えることが多いです。 チャット 口頭 GitHubのIssue GitHubのPR など、色々な手段がありますが、内容的にここで議論して問題ないか?結論をどこで管理すべきか?経緯を記録すべきか?など考えることは色々あります。 GitHubのチームディスカッション機能が議論の場所として検討できるケースがそれなりにあるような気がしたので、機能について紹介します。 チームディスカッション機能 大雑把に言えばGitHubのTeam内で議論をするための機能です。 個人的には「リポジトリに紐づかないゆるいIssue(的なもの)」を「軽く」使うための機能でしょうか。 Issueよりも、「テーマを設定できるチャット」という理解の方が正しいかもしれません。 特定のプロジェクトではなくチームとして発生する問題や提案に対する議論の場として良さそう
      
  [Chapter1-02] Git機能を提供するWebサービス ファイルの変更、追加、修正などを管理する場所である「リポジトリ」は、自分のPCにも、ネットを介したサーバ上にも作成できます。サーバを設定するには専門知識を必要としますが、サーバ機能を提供してくれる便利なWebサービスのひとつがBitbucketです。 2015年6月24日/TEXT:大串 肇 使用するコマンド ――――――― $ git --version ――――――― ■ローカルリポジトリとリモートリポジトリ 前述(Chapter1-01)したように、Git によってバージョン管理を行う場所として指定した場所を「リポジトリ」といいます。自分ひとりだけで開発・制作、バージョン管理を行う場合は、リポジトリは自分のPCにあればよいでしょう。しかし、リポジトリをサーバに用意して、ネットを介してどこからでも利用したい、あるいはチーム
みなさんこんにちは。teratail開発チームの出川(@ikuwow)です。 少し前ですが、9月14日にサンフランシスコで開催されたGitHub Universeにて 「Code Review」と「Projects」という大きな新機能が発表されましたね! github.com 中でもIssueやPull Requestをかんばん上に表示できる"Projects"機能は 誰もが待ち望んでいたツールとも言えるでしょう。 以前からGitHubのIssueをかんばん化するツールは ZenHubや Waffleなど様々なものがありましたが、 ついにGitHubが公式で実装してくれました。 teratail開発チームでは開発でGitHubを利用しているので、 ニュースを聞いたときにはチームメンバーの皆がすぐに使いたくなりました。 既にこのProjectsを使ってみた様々な記事がありますが、 terat
      
  チームで開発を行うときにGitのスキルは必要不可欠なものとなってきています。以前、Git初心者向けにスライドをまとめたものを紹介しましたが、今回はGit(GitHub)をさらに活用するために参考にしたい記事を紹介します。 この記事は以下のような方におすすめです! ・ブランチをどのように運用すれば良いのかわからない。 ・コミットメッセージの書き方にいつも悩んでしまう。 ・issueやPull Requestをもっとうまく活用したい。 ・Git�やGitHubに関する便利なテクニックを知りたい。 ・間違ってコミットしてしまったけど対処法がわからない。 今回は、運用編、コミットメッセージ編、issue編、Pull Request編、テクニック編、問題解決編と5つの内容で分類してみました。実践的な読み応えのある記事ばかりなので、ぜひ参考にしてみてください。 運用編 中の人に聞いたGitHub fl
      
  GitHubでは、サーバーを自前で準備しなくてもWebページを公開できる「GitHub Pages」という機能があります。これまでは、gh-pagesという別ブランチを作成して、そこにソースコードをプッシュする必要がありました。しかし、本日(2016/08/18)実装された新機能により、masterブランチのみでWebページを公開できるようになりました。 本エントリーでは、具体的な設定手順を紹介します。 手順 masterブランチにて、「docs」フォルダーを作成します。このフォルダーに公開したいWebページのソースコードを入れます。 masterブランチをプッシュします。 GitHubのリポジトリページ上で、[Setting]→[Pages]に移動します。 [Source]の箇所から、「Branch: main」、「/docs」フォルダーを指定します。 [Save]を押すと、下図の赤枠部
      
  Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩
      
  いくつかのオープンソースプロジェクトを公開している筆者からの、読みやすくユーザーにやさしいREADMEを書くためのアドバイス。 この記事は、Rowan Manning氏による「Writing a Friendly README」(2016/3/14)を翻訳したものです。 あなたのプロジェクトのREADMEは、かなり重要です。そこはプロジェクトに初めて来た人が大抵最初に見るであろう場所であり、唯一のドキュメントであることもよくあります。あなたのオープンソースプロジェクトにとってのREADMEは、企業にとってのウェブサイトのようなものです。ウェブサイトはユーザーエクスペリエンスの注目を集めるところですが、READMEがユーザー観点で考えられることはほとんどありません。 この記事では、分かりやすいREADMEを書くために役立ち、開発者(ユーザー)の要求に見合い、開発者がプロジェクトを初めて見たの
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
      
  By Jimmy Baikovicius プログラマーのJi-Sung Kim氏が36時間のハッカソンで作り上げたという自動ジャズジェネレーターが「deepjazz」です。deepjazzはPython製のディープラーニングライブラリである「Keras」と「Theano」を使用して作り上げられた2層構造の「Long short-term memory(LSTM)」で、MIDIファイル(音源データ)を与えると音楽を学習してオリジナルのジャズを作曲してくれます。 deepjazz: deep learning for jazz http://deepjazz.io/ 「deepjazz」は、Googleの「AlphaGo(アルファ碁)」やIBMの「WATSON」などのような、人工知能(AI)の一種です。Googleのアルファ碁は囲碁を打つ能力に特化したAIですが、deepjazzはその名の通り
      
  前提 過去のチームといまのチームでどうやっているかの話 master以外なら force push 可能なことが条件 コミットコメント 一行で概要 WhyやHowを書かせる。 WhereやWhatはいらん、diffを見ればわかる。 (必要なら)詳細 なんでここにこういうことをした? という細かい説明。 時間に追われてdirty hackをせざるを得なかったのならここにも書いて欲しい。 書かずに変なことしたら俺がハリセン issueだのメモだのへのリンクでもいい 諸注意 日本語OK 英語オンリーにするとみんな面倒臭がって little change for debug とか平然と入れる 詳しく書かせたいし読むのに苦労したくないので日本語を許す コミットのタイミングと粒度 粒度はできるだけ細かく。 1コミット単位でレビュワーがお前何がしたかった?をみるため。 レビュー中にレビューが入った部分は
      
  Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 専用の拡張をインストールすると、GitHubそのものが拡張される。 GitHubに足りないアジャイルらしさを組み込むもの。2.0以前の機能は、ZenHubとはを参照してください。 ZenHubが2014年にリリースされてから、フェイスブックやソニー、NBC、マイクロソフトなど大手に取り上げられたZenHubは、2015/6/21にバージョン2.0となり、デザインなどが一新しました。 ZenHubのバージョン2.0とされる機能は以下のとおりです。 Task Board(カンバン)の複数リポジトリ対応 新しいZenHub Boardは、複数
      
  4年ほど使ったemacsからST2に乗り換えてみたメモ。 ST2の使用期間は1週間くらい。 emacsの設定は ここ。 ST2の設定につてはまだ固まってないので割愛。 きっかけ Marvericksをクリーンインストールして、 .emacsのバックアップをそのまま置いたら動かなかったので。 el-getでパッケージを入れなおしても バイトコンパイルで失敗したりしてうまく行かなかったので この際乗り換えてみるかーということでやってみた。 emacsの機能/拡張と同等のプラグインが見つかったもの el-get → Package Control https://github.com/dimitri/el-get https://sublime.wbond.net/ 検索サイトが見やすい。 画面分割 → origami 基本機能 https://sublime.wbond.net/package
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く