普段，エンジニアの暮らしというとコードを書いているイメージだけど，実際には，1日8時間のうち2〜3時間しかコードを書けていなかったりする． 実際にはエンジニアはふだん何をしているのか，こういうことを気をつけている，とか，今日の1日はこういう形でした，といった立ち居振舞いを集めて，知見として集めていきたい． ということで，エンジニア立ち居振舞いのお題を作りました． お題「エンジニア立ち居振舞い」 せっかくなので1つ紹介して終わろうと思います． 立ち居振舞い：GitHubの通知を全部見る 僕はチーム内では長い期間在籍しているエンジニアで，一日中GitHubの通知を見ている． GitHubで通知が来るということは，誰かが仕事を進めたということで，何か質問を書いたり，方針を書いていたり，コードをpushしたり，いろんなことを誰かが進めている． そういうときに，そのissueにとって役立ちそうなこと

はじめに 先日、社内で「良いコードの書き方やお作法、プログラミングの原則って、どうやったら身に付くんだろうねえ？」という話になりました。 もちろん、「本を読んで勉強する」っていのも勉強法のひとつなんですが、そもそも、もっと強烈なモチベーションがないと、必死になって良いコードの書き方やプログラミングの原則って勉強できないのでは？なんて思ったりします。 強烈なモチベーションというのは、たとえば、 いったい何なん！？このスパゲティコードは！！！ なんでこんなコードを俺がメンテしなきゃあかんの！！？？ あ～、もう最悪や！！俺はこんなコード、絶対に書かへんぞ！！！！ っていうぐらいのモチベーションです。 というか、これは単純に僕のケースですね、はい。 幸い、ソニックガーデンに入ってからは、周りのプログラマがみんなちゃんとしているので、そんな思いをすることはほぼなくなりましたが、前職、前々職ではそんな

みんなのウェディングで開催した『デザイナー×エンジニアLT＆交流会（マネーフォワード×ママリ×みんなのウェディング） デザイナーとエンジニアが強力タッグを組んだサービス開発！』の発表スライドです。 デザインをデザイナーだけじゃなく、チームで課題解決に取り組んだ方法をご紹介しています。

デザイナーさんとよい関係を作ろう! 平岡 桂典 (ひらおか けいすけ) for ノンデザイナー 陥りがちな状況 デ「ここ変更したんですがどう思います?」 (デザインわかんねー...) (デザインわかる人だとイケてる提案とかでき …

「デザイナーとエンジニアが協力タッグを組んだサービス開発」 登壇資料 Connehito inc. デザイナー 古市聖恵 (@kiyoe_furuichi) , エンジニア 高野福晃 (@fortkle)

はじめに こんにちは、モバイルファースト室の@y_310です。 部署名からもお分かりの通りクックパッドでは今年からスマートフォンアプリの開発に特に力を入れて取り組んできました。 実際に昨年と比べて開発体制が大きく変化しています。以前はアプリ開発専門のエンジニアのみで開発していたものを、サーバサイドエンジニアもアプリ開発を学び、自分が所属する部署に必要な機能をアプリに実装するようになりました。 そのため、以前は2、3人のチームでの開発だったものが、現在は多い時には複数の部署にまたがって10人ほどのエンジニアが1つのアプリにコミットする状況になりました。 そのような環境の変化によりアプリの品質維持が大きな課題となり、この半年間継続的に品質改善に取り組んできました。今回はその改善プロセスについてご紹介したいと思います。 課題 取り組みを始める前は、様々な部分で課題がありました。 具体例を上げると

ステップ数で評価が決まる現場では全く役に立たないテクニックではありますが、ソースコードの減らし方について紹介したいと思います。 開発Div. エンジニアのayasudaです。 2014年の夏にジョインし、会社名と同じサービス、クラウドワークス の開発に携わっています。 ご覧の通り、消したソースコードの方が多いので、ステップ数換算だとマイナスの働きしかしてませんね！ 本記事では、特に Ruby on Rails の運用されているプロダクトコードにおける、ソースコードの減らし方について紹介していこうと思います。 基本的な考え方 ソースコードを減らすときの大原則は「ボーイスカウト・ルール - プログラマが知るべき97のこと」です。 普段、ソースコードを触るときに、一つでも良いので簡単な改善を入れる。これを積み重ねるのが大事です。 一度に一気に直そうとするのはあまり良くありません。大抵の場合、デグ