開発フロー研修 @ Wantedly - Qiita
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
pgcli
We stand with Ukraine Ukrainian people are fighting for their country. A lot of civilians, women and children, are suffering. Hundreds were killed and injured, and thousands were displaced. This is an image from my home town, Kharkiv. This place is right in the old city center. Picture by @fomenko_ph (Telegram). Please consider donating or volunteering. https://savelife.in.ua/en/donate/ https://ww
久々にチーム開発したのでメモ - ひげろぐ
昨年秋頃から年明けにかけてRailsで顧客のサービスをひとつ作った 久々のチーム開発で。チーム人数は3名。 せっかくなので使ったツールややり方などを備忘録的に残しておく。次いつまたチーム開発する機会があるのか知らんけど。 実践したこと プルリクベースの開発 Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー 上記のやり方が面白そうだったので試してみた。 Githubを使っていれば拍子抜けするほど簡単に流れに乗ることができた。 Git力が足りないので最初は少し大変だったが、馴れてくると細かくブランチを切ってフィーチャーごとに対応するということが開発のテンポを良くしてくれた。 コードレビューはイージーミスによるバグや既存のコードと大きく流れの違うコードが混ざるのを未然に食い止める事ができたりと、一定の成果はあった。 一方でい
ChatOpsでOSのセキュリティアップデートを自動化出来るようにした - Glide Note
先日@naoya_itoさんが自身のブログ(インフラの継続的デリバリー)でKAIZEN platform Inc.のインフラについて書いていたやつの続編的な内容。 TL;DR Chat(Slack) + Hubot + CircleCI + GitHub を用いてセキュリティアップデートを自動化した GitHubのPull Requestを契機にセキュリティアップデートを実行できるようにした CircleCIが大変便利。インフラ系の作業を自動化するのに非常に合っている気がする 背景 KAIZEN platform Inc.では、 ネットワーク脆弱性スキャン アプリケーション脆弱性スキャン セキュリティアップデートの定期実行 の3つをセキュリティ系タスクとして継続的にやっていこうという話になり、今回は私が担当した、「セキュリティアップデートの定期実行」の話。 RHEL系OSにはyumの自動更
GitHubに会社の就業規則を公開した - terurouメモ
これです。 ちゃんと社労士チェックを入れて、2014年時点の法運用Validな感じにしてあるので、下手な中小企業はおろか、ろくにメンテされていない大企業の就業規則よりマトモな内容になっているはずです。 なんで就業規則を公開したのか マトモな規則が作ってあれば公開しても特にデメリットはない むしろマトモな会社アピールができてよい 個人的には「無限RedBullです！！！！」みたいな事をアピールする会社よりマトモな広報・求人活動の一環だと思っている 自分で就業規則を作ろうにも、良いサンプルがなかった（後述あり） いわゆるOSS的な話。就業規則にも再利用性が合っても良いはず これを書いてて、就業規則にライセンスを明示するのを忘れていたことに気が付いた GitHubだと、就業規則の改定にプルリクを飛ばせて楽しいし、改定履歴も一目瞭然 零細企業に就業規則って要らないんじゃないの？ 従業員が10人未満
わかりやすいREADME.mdを書く
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
［速報］Docker Hub発表。ビルド、テスト、デプロイの自動化、Dockerイメージの管理など。Dockerのプラットフォーム化を推進
［速報］Docker Hub発表。ビルド、テスト、デプロイの自動化、Dockerイメージの管理など。Dockerのプラットフォーム化を推進 Dockerの開発元であるDocker社は、Docker 1.0の発表とともに、Dockerを基盤としたアプリケーションの開発、配布、実行のための一連の機能を備えたサービス「Docker Hub」を発表しました。 関連：［速報］コンテナ型仮想化のDocker 1.0がリリース。Dockerはコンテナエンジンからプラットフォームになると宣言 Docker Hubは、GitHubやBitbucketなどのソースコード管理ツールと連係して自動的にコードをビルドする機能や、AmazonクラウドのAWS Elastic BeansTalkやGoogle Compute Engine、Rackspace、Red HatのOSなどと連係してアプリケーションをデプロイ
dmca/2014-06-04-LINE-Corp.md at master · github/dmca · GitHub
Dear GitHub Team, My name is [private] and I am writing on behalf of LINE Corporation, in regards to a copyright violation on the GitHub website。 I believe in good faith that "libpurple (Pidgin, Finch) plugin for LINE instant messenger by LINE Corporation/NAVER" infringes LINE Corporation's copyrights and that the use of our source code is not authorized by the rights holder, its agent or the law.
JavaScript で if 文を書くとき必ず波括弧を書くべきと主張しているスタイルガイド - @kyanny's blog
新人さんの JavaScript のコードレビューをしていて、 if 文の本体部分を波括弧で囲っていないコードを見つけた。 おれは本体が一行しかなくても必ず波括弧で囲うようにしており（そのほうがわかりやすいと思っているから）、できればそうして欲しいけど個人の好みを押し付けるのはよくないので、広く支持されているコーディングスタイルガイドの類いで同様の主張をしているものが無いか探した。 Google とか Mozilla とか GitHub あたりのドキュメントを眺めてみたが if 文の波括弧についてはっきり言及している箇所を見つけられずにいたら、該当するドキュメントをいくつか教えてもらった。 http://contribute.jquery.org/style-guide/js/#spacing if/else/for/while/try always have braces and alw
GitHubクローンのGitLabを５分でインストールした - アルパカDiary Pro
※2015/6/22 最新版の手順に更新 ※2015/1/7 アップグレードについての記事を書きました http://d.hatena.ne.jp/toritori0318/20150106/1420558625 ※2014/5/24 補足記事書きました http://d.hatena.ne.jp/toritori0318/20140524/1400955383 で､お決まりのパターンでOSSに流れて､ GitLabとかやってみたんだけど､むっちゃムズいのねあれ｡ まともにインストールできん｡ http://d.hatena.ne.jp/rela1470/20140520 「GitLab インストール」 でググるとたいていまともにインストールしようとしている記事が見つかって なにこれ使うまで面倒すぎ！ ってなりますよね。かつての自分もそうでした。 しかし最近のGitLabはRPMが提供され
VimでPHPの補完にスニペットを使ったら捗った件 - Qiita
この記事はVim Advent Calendar 2013 149日目の記事です。 今までVimでPHPを編集する際に、関数名の補完のために辞書ファイルを使っていましたが、Neosnippet用のスニペットファイルを使うようにしたら、ものすごくいい感じになりました。 PHPは標準関数がたくさんあるのでとてもいい感じです。入力が楽になるのはもちろんですが、引数の順序が紛らわしい関数に翻弄されずに済みそうなのがいいですね！ なお、生成したスニペットファイルはGithubに上げておきました。必要であればコピペして使ってください。 php_functions.snip もしNeosnippetを使ってないならすぐにインストールしましょう！ 特にPHPみたいに定型文がよく出てくる言語でコードを書くときは大変便利です。 Shougo/neosnippet.vim neosnippet.vim を活用し
ScaleOut | Supership
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
Box | Open Source
Box <3 Open Source At Box, we rely on open source software every day. That's why we give back to the open source community whenever possible, by contributing code to outside projects and sharing projects that we've developed internally. About Our Projects Our open source projects represent the best of Box. They are all hosted on GitHub. We hope you'll find them helpful and we invite you to contrib
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - azu/awesome-commit-english: コミット英語についての記事まとめ
crocos.jp
PHP-FIG — PHP Framework Interop Group - PHP-FIG
GitHub - XVimProject/XVim: Xcode plugin for Vim keybindings
GitHub - ovity/octotree: GitHub on steroids
yoshiko-pg.github.io
はてなブログチームの開発フローとGitHub
