pull request を利用した開発ワークフローの話しですが、あんまりプルリの話ししてないし、コードレビュー的なお話しが多いです…。
pull request を利用した開発ワークフロー
pull request を利用した開発ワークフローの話しですが、あんまりプルリの話ししてないし、コードレビュー的なお話しが多いです…。
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
言語とリーダビリティ - methaneのブログ
この記事は 勝手に添削: PHP初心者向けのコード最適化 の続編です。リーダビリティの定義は前と同じく、「そのコードが何をしたいかを把握する時間＋そのコードをレビューして正しいと自信を持てるまでの時間」の短さです。 よく「php よりも Python の方がリーダビリティが高い」という主張に対して、「Pythonでも糞コードはかける」「言語よりも人の問題だ」といった反論をする人がいます。 この反論をする人は「同じ程度のスキルの人が同じ程度の丁寧さでコードを書く」という暗黙の前提が伝わっていなくて、「リーダビリティは言語に依存して人には依存しない（あるいは人よりも言語に強く依存する）」という主張だと誤解しています。(この主張にかぎらず、大抵「◯◯でも悪い△△は存在する」という類の反論は、暗黙の前提を理解していないか、あるいはわざと無視しているケースが多いです) 言語設計が（書き手のスキルほど
プログラミングはそれ自体が目的であっていい - mizchi log
これ読んで思ったこと。 プログラミングを勉強したい人が勉強する前にすべきこと - もとまか日記 http://d.hatena.ne.jp/moto_maka/20130512/1368308092 僕がプログラミングをはじめたとき、何を思ってプログラミングをはじめたか思い出してみようとしたけど、よく思い出せなかった。 ただ漠然と感じていたのは、プログラミングは個人が現実的にこの世界に直接手を加えることができる手段の1つであり、それをやらないのは勿体無い、といったことだったと思う。たぶん。 というわけで、最初にやったのはFirefoxのユーザースクリプトを書くことだったし、それはそれでよい経験だった。なんとなくゲームとかウェブアプリとか作りてーなー、と思って色んなライブラリを動かすだけ動かして満足した。プログラミング覚えて初めて最初の一年で10以上の言語のHelloWorldだけやったと思
一つのメソッドに上から下にずらっと全部書いてしまう現象の考察 - basyura's blog
とある機能を実装するとする。例えば外から Excecute が呼ばれてその結果を返すような場合。多いのが Execute メソッドの中に全部書いてしまって、何 10 行を超えて何回スクロールするんだろうになっているパターン。その際はレビューで以下のようにアドバイスする。 Execute にはシナリオを書いて、中身は別に書くと良いですと。僕の経験的にこの方が良かった、という深い根拠のないものではある。けど、間違った考えとも思わない。自然だろうと。private なメソッドではインスタンス変数を直接扱うのはやめて、public なめそっどから引数で渡したほうがいいとか細かいところもあるけど、そのへんはすっ飛ばしてまずは上記のようにいう。 そんな考えを持っているので、レビュー依頼されたものやコミット済みの資源をなにかの機会で見たときに、上記に反するものを見かけると気になってしまう。 もうちょっと
瞬くあいだに時はながれて - steps to phantasien
最初のバグ修正 をレビューしてくれたのはたぶん、Apple の Darin Adler だったと思う。雑誌連載のねたづくりに書いたパッチだった。このあとも Darin Adler には度々レビューをしてもらった。私にとって、Bugzilla 界隈でのメンターはこのひとだ。あるとき ASSERT_NO_EXCEPTION という小粋なマクロを私が発明した際も、彼は私にかわりメーリングリストで宣伝をしてくれた。何かをわかりあえたと思った。 最初のリグレッションとその修正は 6 つ目と 7 つ目のパッチで…仕事にする前からエンバグしてたわけですが… KDE の Nicholas Zimmerman が見てくれた。彼はそのあと BlackBerry の会社に入ったと聞いたけど、最近は姿をみない。当時の SVG は無法地帯で、やんちゃなパッチもけっこう見逃してもらえた。Zimmerman, KSVG
マジカルsvnとキュアgit
2011年4月18日(火)に実施した、プライベートセミナー『アジャイル開発環境セミナー～一般ユーザが知っておきたいJIRAの概念と操作～』での資料です。
遠隔操作事件のプロファイリングが酷すぎる。いくらなんでもそれはない
まあなにかと物議を醸してるブログですが遠隔操作ウイルス開発者のプロファイリング - とあるソフトの開発記録http://d.hatena.ne.jp/c299792458/20130304/1362412084 ↑この内容が酷すぎるので技術者の端くれとして一言いいたい(そういう釣りなのか?まあ釣られるクマー) 犯人につまらん恨みを買うかも知れないので増田で書く まず、警視庁が今回のウィルスについての情報をまとめていて、これでなにか解る人ヒントを下さいということらしい↓http://www.keishicho.metro.tokyo.jp/jiken/jikenbo/enkaku/sub4.htm 警視庁もよほど困っていると見えるけど、こんなもので犯人が特定するのはものすごく難しい。 ソースコードの内容が公開されてるなら別だけど、ああさすがにソースそのものは手に入らないのか。 これはオブジ
自己流のSQLインジェクション対策は危険
HTMLエスケープの対象となる < > & " の4文字は、文字実体参照に変換された後、preg_replace関数でセミコロンを削除してしまうので、中途半端な妙な文字化けになりそうです。 一般的な原則としては、データベースにはHTMLの形ではなくプレーンテキストの形で保存しておき、HTMLとして表示する直前にHTMLエスケープする方法で統一することで、上記のような文字化けやエスケープ漏れをなくすことがよいでしょう。 脆弱性はないのか このsanitize関数に脆弱性はないでしょうか。上表のように、バックスラッシュ（円記号）を素通ししているので、MySQLや、設定によってはPostgreSQLの場合に、問題が生じそうです。以下、それを説明します。以下の説明では、MySQLを使う想定とします。 以下のように、ログイン処理を想定したSQL文組立があったとします。 $sql = sprintf(
BitBucketのいいところ - methaneのブログ
KLab では、プロジェクト開発中に作った便利ツールなどを皆が気軽に社内で公開できる場としてBitBucketの無制限プラン($200/month)を契約しています。 今日は Github に比べていいなと思う点を紹介していきます。 1. アクセスコントロール Githubだと、書き込み権とadmin権が一緒になってしまっていましたが、BitBucketではadmin権とwrite権が分かれていたり、Team（GithubでいうOrganization）の Owner グループでなくてもリポジトリを作ることができます。 特にadmin権がなくてもリポジトリが作れるので、「皆に気軽にリポジトリを作って欲しい」を実現するために皆に Team の admin権を渡さなくていいのが利点です。 deploy key についても、同じ公開鍵を複数のリポジトリに登録できるのと、pushが禁止されているの
if-then-else文の順番 : 小野和俊のブログ
ペアプロで if-then-else 文が出てきた際、「これ、else if の順序、こっちの方が良くない？」というような会話をすることが時折ある。 どれも当たり前のものかもしれないが、「ああ、確かに」という反応があることもあるので、今日はそんな会話の際に出てくる視点についてまとめてみた。 if (よくあるケース/正常なケース) { // 処理 } else if (比較的特殊なケース) { // 処理 } else if (さらに特殊なケース) { // 処理 } else { // 処理 } 条件式の結果がtrueになる確率が高く、「ノーマル」に近いものを上に書く。可読性が上がる他、特に2.で触れる条件式の判定に時間のかかる場合や、ループの最奥にある処理などのif-then-else文の実行される回数が極めて多い場合には体感レベルで実行速度にも大きな差が出ることもある。 Code Co
同僚の書く酷いコード、どうやって気づかせる？ | スラド デベロッパー
私の同僚は非常に頭がよく、ソフトウェアの知識も豊富だが、想像を絶するほどひどいコードを書く。たとえば、 すべてのプログラムは1つの関数に詰め込まれ、際限ない繰り返しのせいで無駄に引き伸ばされている 変数名やクラス名から得られる情報は泣きたくなるほど少ない コードを短く、読みやすくするための基本的な言語機能は無視されている オブジェクト指向プログラミングの虐待は吐き気を催すほどで、戦争犯罪レベルといえる しかし、彼は私が生まれる前からプログラミングをしており、非常に頭が良いことで、人の意見に耳を貸そうとしない。そのため、「この関数をこのように書いたら良くなると思いませんか」といった簡単な提案は受け入れられないだろう。彼に事実を伝え、良いコードと悪いコードの区別をわかってもらうにはどうすればいいだろうか。
App Engine ドキュメント | App Engine Documentation | Google Cloud
App Engine は、大規模なウェブ アプリケーションを開発およびホスティングするための、フルマネージド型のサーバーレス プラットフォームです。アプリの開発では複数の一般的な言語、ライブラリ、フレームワークからの選択が可能で、開発したアプリのインスタンスのサーバー プロビジョニングとスケーリングは App Engine によってオンデマンドで行われます。詳細については、こちらをご覧ください。
下から目線のコードレビュー - steps to phantasien
WEB+DB の新しいやつがちょっと前にでてます. コードレビュー特集だそうな. 時が経つのは早い. まだ次の原稿書いてないのに… そういえば前にコードレビューの話を書いた気がして, 見なおしたところ かきかけ だった. せっかくなので続きを書いてみることにします. といっても何書くつもりだったか覚えてないのでだらだらと. WEB+DB PRESS の特集は, 主にこれからコードレビューを導入したい人に向けて書かれている. 幸か不幸か私はコードレビューを義務付けれたプロジェクトで働いているため, 導入には苦労していない. かわりにレビューをちょろまかせない面倒はある. ある意味でコードレビューを <やらされている>. もちろんこの言い分は大げさだ. 必要性に異議を唱える気はない. ただ異議はさておき自分の意向とは無関係にコードレビューに参加している気分を書いた話は あまり目にしないので,
RhodeCode
RhodeCode 1.3.6 Released Posted on May 19th, 2012 | Read more RhodeCode 1.3.5 Released Posted on May 13th, 2012 | Read more RhodeCode 1.3.4 Released Posted on March 29th, 2012 | Read more RhodeCode 1.3.3 Released Posted on March 3rd, 2012 | Read more RhodeCode 1.3.2 Released Posted on February 28th, 2012 | Read more RhodeCode is a fast and powerful management tool for and GIT with a built in push/
コードレビューいろいろ - steps to phantasien
コードレビューの話をいくつか見かけた. (1, 2, 3) 私もはやりにのってなにか書いてみたい. といってもリンク先についてどうこう言う気はない. ふだんからぼんやり感じていることをテキストにしてみたい. コードレビューの様式 コードレビューのやりかたは色々ある. 話の背景をあきらかにすべく, まずは私が参加したり見聞きしたりしてきた方法を紹介したい. ただとりとめなく列挙しても見通しが悪いから, 方法を評価する軸を見立てておこう. コードの粒度: 一回のレビューでレビュアが目を通すコードの量はどのくらいだろう. プロジェクト全体? モジュール単位, 機能単位, それともクラス単位? 古典的なレビュー様式はこれら <論理的な単位> でレビューをすることが多い. 最近はブランチやコミットのような <ひとまとまりの変更> を単位とする方法に人気がある. Github の Pull Reque
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
おっさんの同士よ、楽せず歯を食いしばって頑張ろう: ある nakagami の日記
オープンソースソフトウェアの育て方
レビューのススメ？
Phacility - Home