「Facebookにはテスト用サーバがない。リリースとなったらそれをそのまま一般公開するだけ」 - ネタフル
ウォンテッド株式会社社長の仲暁子さん（元Facebook）が、セミナーで以下のような話をされたそうです。 「Facebookにはテスト用サーバーが無いんです。エンジニアはすべて本番環境の上で開発をしていて、リリースとなったらそれを一般ユーザーに見えるように公開するだけ。エンジニアにすごい権限が与えられている。」 これに対してコメント欄でUmihiko Namekawa氏が次のような捕捉をしています。 これは環境や金の問題じゃありません。Facebookという会社の文化なんですね。Facebookの社是がHack! 「フェイスブック 若き天才の野望」にマークが寝そべって雑談しながらノートパソコンにコードをばしばし打ってEnter!でいきなり機能を公開しちゃうのを見てVCが肝を冷やす、というシーンが出てきます。当時でもユーザー500万というスケール。 なるほど、Facebookの企業文化なので
quick hackの必要性 - blog.nekokak.org
ふと思ったのでメモっておく位の感じ。 仕事ではquick hackって重要だなぁと。 業務で本当に必要と思うような仕組みがあったとして、それをすぐに導入できるかは大人の事情とかがあり なかなか難しかったりするのが普通じゃないでしょうか？ 必要な仕組みだから周りだったり上司だったりを説き伏せて正しい（？）手段で導入するのももちろん正道だとおもいますが、 それがなかなかムズカシイのも世の常かなぁと。 自分は必要だとおもっても、周りにその問題意識があるかどうかは別なので。 好き勝手やっていいよって会社であれば別なんでしょうけど、そういう会社って結構珍しいんじゃないかなぁ。 もちろん相談出来る相手がいて、色々と相談や議論をし、協力者を見つけるのもいいし、そういう相手がいるんであればやるべきだとは思います。 そうすれば自分が思っていなかったような問題点なんかが出てきて考えの幅が広がるかもしれない。
地雷力 - steps to phantasien(2011-08-22)
地雷力のある人がいる. 簡単に直りそうなバグ, 一日で追加できそうな機能に手をつけたはずなのに, と当人はいう. バグがバグをよび, パッチがパッチをよび, 議論が議論をよんで, 目のまえに次々と刈るべき毛深いヤックが増えていく. そんな人がたまにいる. しかも話の流れでみつけてしまったバグをぜんぶ割り振られていたりする. 気の毒に...私が遠目にうかがうなかそのひとは毛を刈りだして, 刈るそばからバグや作業が次々と湧きだすけれど, しばらく経ってふと目をやるとあらかた片付いている. そして最後には歓声を耳にする: "おわった!" おめでとうと私は応じる. そのひとは次の仕事にとりかかかる, ああ, そのバグはやめておいた方が... けれどそのひとは動じない. いや一旦は動じるけれど, やれやれと仕事を再開する. そんな人には地雷力があるとおもう. 地雷体質, 羊毛フェチなど揶揄をこめるこ
つくりたかったものとかロケタッチのこととか - ogugblog
2010年07月21日 01:57 カテゴリDesign つくりたかったものとかロケタッチのこととか Posted by ogug No Trackbacks こんにちは、ogugです。 ロケタッチのデザイン全般を担当しました。 「デザイナーです」と自己紹介すると、 「ああ、じゃあ絵とか描くんですね」と言われる事がいまだにある。 たしかに絵は描くけど、それはデザインに必要だから描いているだけでデザイナーは絵描きとは違う。 最終的なアウトプットがビジュアルではあるけれども、それを通してどう社会と繋がりを作るか、コミュニケーションを作るか、ということを設計するのがデザイナーの仕事なんじゃないだろうか。 思えば、ずっと心のどこかにフラストレーションを感じていたんだとおもう。 2010年3月末。 突然呼ばれて言いわたされたのは、4月から新規プロジェクトをはじめるのでそれに入ってくださいと
マイクロソフトにおけるアジャイル開発はこんな風に進められている － Publickey
マイクロソフトの代表的なソフトウェアは、数千人を超える開発者、数十万のソースコードファイル、数千回ものビルドを繰り返して開発される大規模なものだといわれています。 マイクロソフトのエバンジェリスト長沢智治氏は、こうした大規模な開発プロジェクトがマイクロソフト社内でどのように行われているのか、プロジェクトチームの組成から実施計画、進捗管理、バグレポートなど、その裏側を紹介するセッションをいくつかのイベントで行っています。 そこで明かされている内容は、パッケージソフトの開発だけでなく、SIerでの開発プロジェクトでも参考になる部分が多いと思われ、いつかレポート記事として紹介したいと思っていました。 今回、以前に行われたセッションビデオの存在を長沢氏ご本人から教えていただいたので、開発プロセスに関する部分にフォーカスした記事としてまとめました。 記事での内容は主に、「Microsoft Tech
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
iPadでPHP開発ができるか試してみた
ついにiPadが日本でも発売になりました。早速入手できたので色々と触ってみました。 使ってみた印象としては「大きくなったiPhone」ですね。操作はiPhoneまんまなのですが、A4プロセッサのおかげか軽快に動作します。またソフトキーボードがかなり改良されていて特に日本語についてはPCのキーボードっぽく入力できます。 とはいえ、やはりMacBookほど多機能ではないので、立ち位置としては見た目どおりiPhone以上MacBook未満という印象です。 そんなiPadで購入前に気になっていたのが、「iPadで開発ができるか？」という点です。もしこれができるなら MacBookは事務所に置いてまま外出先や家ではiPadでこなせるのではと企んでいました。 そこでiPadでPHPが書けるか試してみました。 キーボード ソフトウェアキーボード 冒頭でも触れたとおり、iPad搭載のソフトウェアキーボード
幸せは金で買えない。しかし・・・ - ミックのブログ
ようやく春の嵐が過ぎ去り、無事 4/1 にシステムのカットオーバーを迎えることができました。まだしばらく集中監視期間が続くので、完全に安心はできませんが、とりあえずプロジェクトに尽力いただいた皆さん、お疲れ様でした。 今回、私は最終フェーズでのパフォーマンス・チューニングという、ある意味でプロジェクトが貯めてきた全てのツケを払う役回りで1ヶ月だけ参加したのですが、その体験で感じたことをまとめてみたいと思います。けっこう普遍性のある話だと思います。 まず、パフォーマンス・チューニングというのは、仕事としては面白いし、やり甲斐のあるものです。私は DB が専門（今回は Oracle だった）なので NW や OS についてはそれほど詳しくないのですが、それでも性能問題というのは、原因を突き詰めていく過程で非常にシステムの内部ロジックに詳しくなれる。というか、詳しくならないと解決できないので、嫌
DevOps - mizzy.org - Trac
DevOps: Why Silos Suck And How To Break Them というエントリをたまたま目にして、「DevOps」という見なれない言葉が出てきたので、気になって調べてみたところ、自分が何となくやっていたことや、今までもやもやと考えていたことに一定の方向性が与えらえた気がしたので、整理してみることにします。 DevOps とは？ 簡単に言ってしまうと「開発者と運用者の間の壁を取り払うためのベストクラクティス」と言えそうです。 開発者と運用者の間の壁？ Flickr の中の人による 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr という Velocity 2009 でのプレゼンスライドには「Devs versus Ops」という章があり、以下のような言葉が載っていました。 "It's not my mach
【ITpro Challenge!】「高い生産性を実現する『ハッカーのソフトウエアエンジニアリング』とは」---Google 鵜飼文敏氏：ITpro
「情報の共有は善。Googleも全員がほとんどのコードにアクセスできる。そして少人数のチームであること。Googleでも，一つのプロジェクト・チームは5～6人以下」---Google ソフトウエアエンジニアの鵜飼文敏氏は9月7日，イベントITpro Challenge!で「ハッカーのソフトウエアエンジニアリング」と題し講演，高い生産性を実現するハッカー流の開発手法を解説した。 ハッカーと呼ばれるプログラマは，通常の数倍とも数十倍とも言われる生産性と，高い品質を実現していると言われる。鵜飼氏はボランティア・ベースのLinuxディストリビューションDebian ProjectオフィシャルメンバーとしてIPA OSS貢献者賞を受賞したほか，The Free Software Initiative of Japan副理事長，2003年と2004年度の「未踏ソフトウエア創造事業」プロジェクトマネージ
高速にWeb開発をするために便利ないくつかのTIPS - KAYAC engineers' blog
outputz でいまだに1位になれたことがない村瀬です。 社内で開発をスムーズにするための tips 集を紹介したので、まとめておきます。 記事ではデモができないので便利さが伝わらない物も多いですが参考になれば幸いです。 screenとかzshとか便利だよ！と言う話は社内ではさんざんしているのでありません。 また、OSX 限定の内容もあります。 でははじめましょう。 keychain keychain と言っても OSX の KeyChain ではなく、コマンドラインのツールです。 これは ssh-agent をより便利にするためのラッパーです。これを使用すると ssh の秘密鍵のパスワードを一度入力するとあとはパスワードなしで ssh 接続できるようになります。 「同じこと二回も言わせんな！」といつも切れているような人は導入すると良いでしょう。 使い方は $ keychain ~/.s
プロジェクト Wassr 挑戦者たち 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
開発と運用の分離
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、システム統括部の駒田です。 昨今、内部統制やJ-SOXといった言葉を良く耳にしますが、 ヤフーもご他聞に漏れず、粛々と対応を進めて参りました。 今回は、その対応の一環として行った、 「開発と運用の分離」に関してのエントリーをさせていただきます。 例えばですが... 開発成果物であるソースコードをテスト終了後に改ざんし、 不正に利益を得る様なエンジニアが存在していた場合、 それはヤフーにとって、一般のお客様に対する裏切りであり、 信用の失墜となってしまいます。 このような事態を回避するため、 当開発部では開発者と運用者とを明確に分離し、 開発者はリリースモジュールに触れる事が出来ない。 運用者はソースコードに触れる事が出
プログラマが仕様を決めればいい - GoTheDistance
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
プログラマの誇りを減衰しないビジネスモデルを - GoTheDistance
アツいエントリなんで思わずTBうってみる。 この業界の問題、それはプログラムが、新人〜3年目の作業と位置づけられていることだ。 プログラマーの誇りを見せ付けろ - 山本大＠クロノスの日記 正確に言うと上級プログラマも初級プログラマも同じ値段で評価されるってことが弊害である、ってことだと思います。予めXXX万円で作ってねという予算が決まっていて、その予算をオーバーしないことだけが成果の基準にあることが問題だと考えます。このルールにおいては、極論ですがコード品質が高くても低くても大差が無くねっていう力学が働きます。 基本的にニッポンの受託開発のプロジェクトの場合は、大きく２つのプレイヤーがいます。 案件を立ち上げてお客さんへのコミット権限がある人・会社 立ち上げた案件をシステム化してデリバリする人・会社 ですが、今の流れでは工程が分断されちゃっているので、案件を立ち上げる人とシステム化してデリ
デブサミ2009 はてなの開発戦略 - 2nd life (移転しました)
先日のデブサミ2009で発表した、はてなの開発戦略 (すごい名前だ…) のプレゼン資料を公開します。前半は主に git の話で、後半ははてなブックマークリニューアルの、Perl 層の開発をどんな感じで行っていったか、という話です。 デブサミ2009 はてなの開発戦略View more presentations from hotchpotch. はてなの git では、中央のマスタレポジトリサーバがあって、そこから各自 clone / fetch して開発を行ってるので、完全に github のような分散のメリットを生かしているわけではありません。 しかし完全に分散を生かさずとも、git に移行したメリットは十分にあって、資料の中でもふれていますが、やはり一番便利なのが git のブランチ機能です。もうこれ無しでの開発は考えられないなぁ、ぐらいで、さくっとブランチ切って開発、ブランチの切り
Mojoの遅さはたいした問題じゃありません - Charsbar::Note
わかっている人にとってはごく当たり前の話ですが、あらためて明記しておきましょう。 最近ここで取り上げたMojoが、見ようによっては存外遅いというベンチマークが公開されました。また、MojoのライバルともいえるHTTP::Engineとの性能比較も紹介されています。 その結果については、とやかく申しますまい。CGIとしてのfairさはさておき、（mod_phpなどの）常駐モジュールと比べて（perlが、ではなく）CGIがあきらかに桁ひとつ遅いというのは、十年も前からわかっていたこと。いかに小手先のテクニックを駆使したところで、その事実が覆ることはこの先もないと言ってよいでしょう。 でも、MojoやHTTP::Engineにとって、大事なのは、そういうことではないはずですよね？ 従来のCGI.pm（あるいは、より速いCGI::Simple)を使った解は、いざユーザが増えてより速いFastCGI
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
quick hackの必要性 - blog.nekokak.org
とあるアプリの開発運用(トラブルシュート)
テクノロジー : 日経電子版
