Always ready-to-code Isolated cloud development environments with your favorite editor. Connect in seconds with one command.
![Gitpod: Always ready-to-code.](https://cdn-ak-scissors.b.st-hatena.com/image/square/2f3a8d29e898205b328485f6a8bf2dfa4a068256/height=288;version=1;width=512/https%3A%2F%2Fwww.gitpod.io%2Fimages%2Fmedia-image.jpg)
What is the bug bounty program?But bounty program allow individual bug hunters to report bugs to a company and receive rewards. These bugs are usually security exploits and vulnerabilities. 1. ResearchReview the program scope to ensure that you are looking for vulnerabilities that companies are interested in and start research. 2. ReportWrite a clear and understandable report when you found vulner
こんにちは。クックパッド特売情報ディレクターの田中です。 前回ヘルスケア事業部の濱田くんのエントリーでエンジニア以外のGitHubの利用について紹介されていましたが、今回は私がチーム開発で実践しているissueの立て方についてご紹介したいと思います。 チームが大きくなってきてヒズミが生じてきた 本来、ディレクターが開発を伴わない価値検証を十分に行った上で仕様を考え、デザイナー・エンジニアに引き継ぐのが理想的だと思います。 私自身も当初はその開発の進め方を採用していましたが、チームが大きくなり、ディレクター1人で関わるエンジニアが増えてくると、状況は変わってきました。 マルチタスク的に仕様を考えていたために詰めが甘い部分が多く、手戻りが発生してしまったり、仕様の準備が追いつかず、エンジニアの手が空いてしまうことが増えてしまったのです。 当初は自分自身の頑張りが足りないからだと、徒に気合いと根
iOS9がそろそろでます iOS9が今月半ばに登場するので、それに向けてiOS9対応をする必要があります。 例年の通りだと、来年にはiOS9SDKでビルドしていないものは審査すら出せなくなります。 iOS8対応済みのアプリに対してiOS9対応する際にやろうと思っていることを以下にまとめました。 他にもこれやっといたほうがいいよっていうのがあれば教えて下さい。 iOS9対応とは まずXcode 7をダウンロードしましょう。 Base SDK をiOS9にしてビルド。これで完了です。 最初はビルドが通らないことがしばしば。エラーを取り除きましょう。 以下がポイントです。 1.URLスキーム対応 問題 iOS9からcanOpenURL:メソッドが使えません。「This app is not allowed to query for scheme originalscheme」というエラーをはきま
BUNDLED WITH って何? bundler 1.10.0 以降で作成された Gemfile.lock では、BUNDLED WITH というセクションがあって、使用された bundler のバージョンがトラックされるようになっている [3485] 。 例えば bundler 1.9.0 で作成された Gemfile.lock のあるプロジェクト上で、 最新の bundler 1.10.3 を使用して bundle install --path vendor/bundle すると、 Gemfile.lock には以下の差分ができる。 これをもう一度 1.9.0 で bundle install すると、上の文字はきれいさっぱり消える。 BUNDLED WITH の何が困るか 多人数で開発するときには、この変更は微妙に邪魔で、意図しない Gemfile.lock 変更が出てしまうことで
Revised Revised 型の国のTypeScript 本書について 本書はJavaScriptにコンパイル可能な言語のTypeScriptについて解説した本です。TypeScriptの基本的な知識(型の使い方)やコンパイラのオプション、型定義ファイルの作り方やエコシステムについて解説します。 対象読者は新しめのJavaScript、いわゆるECMAScript 2015とそれ以降*1について理解しているユーザです。Node.js環境やnpmの使い方、OOP (Object Oriented Programming)の効能や利点をある程度理解していることが望ましいです。 本書に登場するすべてのサンプルコードは次のTypeScriptコンパイラでコンパイルできることを確認しています。 Version 2.4.2 本書はC87、C90で頒布した『型の国のTypeScript』の改訂(C9
どうも、バンクーバーでぶらぶらしている@t32kです。最近は暇なのでもっぱらOSS活動に勤しんでおります。そんなわけで日々のアプリケーション開発において重要になってくるのがバージョニングです。 今日はセマンティック バージョニングについて解説します。自身が公開しているライブラリやパッケージのコードを何かしら修正したら、それに伴いバージョンを上げるのが一般的だと思うのですが、実はどのようにバージョンを上げるのが適切なのか、昔の私は理解していませんでした。 『いっぱい変更したのでメジャーバージョン上げてみるか』、『今回の修正は軽微なものだし、マイナーバージョンを上げるか』などと、なんとなくにバージョニングをしていました。 If the plugin’s API changes dramatically (for example, when sortOrder option is renamed
東京Node学園祭2014 に参加してきたのでその時のメモ 企業JavaScript飯 #企業JavaScript飯というご飯イベントをNode学園祭のお昼に(勝手に)やってました。 @teppeis、@ahomu、@kyosuke、Layzie (敬称略)で企業内でのJavaScript状況ですかという感じの話をしてきました。 質問テーマのスライド: https://github.com/azu/slide/raw/gh-pages/nodefest2014/lunch.pdf という感じのテーマを元に話をしてきました。 参加していただいた皆さん興味深いお話ありがとうございました。 最近企業のJavaScript(er)ってどんな感じになってて、どういうものを求めているのかに興味を持ってるので、面白い話があったらお話きかせて下さい。(to @azu_re にmention) どうやったら
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
Web2Executable is a friendly command line and GUI application that can transform your Nodejs (or any other JS/HTML) app into an executable (and libraries) that can run in a contained, desktop-like style. It can export to Mac OS X, Windows and Linux all from one platform, so no need to go out and buy expensive hardware. It's powered by the very awesome project NWJS and PySide, is open source, and i
TypeScriptリファレンスお買い上げありがとうございます! Amazon 達人出版会 2014/10/07 TypeScript 1.1.0-1 がリリースされました。ぱちぱち。 コンパイラが書き直されて、大幅な高速化と、わかめが見た感じコードベースのスリム化が行われている気がしなくもない、という感じです。 公式の変更点はChanges between 1.0 and 1.1とList of minor breaking changes from 1.0を見てください。 Playgroundも既に1.1.0-1ベースにアップデートされているようです。 なお、以下の解説はあまり確認せずIssueやサイトに記載の内容を鵜呑みにして記述しております。 言語仕様上の変更 TypeScript 1.0 系の間は、基本的には非互換な変更は導入されないことになっています。Roadmap 非互換な変
Issue管理システムを使っている開発現場では同僚の書いたチケットに悩まされる以下の様な光景が良く見られます。 事例1「何の目的で作られたのか分からないチケット」 ソースレビューを振られたのでチケットを見てみたら、何を変更したいかは分かるけどこの変更がどういう意味があるのか分からないケース 担当者の対応 作業したメンバーの席まで歩いて行って 「ねーねーこれさー、何のために作ったの?」 「あーそれはですね、まず○○という話がありまして、それで…」 (背景から説明されて15分経過) 事例2「ソースを全部読まないと何を変更したか分からないチケット」 ソースレビューを振られたのでチケットを見てみたら10コミットぐらい入れてあるけどチケットの説明が簡素過ぎて何の仕様をどう変更したか(もしくは新規に作ったか)がソースの差分を全部読み込まないと分からないケース 担当者の対応 作業したメンバーの席まで歩い
私は GitHub が大好きです。GitHubはオープンソースへの コントリビューション (寄与貢献)を何十倍も容易に、そして楽しいものにしたと思います。ですが、GitHubがPull RequestというwebのUI形式で前面に押し出しているオープンソースの メンテナー のワークフローが、プロジェクト品質とコントリビューションを受けつけるスピードの弊害になるということに気がつきました。そこで、GitHubの Pull Request にある「Merge pull request」ボタンをクリックする前に、少しお話をさせてください。 メンテナーの紹介 ジェーンはそこそこの成功を収めているオープンソースプロジェクトのメンテナーです。彼女は毎週プロジェクトのGitHubリポジトリに上がる新しい Issue を確認し、リクエストに対し速やかにフィードバックを返します。リクエストをすべて実行する時
Promise本での利用方法 JavaScript Promiseの本というのを書いてる それぞれのセクションレベルでIssue+pull-reqeuestsで書いてる リポジトリ => azu/promises-book 途中(後半)から積極的にIssueを使い出した Issue数:50、Pull Requests数:20 ワークフロー Issueを立てる git-issue + git-flow + percolでissueのブランチを切る [WIP] pull-requestsを立てる ref #id push -> review merge + close #id でissueも閉じる git flow finish でローカルとリモートブランチを削除
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く