コードレビューをしよう - ppworks.jp
Sendagaya.rb #86 - Sendagaya.rb | Doorkeeperに参加してコードレビューについて思うところをみんなでディスカッションしたので、自分の思いをまとめておきます。（ポエム） ソニックガーデンの @mah_labさんのスライドにある7つの秘訣に同意です基本。あと、github上のプルリクでコードレビューするという前提でまとめます。 1. レビューの観点を明確に いま何の話をすべきかという状況を判断して、どの観点で物を言うのかっていうのはコードレビューだけに限らず打ち合わせ時にも大事ですね。今この観点で議論を進めますよ！ということを表明することで齟齬が防げます。 観点が明確だと議論のテーマが明確になるので、コードレビューで修正すべき点も分かりやすくなりますね。 コーディング規約の観点 セキュリティの観点 メンテンスの観点 設計の観点 リリース前にこれで出来るレ
株式会社ジェニュインブルー解散及び清算のお知らせ - ppworks.jp
これまで株式会社ソニックガーデンのギルドメンバーとして株式会社ジェニュインブルーを立ち上げ、納品しない受託開発により複数のスタートアップ企業様のシステム開発に携わって参りました。 この度、パートナー企業様のビジネスの発展に伴いそれぞれのサービスが私の手から離れたタイミングで会社を清算することになり手続き中です。なにより携わったサービスがみな順調であることは嬉しい限りです。 直接ご挨拶が出来なかった方も多いのですが、これまでご愛顧賜りました皆様に心より感謝申し上げます。
WIPであろうと、情報共有すると何がいいのか？ - ppworks.jp
口頭で話したことを文字に起こすことについての続編のような記事です。 消え行く知見や、消え行く情報を文字にすることで永続化させ、密室の議論を無くす。その為に以下のような活動が重要という話を書きました。 口頭で相談したことをesaやqiita:teamにまとめる 口頭でコードレビューしたことをgithubやgitlabのコードレビューのコメントにも書き残す 口頭で話したことをチャットにも書き残す チャットで話しかけた後に口頭で済んだ場合、チャットに解決済と流す 情報共有すると何がいいのか？ 何がいいか。 暗黙知を減らすことが出来る 当事者に なろうと思えばなれる なろうと思えばなれるというのは、どういうことかというと、共有化された情報は、その情報をどう捉えてどう向き合うか情報を得た側が選択してこそ価値が出る。 共有された情報に対して当事者意識を持つかどうかは情報と向き合った人に委ねられるという
それでもRailsを選択する3つの理由 - pblog
スタートアップ界隈でのRuby on Rails利用率は割と高く感じる。 みんなが使っているから使う？それだけではないはず。なぜ使うのだろう。 railsの特徴を考える。 規約縛りの哲学 周辺gemのエコシステム webの進化への追従の速さ 規約縛りの哲学 Convention over Configurationてやつ。規約を決めて、それに沿えば、フレームワークに乗って素早く開発できるようになる。規約で縛ることでRailsに流れる哲学に従うことを強制化している。 外れると痛い目を見る。Railsに乗るということは電車に乗って簡単に遠くまで行けるということ。Railsから降りるということは電車からも降りるようなものだ。中途半端な理解で突き進むと線路からすぐに降りて歩くことになる。 スタートアップでRailsが採用される一番の理由は、 簡単に遠くまで行ける だと思う。ただ、そんなにうまい話は
pplog開発のコードレビューから学ぶpull requestによる自律的行動とコミュニケーション - ppworks.jp
pplogの過去のポエムを複数単語で絞込できるようになりました。 pplogは、自身と向き合い想いを言語化するためのサイトだったりします。（色んな使い方があります） 最新のポエムだけが他人に見えますが、 自分の 過去のポエムを見る機能があります。 この過去ポエムは検索機能が付いているのですが、先日まで複数単語で絞り込むことが出来ませんでした。 pull requestが来た id: shootaさんからpull requestを頂きました。 勝手にやった！まさにこれだ！と思いました。 よし、コードレビューをしよう！ 命名に突っ込んだ これを見て思うところがありました。 search_word_arrays = params[:keyword].gsub(/ /," ").split() 私は言った for文にナニカを感じた し、Cぽい！ search_word_arrays = param
クソコードと呼ばない - ppworks.jp
新しい現場にはいったときに心がけていること、クソコードと呼ばないこと。 誰かのコードを読んでいるとそりゃまあクソコードを見つけることがある。その時どう立ち向かうかという精神論の話。 例えソレがそうであってもソレを口にするとネガティブが蔓延する。思ってもイイ、でも言ってしまってはならない。あるフェーズに置いては必要だった し、現に動いていて価値を提供している のだ。あるべき姿を叫ぶの簡単だ。あるべき姿を見ているなら行動しないといけない。見つけたらリファクタだ。出来るところからやるんだ。 Shut the fuck up and write some code & 許可を求めるな Pull Request せよ— 🌈KOSHIKAWA (@ppworks) 2014年5月23日 クソはクソと言える空気や文化は大事。良くないものを指摘できるようにはしたい。口の前に手を動かそう。プログラマーなら
コードレビューをし合える文化がチームを強くする - ppworks.jp
コードレビューしてますか？ 「コードレビューをしよう - pblog」でも触れたのですが、 今回はコードレビューの話です。 コードレビューって何からして良いか分からなかったり、レビューアーに負担なんじゃないか、、、って尻込みしがちですが、レビューしてもらう前に気を付けること、なにをレビューしてもらうのか、そして逆にレビューするのか、そして何が起きるのかあたりを考えていきましょう。 レビューして貰う前に気を付けること レビュアーの負担を減らすのは大事です。 コーディング規約に沿っているか？といった簡単なレビューは、犬にやらせるという方法もありますが、そもそもgit-pushする前に、ローカルのgit-commit時点で対処しておくというのもありです。 犬 is rubocopですし、 rubocopやjshintなどをgit-hookにまとめて設定できるpre-commit gemが便利そう
プログラマーがイラレで絵を描けるようになると、こうなる - ppworks.jp
プログラマー、絵が描けないじゃないですか（偏見） こんなじゃないですか。 なので描けるようになりたいなとずっと思っていて、ベジェ曲線って滑らかでナンカヨサソウ、とチャレンジしました。 「ベジェ曲線」習熟ドリル 7,8年前に買ったのがこれ。そう、チャレンジは2回目なのです。前回は3ページぐらいで挫折してました。んで、最近急に暇になったのをキッカケに「よしやろう」という気になり始めたのです。 改訂二版〈Illustratorで学ぶ〉「ベジェ曲線」習熟ドリル 作者: 中村高之出版社/メーカー: ラピュータ発売日: 2005/04メディア: 単行本購入: 2人 クリック: 8回この商品を含むブログ (4件) を見る (2014.1.10追記) なんと、長らく手に入りにくかったこちらの書籍が新装改訂版で再登場とのこと。 表紙が若干、損していた分、今回はスタイリッシュで内容と合っていてヨサソウです。
エンジニアこそ色彩デザインを学ぼう - ppworks.jp
学ぼうよ、と思っていて、 新人デザイナーのための色彩デザイン・配色のルールを学べる本 作者: 柘植ヒロポン出版社/メーカー: ソシム発売日: 2011/10/01メディア: 単行本 クリック: 1回この商品を含むブログを見る を読んでいました。 @ken_c_lo氏が以下のスライドで触れていますが、エンジニアがデザイン学ぶのマジオススメとのことです。よっしゃ、学ぼう。 新人デザイナーのための色彩デザイン・配色のルールを学べる本 新人デザイナーのための色彩デザイン・配色のルールを学べる本 作者: 柘植ヒロポン出版社/メーカー: ソシム発売日: 2011/10/01メディア: 単行本 クリック: 1回この商品を含むブログを見る WEBというより印刷のデザイナー向けの本なのかな？という印象なのですが色の使い方という意味では勉強になりました。 特色の話やCMYKプロセスカラーの話は一旦無視しながら
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
