よーし、Git を学んでチーム開発しちゃうぞ〜って時に読むべき本を発見した - ppworks.jp
『わかばちゃんと学ぶ Git使い方入門』を頂いたので感想を！ わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉 作者: 湊川あい,DQNEO出版社/メーカー: シーアンドアール研究所発売日: 2017/04/21メディア: 単行本（ソフトカバー）この商品を含むブログ (2件) を見る なんなの Web業界に憧れる、マイペースな大学生、わかばちゃんが主役。 pplogがキッカケで形になった本があるらしい #わかばちゃんと学ぶwebサイト制作の基本 - pblog Webデザインという単語は、知っていて何となくカッコイイし興味を持っている人が、Webサイト制作〜運用までの一連の流れを知る取っ掛かりとしては、すごく良くまとまっている 前作はWebデザインを切り口に、Webサイト制作〜運用までをカバーした内容だったけれども、本作はバージョン管理システム
Circle CIでbundle updateのPull Request作成を自動化する手順 - ppworks.jp
日々、bundle updateしてますか！ circleci-bundle-updateとcircleci-bundle-update-prを使って、bundle updateの Pull Requestを自動化する手順をまとめてみます。作者の記事を読めばいいっちゃいいんですが、地味に抜けていた手順と各ステップは何のために必要かを整理してみました。 このgemは、Pull Requestに各gemの差分リンクを貼ってくれるのが便利だな！って思って採用してます。素敵なgemをありがとうございます。 github.com github.com ステップは CircleCI経由でbotからgithubにpush出来るようにしておく CircleCI経由でbotからgithubにPR作れるようにしておく 外部からCircleCIへbuild指示できるようにする 外部からcronでCircleCI
それでもRailsを選択する3つの理由 - pblog
スタートアップ界隈でのRuby on Rails利用率は割と高く感じる。 みんなが使っているから使う？それだけではないはず。なぜ使うのだろう。 railsの特徴を考える。 規約縛りの哲学 周辺gemのエコシステム webの進化への追従の速さ 規約縛りの哲学 Convention over Configurationてやつ。規約を決めて、それに沿えば、フレームワークに乗って素早く開発できるようになる。規約で縛ることでRailsに流れる哲学に従うことを強制化している。 外れると痛い目を見る。Railsに乗るということは電車に乗って簡単に遠くまで行けるということ。Railsから降りるということは電車からも降りるようなものだ。中途半端な理解で突き進むと線路からすぐに降りて歩くことになる。 スタートアップでRailsが採用される一番の理由は、 簡単に遠くまで行ける だと思う。ただ、そんなにうまい話は
FactoryGirlで用意されたデータに望むこと - ppworks.jp
FactoryGirl というテストデータを用意するためのgemがあります。 読んだ人に、どんなデータが入ることを想定しているか、それが伝わるデータを用意していきたいですね。'MyString'じゃなくて、例えばどんなデータなのかを教えて欲しいのです。 伝わりづらい例 FactoryGirl.define do factory :post do title "MyString" content "MyString" end end 具体的な例 FactoryGirl.define do factory :post do title "pplog開発のコードレビューから学ぶpull requestによる自律的行動とコミュニケーション" content "pplogの過去のポエムを複数単語で絞込できるようになりました。" end end FactoryGirl.define do factor
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が便利そう
おれおれWebサービスの開発〜運用って話をした話 - ppworks.jp
社内で不定期の勉強会があり、入社初日か2日目あたりにたまたまその勉強会が行われておりました。おーこれはいい雰囲気だ、というわけで次回はお話させてもらおうと早速手を上げました。MF Geeks Nightというエンジニア主導の会です。 てなわけで自己紹介がてら、個人でのWebサービスの開発〜運用をどうやっているかというお話をさせて頂きました。YAPC::Asia Tokyo 2014 前夜祭での発表資料を加筆修正した版です。 MF GeeksNight pplogの話 from Naoto Koshikawa MF GeeksNight pplogの話 新たな場では、まずは自分からオープンにしていくことを心がけています。こうしたとき、pplogにまつわる何かは良い自己紹介となりますねえ。ありがとう。 そしてエンジニアそういう、自分の興味のあることをシェア出来るエンジニア主導の勉強会の場を提供
KPTツールFURIKAERIをデザインする - ppworks.jp
先日、マネーフォワードのエンジニアブログに「おもてなしの心でコードを書こう」という、振り返りのKPTツールを題材にした記事を書きました。その記事を書くために作ったKPTツールはFURIKAERIと名づけました。今回はその続き、まさかの会社ブログと個人ブログのコラボレート。実は木曜の深夜〜金曜早朝にハッカソンしてKPTツールを作り、会社で記事にし、週末にデザインを当てて今回の記事にしております。何を目指しているのか。 質素なFURIKAERI デザインのない状態がこれです。質素ですね。質素ですがKPTをするための最低限の機能は揃っております。この状態は、ppworks/furikaeri/tree/v1.0.2で参照頂けます。 $ git clone git@github.com:ppworks/furikaeri.git $ git checkout v1.0.2 お化粧しましょう まずは
Webサービスはヨシヨシしないとスネる - ppworks.jp
ちょっと最近構ってあげられていなかったんですね。そしたら、どうもpush通知が死んでいた模様。つまり、pplogはスネていた。 最近 pplog の通知が飛んでこなくなってしまった— ぺこちゃん (@ryopeko) 2014年10月16日 @ken_c_lo #pplog で購読してる人たちのポエム更新push通知がﾄﾄﾞｶﾅｲ疑惑— イカID: Toshiwo (@toshiwo) 2014年10月28日 ios8関連かなーと静観していたのですが、昨日ようやく本腰で調査しました。 まずは、ポエんでみる pplogは、herokuで運用しており、ログはAddonのpapertrailに流しております。なのでpapertrailを眺めながらポエんでみました（ポエむとはポエムを投稿すること）。すると、こんなログが pplog app/web.1: Too many channels (100
コードレビューをしよう - ppworks.jp
Sendagaya.rb #86 - Sendagaya.rb | Doorkeeperに参加してコードレビューについて思うところをみんなでディスカッションしたので、自分の思いをまとめておきます。（ポエム） ソニックガーデンの @mah_labさんのスライドにある7つの秘訣に同意です基本。あと、github上のプルリクでコードレビューするという前提でまとめます。 1. レビューの観点を明確に いま何の話をすべきかという状況を判断して、どの観点で物を言うのかっていうのはコードレビューだけに限らず打ち合わせ時にも大事ですね。今この観点で議論を進めますよ！ということを表明することで齟齬が防げます。 観点が明確だと議論のテーマが明確になるので、コードレビューで修正すべき点も分かりやすくなりますね。 コーディング規約の観点 セキュリティの観点 メンテンスの観点 設計の観点 リリース前にこれで出来るレ
プログラマーがイラレで絵を描けるようになると、こうなる - 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ページを開く
