エンジニアのこだわりと、継続的開発、チャレンジについて。
前職の頃からよく言うフレーズなのだが、受託をずっとやってきたエンジニアが面接に来た時に、「誤解を恐れずに言えば」という前置きとともにこういうことを言うことがある。 「サービスの開発は退屈ですよ？」 Facebookやtwitterや、若年層向けの携帯SNSや、それに従属するソーシャルアプリのような鬼のような成長をするサービスはよくわからないが、それ以外の従来からある、数多くのWebサービスにおいてエンジニアに求められるものは、如何に目の前の日々レガシーになっていくコードを安定的にメンテナンスしていくか？というサイクルになる。 安定成長するネットビジネスは「ストック型」である。お客様がそのサービスを使い始めて、使い終えるまでの期間を生涯価値として、今まで開発したコードで「サービス」を利用する。 その生涯価値がマルチスレッドのように重なることで、毎月安定的にユーザーが増えて行く仕組みである。と
TV放送はイノベーションのジレンマを迎えるか
2000年〜2003年末 動画1.0 IIJ、JStream、Sony、NEC、各ADSL業者、Real MediaからWindows Mediaへ・・・ブロードバンドの立ち上がりの期待感から動画配信、ストリーミング配信に参入する業者が相次いだ。 当初、家庭用ブロードバンドの期待があったが、なかなか導入されないADSL、FTTH（死語）の状況に動画配信各社は、ビジネス向け動画配信に梶を切る。つまり企業内配信だ。 2002年頃は、動画のIR配信、社内教育などに活路を見いだして、中には倒産する会社もあった。僕も前職で動画配信のCMSを開発していたので、Windows MediaやReal Media、Flash Communication Serverに関しては多少なりとも経験はある方だと思う。 この時代を、勝手ながら動画1.0と称するならば、日本の動画1.0の終演は、2003年末に NTT
Fireworks CS3ええわ〜
昨日、AdobeのCreative Suite 3（CS3）の発表イベントに行って、新しいCS3はどんな感じなのか見てきました。 Fireworks3は、Photoshopと競合しない方向をWebのプロトタイプ作成という情報設計の分野に活路を見いだたようです。 以前、僕が書いた、以下の課題を解決してくれるツールになっています。 遠い昔に書いた話ですが、以下の要件を新しいFireworksは解決してくれます。 こういうツールないですか？より １．画面枠内の画面要素だけを切り取ってHTMLに書き出してくれる機能 （画像切り出しのダミーHTMLでよい。） 要するに図面余白や、寸法線、説明コメントは出力されないで、画面のところだけ出力される。 ２．HTMLフォームは部品として配置でき、HTML上では通常のフォームタグに書き出されること。 ３．ハイパーリンクをホットスポットとして文字列オブジェクトま
F's Garage:Web2.0の定義に付け加えたい一つの要素[Web系]
これ前から思ってたことなんですが、良い文言が見つからなかったものが、kara_dさんとのmixi日記上でのやりとりで出てきたキーワードがぴったしだったので、以下に書きます。 そのキーワードとは、 「meddle / おせっかいであること」 僕はmixiを始めた時、他の数多くの会員サービスと同じく、登録したことすら忘れるようなサービスでした。僕の奥さんがmixi id３桁台、僕は5桁台で、しかも奥さんからの招待状は無視して、会社の人の招待状でようやく入会したという感じで、SNSに積極的な興味を持っていませんでした。 いつものようにorkutで知り合った数人の知り合いにマイミクというつながり申請をして、プロフィールを書いて、そこで終わる筈だったのです。 しかし、mixiからはメールでマイミクの日記の状況が、毎日送られてくるようになりました。 このメールを見ていたら、そこには友人の人たちの日記が
炎上マネジメント
「炎上」というキーワードの起源を知ってるわけじゃないので、そもそもの定義はよくわからんというか、僕が見たのは切込隊長のblogなのですが、まるで「萌え」に匹敵するが如く急速に普及したこのキーワードですが、それはそれとして炎上の安売りになりつつあるですか？ S i M P L E * S i M P L E 炎上後のすばらしい対応 批判ではなく、むしろ危機管理の好例としてのお話です。実際、最初にエントリーを見たときには、僕も目を疑ったのですが、荒れた後の対応のすばらしさに、いたく感銘を受けました。 田口さんの文章でそんな炎上なんて起きないだろうなぁと思って見てみたら、ホントに些細なことじゃないですか。 それは炎上とは言いませんし、荒れても無い。 好ましくない書き込みをミスと仮定したとして、その指摘への対応にしか過ぎません。 ただ、分析自体はトラブル慣れしていない人には良い例だと思うのと、先日
サービス開発発想と企業システム発想
スケーラビリティと機能性は不可分。発行するSQL文が増える可能性がある以上、明らかにトレードオフの関係となる。 キレイ事や正論やあるべき論ではなく、実際、これでいいんじゃないかと思うんだがどうだろう、と言う質問。 ■Webサービス開発： キーワード：むしろ冗長でも良い、まずは最適化発想禁止、スケーラビリティは運用しながら調整（計算できないし、サービスの発展にあわせて作るかえるべき） 目的：極論だけど日単位で機能追加が可能であることを最重視 ■エンタープライズなサービス開発： キーワード：冗長は害悪、常に100%の最適化発想、スケーラビリティは社員の数と伸びで計算可能 目的：スケーラビリティは基本的に予測可能として考える。安定性と機能完成度重視なので、あらゆることを固める必要あり。アジャイル発想で、最近はそうでもないかもしれないけど、Webサービスほど発展が不明確ではないと思う。(M&Aして
mixi心配です。
ミクシィ、画像に認可制御なしの欠陥を改修できず、ヘルプで弁解 ----------------------------------- 2005年5月にIPAの脆弱性情報届出窓口に届け出られたmixiの欠陥の件が、1年半たってようやく決着したという。この欠陥は、mixi内でアップロードされた画像が、mixiにログインしていなくても画像のURLを指定すれば誰にでも閲覧できてしまうというもの。 ～中略～ IPAはこれを脆弱性として受け付け、取り扱いを開始したものの、11か月後の2006年4月になって、ミクシィ側からギブアップの連絡があったという。その内容は、「システムの改修にて試みましたが、いくつかのプラットフォームにおいてログインができなくなった」「全ユーザーに対応させることは非常に難しい」というもので、改修しないということで取り扱い終了となったそうだ。 -------------------
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
