コードレビューにこそ、コーチングのアプローチを適用するべきかも - little hands' lab
3つのコミュニケーションパターン 会社でコーチング研修があり、(主に部下と1on1を想定して)コミュニケーションパターンが以下の3つに分けられるという話がありました。 コーチング： 「答え」は相手の中にある 相手の話を聞く/問いかける/人となりを認める ティーチング： 「答え」はこちらにある 知識ややり方を教える/相手が理解してないことを説明する フィードバック： 成長を促すために、周りからどう見えているか、思われているかを伝える ポイントは 「いつもティーチングで自分が思うことばかり言ってしまってないか？アプローチには種類があることを認識し、適切に使い分けていこう」 という話でした。 これだけでもとても面白い話だったのですが、「これ、コードレビューでも同じではないか？」と思ったのです。 レビューにおけるティーチングとコーチング ティーチング ティーチングはいわゆる「指摘」です。 プルリク
Rails を使った EC アプリケーション開発について学べる本 "Take My Money" を読んだ - kymmt
読みました。 Take My Money: Accepting Payments on the Web 作者:Rappin, NoelPragmatic BookshelfAmazon どんな本か 副題が "Accepting Payments on the Web" となっているように、決済 (payment) システムをもつ Web アプリケーションを作る方法について説明しています。『達人プログラマー』などでおなじみの The Pragmatic Bookshelf シリーズの本です。 チケット販売システムの開発を通して、次のような具体的な話題に触れています。基本的には Rails 5 を使ってロジックからビューまでを開発していきます*1。 決済システムの実装 ショッピングカート 外部決済サービスとの連携 サブスクリプション機能 エラーケースとその対策 管理画面の実装 返金など注文の操
Docker / Apache Mesos / Marathon による3倍速いIQONクローラーの構築 - ZOZO TECH BLOG
わーい！コンテナたのしー！🐾 こんにちは。流行りには積極的に乗っていきたい。インフラエンジニアの光野です。 弊社が運営するファッションサイトIQONでは、日々200以上の提携ECサイトから100万のオーダーで商品をクロールしています。 新商品の追加・商品の在庫状況・セールの開催など情報は日々変化するため、弊社において「正しくクロールすること」と「速くクロールすること」は肝心カナメの要素です。 本記事では、特に「速くクロールする」という目的で構築したコンテナベースの新クローラーシステムを紹介いたします。 このクローラーシステムは、最終的にクロール時間67%減、 維持コスト70%減という成果が得られました。 キーワード： コンテナ, Docker, Apache Mesos, Marathon, AWS Lambda, Amazon EC2 SpotFleet 問題解決手段の検討 -> コン
ビジネス貢献するためのエンジニアリングの話をデブサミでしてきた #devsumi - @i2key のBlog
Nintendo switchの初期不良を引き当てたので、ゼルダをやるために開けておいた予定がなにもすることなくなってしまったのでブログを書いた。私のswitchは今頃京都にあるでしょう。 Developers Summit 2017 でコンテンツ委員しつつ登壇もしてきた もともとは、デブサミオーガナイザの鍋島さんからコンテンツ委員としてお声がけ頂き、今回はコンテンツ委員という立場でデブサミに関わっていました。 そのため、コンテンツ委員が登壇とか自作自演感甚だしいので自分が登壇するつもりはまったくなかったのですが、GuildWorks -ギルドワークス-の市谷さんから越境をテーマに株式会社ヴァル研究所の新井さんと自分の3人でやりませんかとお誘いを受け、以下で登壇することに。 「新規事業が対峙する現実からエンジニアリングを俯瞰する」 新規事業が対峙する現実からエンジニアリングを俯瞰する #d
React with Reduxによる大規模商用サービスの開発 / nodefest2016
東京Node学園祭2016で話したブッキングテーブルのやつ
API design guide | Cloud API Design Guide | Google Cloud
Send feedback API design guide Stay organized with collections Save and categorize content based on your preferences. Changelog Introduction This is a general design guide for networked APIs. It has been used inside Google since 2014 and is the guide that Google follows when designing Cloud APIs and other Google APIs. This design guide is shared here to inform outside developers and to make it eas
国内ラボ開発という新たな受託開発のビジネスモデル - GoTheDistance
古い読者の方はご存知かと思いますが、僕は受託開発においてアジャイル開発をそのまま適用するのは否定的で、アジャイル請負は自爆テロと紙一重だとすら思っています。上手くやれる組織もあるんでしょうけど・・・。 アジャイルを受託開発で正しく推進するのなら、ビジネスモデルを大きく変える必要があると見ています。永和さんの価値創造契約や、倉貫さんの納品のない受託開発等、新しい受託開発のビジネスモデルが出て来ました。そんな中、こんな会社があるんだけど知ってますかと連絡がありました。(株)プラムザさんが掲げる「国内ラボ開発」です。 labo.plumsa.co.jp 受託開発専業の会社さんでアジャイル開発を独自の方法論で推し進められているようなので、2/20に開催されたセミナーに潜り込んでみました。 国内ラボ開発のビジネスモデル 契約は準委任契約で、最低契約期間３ヶ月。それ以降は月額課金となり契約解除が可能に
5億件以上の求人情報を蓄積する汎用クローラエンジンのアーキテクチャと運用
「クローリングのスペシャリストが語る、クローラー運用の裏側！#crawler_ops」に登壇した際の資料です。Read less
Golang（Go言語）を採用して、たった二人で基盤となるAPIゲートウェイを開発した話 - メドピア開発者ブログ
はじめに 初めまして、気がつけば先月の25日で入社1年目を迎えた、 技術部 & Sake部部長 の@shinofara（篠原）です。 1月頃からGo言語（Golang） ばかり触りすぎて、PHPをたまに触ると; を忘れて怒られます。 困ったものです.... 今回は、僕も含めた2名で進めてきた、弊社初の Go言語（Golang） プロダクトについてのお話をしたいと思います。 少し長いですが、お付き合いいただければとてもうれしいです！ ※関係無いですが、gopher君可愛いです。 Go言語のロゴ、マスコットは2009年にRenée French(http://reneefrench.blogspot.jp/)さんによって作成・公表されました。 これらはCreative Commons Attribution 3.0 Unported License(http://creativecommons
第2回 プロダクトアンチパターン | gihyo.jp
プロダクトの難しさ プロダクトを作るのは本当に難しい。ユーザーが抱える問題を解決しようとしているのだから当然だ。ひょっとしたらあなたは人類史で初めてその問題に取り組んでいるかもしれない。プログラミングも難しいが、「難しさ」の種類が違うように思う。プログラミングの難しさはソースコードを介して他者と共有可能であり、ソースコードは機械語を解するコンピュータとエンジニア向けに書かれたものなのであいまいさが少ない。一方でプロダクトが解こうとする問題はあいまいで多岐にわたる。「タクシーを見つけるのが難しい」から「一緒にお昼ごはんを食べる仲間がいない」まで、1つとして同じものはない。同じ問題を解いている人に出会えることは少ないだろう。 プログラミングにはデザインパターンというものがある。「この形はどこかで見たことあるぞ」「この種のコードはObserverパターンを使えばきれいに依存を分離できる」
俺が、俺こそがERMasterだ！！ - シスアーキ in はてな
やあやあ、僕ですよ！ 皆さん、ER図作成ツールって何を使っていますか？ 僕は以前にERMasterを使っていて、すごい使いやすかった*1のですが、 テーブル数が多くなると途端に画面が重くなる 一つのビューでしかER図を扱えない という状況があって、それ以来は違うツールを使っていました*2。 ER図作成ツールとして僕の知っている範囲では、 A5:SQL Mk-2 Astah(UML作成ツール。クラス図をER図がわりにしています) MySQL Workbench Object Browser ER などですかね。 どれも一長一短でしっくりきません。 最近、とある大きなプロジェクトをスタートするにあたり、今回もA5かな〜とか思っていたのですが、JJUG CCC Spring 2016でU-NEXTがERMasterを使って大規模開発をしたという話を聞きました！ ここら辺の話はこちらに書いてます！
運用でカバーの波田野さんが現場で得た経験則とCLI支部への思い (1/4)
2週間に1度のペースで勉強会を開催するJAWS-UG CLI専門支部の波田野裕一さん。過酷な運用現場で獲得してきたいくつもの経験則を惜しみなく勉強会につぎ込む。勉強会の会場で、運用とコミュニティにつづられた波田野さんの半生を振り返る。 本連載は、日本のITを変えようとしているAWSのユーザーコミュニティ「JAWS-UG」のメンバーやAWS関係者に、自身の経験やクラウドビジネスへの目覚めを聞き、新しいエンジニア像を描いていきます。連載内では、AWSの普及に尽力した個人に送られる「AWS SAMURAI」という認定制度にちなみ、基本侍の衣装に身を包み、取材に望んでもらっています。過去の記事目次はこちらになります。 DOSからスタートし、SEDとAWKと出会い、モバイルUNIXに進むまで 長年、運用現場で活躍してきた波田野さんは、昔からコンピューター好き。「最初に買ったパソコンはMSX-2。FM
クラウドはライブラリ以上の必須スキル――クラウド時代の開発者の学びをソラコム 片山暁雄さんに聞く
開発者は、ビジネス側の視点を持てば幅が広がる 吉羽 次に、これから開発者の向かうべき方向について話を聞きたいんですけど、今まで片山さんから聞いた話を振り返ると、自分の中の品揃え増やすことが重要なのでしょうか。 片山 あとはその、IT自体が何かの目的を達成するための道具であると思うので、目的をどう達成させるのかという意識。それを持っている人がいいんじゃないかなと思いますね。 吉羽 わかりやすく言うとビジネス側の視点を持つこと？ 片山 一つはそうですね。IoTも、要は今まで取れなかった情報を使って何かしようという世界観じゃないですか。ただ、取ってきたデータを何に生かすかとか、こういう目的のためにはどんなデータを取らなくてはならないという思考って、もっと必要になってくると思うんですね。だからITで改善するだけじゃなく、新しいビジネスをどう作るかを考えることが大事。 吉羽 0から1を考えられること
Railsアプリケーションにおけるエラー処理（例外処理）の考え方 - Qiita
はじめに Railsアプリケーションを本格的に作り込んでいくと、「エラー」とは無縁ではいられません。 しょうもないバグでエラーが発生することもありますし、ほとんど不可抗力ともいえるような大規模なネットワーク障害でエラーが発生することもあります。 エラーの種類がなんであれ、エラーが起きた場合は「原因を素早く特定し、速やかに復旧させること」と「あるエラーが引き金になって、さらに大きなエラーに引き起こさないようにすること」が重要です。 エラー処理を適切に実装していれば、原因の特定や復旧もすばやくできますし、さらに大きなエラーを引き起こす可能性も少ないです。 また、ソースコードも比較的シンプルに保てます。 逆にエラー処理が不適切だと原因の特定に時間がかかったり、異常なデータがどんどん増えてさらに大きなエラーを引き起こしたりします。 ソースコードにも無駄に複雑な処理フローや条件分岐がたくさん出てきて
「客の顔も知らずにUXが語れるか」自らCTOの座を譲った50歳ベテランプログラマーの生き様 - エンジニアtype | 転職type
2015.05.18 ITニュース 弊誌では先月、「New Order—現代のゲームチェンジャーたち—」と題した大型特集を組み、テクノロジーを駆使して新しいスタンダードを生み出そうとする各界の「ゲームチェンジャー」の仕事術や思考法を紹介した。 しかし、そういった学びを得たからといって、現実には全ての人や企業が、ゲームのルールを決める側に立てるわけではない。むしろゲームの一プレイヤーとして、めまぐるしく変わるルールに翻弄されながらも、自分たちにしか生み出せない価値を追求し続けるのが大半の立場だろう。 先ごろエンタープライズ向けクラウドサービス『知話輪（chiwawa）』をリリースしたシステム開発ベンチャーのドリーム・アーツもまた、時代の変化に直面し、このほど一つの大きな決断を下した。1996年の創業からCTOを務めてきた前川賢治氏が退任し、ひと世代下の石田健亮氏へと世代交代したのだ。 人の出
顧客の言うままに作ると、たいてい大失敗します
やまさき ふみのり 1974年、山口県生まれ。早稲田大学大学院に在学していた1998年、趣味のロボット開発の資金を捻出するためにイクシスリサーチを設立。2000年に科学技術振興事業団（現科学技術振興機構）のプロジェクトで2足歩行ロボット「PINO（ピノ）」を開発した実績も持つ。 （写真：陶山 勉） ――どのような経緯でロボットに興味を持ったのですか。 ロボット業界では、「鉄腕アトム」や「ガンダム」などのテレビアニメを見てこの業界を志した人が多いと思います。ですが自分は子供の頃、ロボットのアニメを全然見ていません。実家が山口県の田舎だったので、田んぼでサッカーをしたり山でカブトブシを採ったりして遊んでいました。あと実家の工具箱からノミやのこぎりを持ちだして、工作をしていましたね。木の切れ端を船の形に加工して、川に浮かべたりする遊びです。 そんなふうにモノづくりに強い興味を持っていた小学5年生
マイクロサービス化が進む背景について考えてみた
Why People Want Microservices.md マイクロサービス化が進む背景について考えてみた 最近マイクロサービスって流行ってますよね。バズってると言ってもいいくらい。 個人的には、「マイクロサービスって結局何なの？」とか、「SOAと何が違うわけ？」とかいう議論は苦手です。 でも「なんでみんなマイクロサービスで作りたいのか？なんでマイクロサービスで作られるサービスが多いのか？」にはすごく興味があるんです。 僕は今、シリコンバレーにある日系SIerの小さな子会社で駐在員をやっていますが、このエリアに居ると、とにかく最近、 「サービス全体が、独立した小さなサービスの集合で構成されるようになってきている」 という流れがあるのは実感できます。もうそれが前提みたいになってるくらい。普通サービスって依存サービスを幾つか呼び出しますよね？ってところから始まるのが普通なくらい。 この記
DDD「エリック・エヴァンスのドメイン駆動設計」の読書会のメモ 01 | kanonjiのブログ
エリック・エヴァンスのドメイン駆動設計 ソフトウェアの核心にある複雑さに立ち向かう（Eric Evans 牧野祐子 和智右桂 今関剛） ｜ 翔泳社の本 去年の秋ぐらいから設計に悩む事があり、エリック・エヴァンスのドメイン駆動設計、いわゆるDDD本を買ってました。 なかなか通しで読む時間が取れず、気になる所をつまんで読んでたので、ちゃんと理解出来てないなと思っていた所、読書会をすると言う知り合いが居たので混ぜてもらいました。 折角なので記憶に新しいうちにメモして置こうと思って書いてるけど、理解がふんわりしてるまま、もしくは勘違いしたまま書いてる可能性もあります。 あと、議事録ではないので、あくまで読書会で話した結果、自分が思った事を書いています。 なんか書いてたらすごく長くなっちゃったけど、次回以降もこんなに書けるか分かりません。 今回読んだ範囲 まえがき 第1章 知識をかみ砕く 第2章
クックパッドモバイルアプリの開発体制とリリースフロー - クックパッド開発者ブログ
こんにちは、技術部モバイル基盤グループの @slightair です。 今回は、クックパッドのモバイルアプリをどのような流れで開発しているか説明したいと思います。 この記事では技術的な話ではなく、どのようにして、どのようなことを考えて僕らがモバイルアプリを開発しているかに触れたいと思います。 開発体制 クックパッドにはモバイルアプリを専門で開発するようなチームはありません。 必要に応じて、誰でもモバイルアプリ開発に取り組みます。 機能追加・修正を行ったらリポジトリにプルリクエストを送ります。 プルリクエストが来たら、アプリ開発を行うエンジニア同士でレビューします。 様々な修正をひとつのバージョンにまとめるのは、僕が所属する技術部と後述するリリースマネージャーで行います。 リリースマネージャー バージョンごとに、そのリリースの責任をもつリリースマネージャーをひとり選びます。 リリースマネージ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ポイントシステム基盤を支える技術
