技術的負債の生態 - maru source
@t_wadaさんが翻訳されていた技術的負債の記事をあらためて読んでみたら非常に面白かった。技術的負債の本来の意味が説明されているので、まだ読んだことがない人は一読をおすすめする。 その翻訳記事を読みながら、Jasper（僕が開発しているGitHub用のIssueリーダー）のv1.0で技術的負債を返済したことを思い出した。そこで、その翻訳記事を参考にして技術的負債の生態について自分なりに考えてみることにした。すると面白い生態がいくつか見えてきた。例えば「生態③: むしろ技術的負債が生まれることそれ自体はポジティブである」などである。今日はそのことについて書いてみようと思う。 ちなみに今回は技術的負債への対処までは解明することができなかった。いつか続きを書けたらいいなと思う。 技術的負債が生まれる背景 まずはJasperで経験した技術的負債を紹介する。負債の内容自体はそんなに重要ではないので
ミルクボーイがアジャイルを説明したら
序章駒場「最近、うちのおかんがシステム開発に興味を持っててなぁ、名前は忘れたらしいんやけど、迅速に開発できて、仕様変更にも対応できる、素晴らしい開発手法を取り入れてるところがあるらしいんやわ〜。」 内海「そんなもんアジャイルに決まってるがなぁ〜! 今やシステム開発と言えば、アジャイル。素早く変化に対応できるってゆーのが特徴なんよ。そもそも名前が “迅速” を意味する英語やねんから、アジャイルに決まってるがなぁ〜。」 チームの人数駒場「最初、オレもそう思たんやけどな、なんでも 40 人ぐらいで開発してるらしいんやわぁ〜。」 内海「ほなぁ、アジャイルちゃうかぁ…。アジャイルでは 5〜9 人ぐらいが推奨されてるからなぁ〜。40 人もおったら、とてもやないけど、コミュニケーションが成立するとは思われへんなぁ〜。効率の悪い伝言ゲームになるのは目に見えてるからなぁ〜。おかん、他にもなんか言うてなかった
本番環境のデータをマスクしてステージング環境に同期する - 食べチョク開発者ブログ
こんにちは。エンジニアの西尾です。 食べチョクのステージング環境では、本番環境のデータを日次で同期して利用しています。 今回はステージング環境の役割と、どのようにデータ同期をしているのかについてご紹介いたします。 ステージング環境 食べチョクでは、手元のマシンでプログラムを修正しコードレビューを実施後、改修内容をステージング環境にデプロイしています。 ステージングは、本番へのリリース前に修正箇所の動作確認・検証する環境です。この環境で動作や性能に問題がないかを確認後、本番環境へのデプロイを実施しています。 ステージング環境には、本番と同等のデータが入っています。 リリース当初は、ステージング環境と本番環境のデータは同期しておらず、テスト用のダミーデータで動作確認を行っていました。 しかしダミーデータでの確認だと、 ダミーばかりが並んだサイトと本番環境では見た目や印象が違っていて、UIが最適
読書メーター開発チームのご紹介 | トリスタinside
おはようございます。読書メーター開発チームの荻野です。本記事では、トリスタの提供する読書メーターというサービスと、それを開発するチームについて紹介していきます。 読書メーターとは 読書メーター ( https://bookmeter.com ) は、「読んだ/読んでる/積読/読みたい」といった読書管理や、書籍への感想投稿を通して、ほかの読書家とコミュニケーションができるサービスです。読書SNSとしてはユーザの活発さが特徴で、感想やつぶやきを投稿するとすぐにリアクションがつくので、使っていてとても楽しいサービスです。感想投稿数も国内最大級なので、読書好きでしたら是非使ってみてください。 サービス形態としては、Web（PC/スマートフォン）とアプリ（iOS/Android）のほか、BOOK☆WALKERなどの電子書店にAPIを介した書籍レビューの提供も行っております。 これから紹介する読書メー
VancouverにあるAmazon S3チームのDeveloperになります - As a Futurist...
tl;dr - Amazon に入って 3 年が経ちましたが、この度転籍という形で Canada の Vancouver にある Amazon S3 開発チームに Systems Development Engineer として移ることになりました。 2010 年頃からずっとなりたいと思っていた北米での開発者の仕事(もちろん英語のみ)なので、本当に嬉しいです。AWS の Solutions Architect(SA)としてお客さんと向き合う仕事をじっくりさせてもらい、そこから実際に開発をしているチームに開発者として拠点も含めて移れるキャリアパスがあるんだよ、という一例になれましたので、SA になると自分の手を動かす機会が減ってしまうことを懸念している開発者の方の背中を押せたら幸いです。なお、2018 年 6 月頭に日本を出国予定で日本の会社も退職してしまうので、(旅行を除いて)日本に戻って
「全アクセスがmemcachedに行ったら負け」超大量リクエストをさばくフリークアウトの技術哲学
「全アクセスがmemcachedに行ったら負け」超大量リクエストをさばくフリークアウトの技術哲学 アドテクノロジーの雄、フリークアウトのエンジニアは、日々圧倒的な量のリクエストと戦っています。こうしたシビアな世界での仕事は、若きエンジニアをどのように鍛えるのでしょうか。 株式会社フリークアウト。アドテクノロジーに携わる者ならば、その社名を1度は聞いたことがあるでしょう。DSP*1のシェア国内トップクラスである同社は、高い技術力に裏付けされた信頼性の高い広告配信サービスを提供しています。 その安定した技術基盤を生み出すには、メンバーの育成やカルチャーの醸成が必要不可欠です。フリークアウトはいかにして、“強いエンジニアチーム”を作り上げているのでしょうか。 広告配信インフラやデータ基盤などを担うAccelerator divのテックリード本間雅洋（ほんま・まさひろ／@hiratara）さんと、
グローバルゲームジャムでクラス設計をやった話2017 - Qiita
お知らせ 2017/11/26開催の「プログラマのためのUnity勉強会」において、 Unity開発で使える設計の話＋Zenjectの紹介 というタイトルで講演しました。こちらのスライドを先に見てから本記事を参照されることをおすすめします。 はじめに 去年に引き続き、今年もGGJに参加してきました。今回もそのことを書きたいと思います。 今回の内容は以前に投稿したUnity開発で便利だったアセット・サービス紹介 & Unityでのプログラミングテクニックとつながりがあるので、こちらを先に読んでからのほうがわかりやすいかもしれません。 Global Game Jam とは GGJとは全世界同時に行われるゲームジャムのことです。要する、世界規模のゲーム開発ハッカソンです． プログラマ、デザイナ、プランナ、グラフィッカなど様々な役職の人をごちゃまぜに、3～8人程度のチームを組み、48時間でゲームを
16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ
技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム（16年の歴史があります）の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、
消滅会社 AppBankGAMESを終えて・ゲーム作りで大事なこと - hotmiyacchiの日記
2015-10-19 消滅会社 AppBankGAMESを終えて・ゲーム作りで大事なこと 創業から３年間社長を務めたAppBank子会社の消滅 長文ですが、奇しくもAppBankが上場した週にこんな記事を書いたのは、社長を退任した感傷的な衝動っぽいですが、よっぽどしょぼい話で、かつ、会社も職も失ったけど、大事なことは何かを再認識するための話です。 紆余曲折あってAppBank GAMESという会社は、創業から３年を経たところでグループ内の別会社に吸収され、それもまた前向きな成り行きと皆んなで承服し、私は社長を退任しましたが、それぞれが前向きに進み、遂には会社が上場するという大きな節目を迎えました。 っと、まじめな謝辞を述べたいというより、失敗談をしなければと思うことがありました。 かつ、今のタイミングを逃すと、せっかく皆で学んだ大事なことが濁りそうというか、我々が犯した大きな失敗がまた別の
大企業でスクラムしたら筋肉だった
あなたのチームの「いい人」は機能していますか？Minoru Yokomichi169.5K views•56 slides 凡庸なSEが、大規模SIerの集団でできること - DevLOVE甲子園 2013Minoru Yokomichi13.8K views•35 slides
コードレビューポエム - その手の平は尻もつかめるさ
これはポエムです (It's just like a unko)． ■ 「なぜコードレビューをするのか」という問いに対する答えは様々だ．コードの品質を上げるため，コードレビュー自体が楽しいから，あるいはコードレビューやってる俺たちって恰好良いじゃん，などなど色々ある． これらは全部正しいと思う．コードレビューをすればコードの品質が高くなる可能性は強まるだろうし，「コードレビューが楽しい」という感情がコードを書くための原動力になるのであればそれは良いだろうし (なぜならコードレビューをするにはレビュー対象たりえるコードが必要だ)，「コードレビューやってる俺たちって恰好良いじゃん！」というのも結構だ．貴方がたは本当に恰好良いヨ！ さて，コードレビューという話題に必ずついて回る尤もらしい理由の1つである「コードの品質向上」について考えたい． なぜコードレビューがコードの品質を上げるための手段とし
OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい（もしくはコードレビューの話） - kazuhoのメモ置き場
以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。 チーム開発の場合、簡単にコメント返せないようなPR送られた時点で負けだと思ってる。無駄なコードが生産されないよう事前に設計を詰める作業をすべき / “雑なレビュー - ✘╹◡╹✘” http://htn.to/by5or1 https://twitter.com/kazuho/status/431602421068877824 今日一般的に想定される「OSSの開発モデル」はEric S. Raymondの有名なエッセーである「伽藍とバザール」によって解説されたところの「バザール」である。 「バザール」モデルにおいては、多くの改善提案の中から最善と考えられる実装が取り入れられ、コミュニティで共有されるようになる。同エッセーから引用するなら、 ふりかえってみると、Linux の手法や成功の前例は G
プログラマの生産性と報酬 - アスペ日記
追記: 続編を書きました。マッチョとの戦い 最近、プログラマの生産性が話題です。 いろんな意見があるものの、個人的には 10〜100倍の生産性の違いはあると思います。 いや、それは違う、生産性の高いエンジニアは生産性の低いエンジニアに作れないものが作れるのだからそういう話ではない、という意見もあります。 しかし、実際には生産性の低いエンジニアができもしないことをしようとして結局できないで終わるということがあったりしつつも、何らかの貢献をするというのが普通だと思いますので*1、最終的には 10〜100倍の違いといった形に落とし込めると思います。 で、この生産性の違いはどこから来るのか。 個人的には才能だと思っています。 ぼく自身は、自分のことを中間レベルのエンジニアだと認識しています。 平均の 3〜10 倍できて、トップより 3〜10 倍できないくらい。 でも、自分が平均から抜け出るために何
はてなで実践している社内コミュニケーション方法 - Hatena Design Group
こんにちは。はてな デザインチームの id:ueday です。 どうしたら会社（あるいはチーム）でのコミュニケーションを円滑に・楽しく行うか、というのは常に悩みどころですよね。私達も今までに色々なツールや方法を試していて、日々ベストプラクティスを探しているところです。 この記事では、はてなで実践している社内コミュニケーション方法についてご紹介しますが、常に試行錯誤しているので、これが最適、とは言い切れないところがあります。現時点の方法としてご紹介したいと思います。 東京・京都の2拠点を繋ぐ はてなでは、京都と東京の2拠点で開発をしています。そこで活躍するのが、「ポリコム」というテレビ会議システムです。打ち合わせや朝会はこのポリコムを通じて行うので、物理的な距離を感じずにコミュニケーションがとれるのです。詳しくははてなのカルチャーをご覧ください。 カルチャー - 株式会社はてな メールは使わ
開発時に出会いたくないパターン - Perl日記
悩んだりうまくいかなかったり解決したり。だらだら書いた。 手作業症候群 とにかくなんでもかんでも手で確認・作業する必要があると思い込んでしまう病。 そりゃiOSアプリとかAndroidアプリとか最終的には実機確認は必須だけれども。 その前にやれることは多々あるはず。リグレとか。 あと「デプロイ職人」も不要にするべき。わかってる。 自動化できない要素を突っ込んでる方が悪いのだ。なんとかする。 masterブランチぶっこみ志向 masterブランチに直接コミットを重ねていくことにより開発速度をアップさせることができる。 ただし孤独な背水の陣を構えることになる諸刃の剣。 おとなしくtopic branchを切って作業するのが安心への近道であり王道である、 とか言ってたらみんなちゃんと切ってくれるようになった。めでたし。 チケットそっ閉じ症候群 本来はリリースしたりデータを修正したりしてチケットと
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
Gyazo GIF Winの話 - ひでシスのめもちょ
※参照：uiureo: Gyazo GIFの話 夏の間、開発に関わってきたサービスが一昨日リリースされた。Gyazo GIFというスクリーンショットを動画で共有できるというサービス。画面の一部を映像として切り取ったGIFアニメを簡単に作ることができる。 https://gyazo.com/ja Gyazo GIFは後輩のuiureo個人で開発していたGifzoというサービスの後継にあたる。Gifzoは2週間で開発され、売却され、Gyazo GIFとして生まれ変わった。僕自身の記憶のために少しだけGifzoの話を書いておきたい。 Gifzo Gifzoは前述の通りuiureoくんが個人で開発したサービスだ。サービスがある程度形になったとき彼はサークル内チャットでその動作確認を兼ねたお披露目をした。 一方、僕は語学一単位だけ落として暇な留年期間を送っていた。彼はクライアントをMac版しか開発し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
さらに上を目指すための iOS アプリ設計
github を用いた開発フローテンプレート
クックパッドのインフラ責任者が語る、DevOpsを成功させる考え方「迷ったら健全な方を選ぶ」～DevOps Day Tokyo 2013
