第5回 ファイルがなくなる？ データの配置や保存の仕組みがどうなるか
第5回 ファイルがなくなる？ データの配置や保存の仕組みがどうなるか：クラウド社会とデータ永久保存時代の歩き方（1/2 ページ） これまではクラウド社会で大きく変わりつつあるデジタルデータの扱い方、その注意点について話してきました。今回からはIT側から見た理想的なデータ保存形式について解説していきます。 この連載は…… ストレージ技術は、クラウド／IoT時代を迎えて大きく役割を変えつつあります。 様々な「非構造化データ」が無秩序に保存されてゆき、さらにかなり長期に保存する必要が出てきました。実は最新のデータセンターにおいてもデジタルデータの長期保存は大きな課題で、様々な新しい技術、新しい管理方法が考えられてきています。これはごく身近な個人のデータもそうです。スマホで撮った写真や動画、家族とのやりとりや記録、日記的メモやSNSのログなど、これらはいわばライフログ（人生の記録）になりつつある自
5分で絶対に分かるAPI設計の考え方とポイント
API設計を学ぶべき背景と前提知識、外部APIと内部API、エンドポイント、レスポンスデータの設計やHTTPリクエストを送る際のポイントについて解説する。おまけでAPIドキュメント作成ツール4選も。 【0分】API設計を学ぶべき背景 APIの公開が増えている 最近、自社で保有するデータや、システム、アプリケーション、Webサービスの機能を「API（Application Programming Interface）」として公開する企業が、増えてきています。これに伴い、「API経済圏（APIエコノミー）」という新たなビジネスモデルが確立されつつあります（参考：5分で絶対に分かるAPIマネジメント、API経済圏）。 「ProgrammableWeb」というAPIに関するニュースサイトや、さまざまな企業が提供するAPIのリンクがまとまったサイトもあり、APIの普及はものすごいスピードで進んでいる
初めての新規サービス開発を通して学んでいること - クックパッド開発者ブログ
こんにちは。投稿推進部の清水(@pachirel)です。 2009年にクックパッドに入社してから、インフラ周り、クックパッドの人事周り（採用・評価）や広告周りのシステム開発を担当していました。 2014年4月頃から、2〜3名の小さなチームで新規サービスのプロトタイピングをいくつか行っています。 企画の詳細は省きますが、私がこの10ヶ月ほどで学んだことをまとめました。アジャイル開発やLean startupの考えに共感しているので、そこから得た内容に私の体験を付け加えたものになっています。 今回はプログラミングに関する技術的な内容は含まれていません。 なぜ作るか スタートアップが失敗する原因で一番多いのは「人が必要としていないものを作ってしまった」というものです。 The Top 20 Reasons Startups Fail 社内の新規サービス開発でも同じ傾向があるのではないでしょうか。
砂漠の国の王子はいかにして船出をするか：プログラマで、生きている：エンジニアライフ
わたしは開発現場で黙々とコードを書いてることがほとんどで、あまりお客さまと顔を合わせることがないんですが、要件定義のために客先にでかけた経験も少しはあります。 で、お客さまから処理の流れを聞きながら「あっ、砂漠の国の王子様が船出してる」って思うことが結構あります。 「砂漠の国の王子様が船出する」ってなんのこっちゃ、とお思いでしょうが、わたしが高校生のときに読んだ氷室冴子先生の『少女小説家は死なない！』っていうコメディ小説がありまして、売れない少女小説家が書いた小説に「そして、フラーゼは海に船出した」という一文があって、それを読んだ主人公の女の子が、十行前に「砂漠に囲まれた陸の孤島のような国」と描写されていた国にいた王子様がどうやって海に船出するんだ、とツッコミを入れる、というエピソードがあったんですよ。 これは、売れない小説家の書く小説がなんで売れないのか、という理由を示しているくだりなん
失敗したプロジェクトから学んだ3つの教訓
プロジェクトが失敗しても、それはまったくの時間の無駄に終わるわけではない。そこで得た経験は、次のプロジェクトを成功に導くうえでの「べからず集」を構成する貴重な教訓をもたらしてくれるはずだ。 あなたの履歴書には成功したプロジェクトが書き連ねられていると思うが、経験豊富なプロジェクトマネージャーであれば、失敗したプロジェクトや、問題を抱えたプロジェクトにかかわった経験も、少なくとも1度はあるはずだ。「2009 Chaos Report」によると、66％のプロジェクトは業務目標の達成に失敗したか、壁にぶち当たっていたことが示されている。 プロジェクト目標がスコープの削減による影響を受けたり、「戦略的方針転換」によってリリースが中止されたり、本当の業務価値を提供できないただの多大な投資に終わったとしても、そういった失敗プロジェクトを成功プロジェクトとして語る場合もある。あなたにも心当たりがあるので
ソフトウェア開発に「ちょっと変えるだけ」などない | gihyo.jp
「SMSを使う場面があるからレビューの長さを140文字以内に制限したいんだ。ちょっと変えるだけだよね？」、ソフトウェア開発の現場でこんな要望を受けることはよくあります。 カスタマーサポート向けのSaaS（Software as a Service）を提供するIntercomのブログにて、「高品質のソフトウェアを提供しよう思うのなら、ちょっと変えるだけなんてことはありえない」という主張とともに機能の全体像をしっかり検討し、その価値と見積りのバランスを熟考することの重要性が説かれていました。 冒頭のような場合、経験の浅いプログラマは熟慮することなくif文を追加して数分で対応してしまうかもしれませんが、ソフトウェアやサービスの質を高めることを目指すのであれば、考えることは山ほどあります。 レビューが140文字を超えたらどうなる？ エラーはどこにどんな文言で表示する？ 文字数制限の理由をユー
「監修役」って大事だよなぁ。：What a wonderful world：エンジニアライフ
先日放送されていた「ほこ×たて」のセキュリティ対決。見ていた人、結構多かったのではないでしょうか。かく言う僕も、期待しながら見ていた人の一人であります。 しかし、「なんなんだこの展開……。セキュリティ破られてるじゃん。」と、放送を見ていて残念に思った一人です。 その後、Twitterや、防御側のネットエージェントさんのブログを見て「攻守共にちゃんとやっていたんだな。むしろ問題は編集の方なのかもしれないな。」と、多くのITエンジニアと同じように残念に思った一人です。 「あれは編集が悪いんだ！」と言うのは、簡単なことでしょう。 しかし、システムの作り手としては、僕らも同じような過ちを犯すケースがあることを思うと、なんだか単純に批判をできないのではないかと思うのです。 ■あの企画に「監修役」はいたのだろうか？ 「ほこ×たて」の放送内容を一人思案して思ったことは、「この企画にセキュリティの知識を持
Google&Facebookに学ぶ、新機能の実装プロセス : けんすう日記
新機能の作り方 サービスを作っていて、新しい機能などをつけようとする時に、煩雑なプロセスなどがある会社は多いと思います。 これは前職のリクルートという、大きな会社で働いてた時も感じたのですが、新しくておもしろい機能をつけようとすると、いろいろと制限があるのですね。 たとえば、「なぜその機能が流行るか」のロジックを聞かれたりします。これはリソースやお金を投資する分、説明責任がある！ということですね。冗談みたいな話ですが、資料を作ったりして、この機能がどういう効果があるかとかを説明してたりしたのです。だいたいの場合、弾かれてたりしました。 また、その機能を実装したあとの影響のために、部署との調整が必要だったりします。リクルートのとあるサービスに、口コミ機能をつけようとしたら、あらゆる部署に説明しにいかないといけなかったりしました。 どちらも間違っているわけではなく、会社としては一見必要なプロセ
ユーザーレビューとどう向き合う？ クックパッドiPhoneアプリに酷評殺到の背景 (1/3) - ITmedia ニュース
2月初め、「クックパッド」のiPhoneアプリが新しくなった。従来は、検索機能中心のシンプルなアプリだったが、新アプリはレシピ提案機能などを充実させた多機能でモダンデザイン。Web業界では好評で、絶賛するニュースメディアやブログも多かった。 だが、ユーザーがApp Storeに投稿したレビューは辛らつだった。「前の方が良かった」「使いづらい」など酷評が集中。「☆」1つの評価が大量に投稿され、“炎上”状態になっていた。 その後のバージョンアップなどで徐々に評価は戻っており、最新バージョンでは「☆4」や「☆5」の評価も増えてきた。だが、最初のバージョンアップ時に多くのユーザーが低評価を投稿したため、全評価の合計を見ると、3月末現在でも、「☆1」が大多数のままだ。 思わぬ反応に、クックパッドの橋本健太CTOは「メジャーバージョンアップで完成ではない。これからがスタート。改善を繰り返していきたい」
優れた仕様を決定するために必要なこと - GoTheDistance
たまにはブログ更新したいから、ついさっき流れてきたエントリに食いついちゃうよー。 ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change! 工程の分断はあり得ません ソフトウエアの設計に実装経験が要るか要らないかというのはそもそも議論にならない。「ソフトウエアの設計＝仕様の設計+コードの設計」なんだから、例えればコインの表と裏。それらは引き離すことは出来ないのに引き離して分業しようとするからよろしくないことが起きてしまうというのが、上記記事の主題かと思います。簡単に言えば。 僕もこの点については「工程の分断」という言葉で何度も書いています。コインの表と裏であるべきものを分断してしまうと、互いのフィードバックを得る術を無くしてしまいます。そうなったら良いことは無い。ここは誰でも納得がいく所でしょう。 仕様を設計するチャンスって超少ないんじゃない？
名は体を表す：101回死んだエンジニア：エンジニアライフ
いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 ■誰だ、スクリプトに"Death-Note.sh"ってつけたのは！ スクリプトを書く時、気を使うのは分かり易い名前を付けることだ。これは基本だと思う。できれば名前を見るだけで、どういう動きをするか理解できるものが理想だ。 記載したユーザセッションを記した通りの時刻にKillするスクリプト、その名は"Death-Note.sh"。そのスクリプトに記されたユーザは、指定の時刻でプロセスをKillされて、強制的にログアウトされる。非常にうまい名前の付け方だと思った。ちなみにそのサーバの管理者アカウントは"Yagami"だった。 ■サーバの名前エトセトラ たまに見かけるのは、サーバのホストネームに歴史上の人物の名前を付ける人たちだ。歴史を知っていれば、的確にサーバの関係が分
「バックエンドの経験はなかった」Instagram創業者は、どうやってシステムをスケールさせてきたか
昨日のPinterestの記事「Pinterestの急成長を支えてきたアーキテクチャとは？ Pythonで開発しAmazonクラウドで運用」に続いて、やはり写真を中心としたサービスで急成長してきたInstagramのスケーラビリティについて、まとめてみました。 InstagramもPinterestと同様に、基本はAmazonクラウド上でPythonとフレームワークのDjangoを使ったシステムを構築しています。興味深いのは、創業者の二人ともバックエンドの経験がないなかで試行錯誤をしてシステムをスケールさせてきた点です。 Instagramは先月、Facebookに買収されると発表されています。この先、Instagramのシステムはどう変わっていくのでしょうか。 Instagramのシステム構成 約半年前、昨年12月にInstagramのブログに投稿された記事「What Powers In
反復型モデルは速さとは真逆のプラクティスである。 - レベルエンター山本大のブログ
反復型vsウォーターフォールを新人教育で教えるときに、 あるゲームで体感してもらったんだが、現実にあるあると言える面白い結果になった。 結論から言うと、反復開発は速くはないということがわかった。 題材は、伝言ゲームである。 ■基本ルール ・５−６人で１チームを作り、最後尾の人がマジックと紙を持つ。 ・講師が先頭の人だけに絵を見せる。絵は以下のようなものだ。 ・先頭の人は、自分が伝言している間だけは何度でも講師の絵を見に来ることができる。 ・言葉だけを使った伝言ゲームによって順番に1人1人回して行く。 ・最後の人が紙に書き出しす。 ・制限時間は15分 ■ウォーターフォールバージョン 基本ルールに加えて以下をルールとする。 ・伝言のフローは1回だけ。1回で伝えきること。 ■反復型バージョン 基本ルールに加えて以下をルールとする。 ・伝言のフローは何回行っても構わない。 ・ただし、先頭の人を起点
『初めからやっておけばよかったとあとで思うシステム構築に関する10のこと』
システムを作ろうとした時に、まずはサービスとしての立ち上げを優先するあまり、それ以外の事は時間ができたらと後回しにする事はよくあります。 しかし、規模が大きくなってサービスが軌道に乗ってくると色々とあの時やっておけばよかったとか、もう一度作り直したいという状況に追い込まれるのはよくある事です。 そんな事にならないように、初めからある程度考慮しておいたほうが良い事を書いてみたいと思います。 1. フレームワークを利用する 一からシステムを組む際は、何らかの著名なフレームワークを最初から導入した方が効率的に進められます。 全てを手作りしたい衝動やフレームワークを導入する際の教育などのコストだけを見ていると、あとあと後悔する羽目になったりします。 それは規模が大きくなるにつれ、保守性がやたらと落ちたり、独自の構造から他のエンジニアがそれを使うのに習得するコストがフレームワークを使う場合のそれを上
「夢」のシステムが実現しないわけ - novtan別館
身につまされるところがいくつかあった。 まず顧客には「本当に必要なもの」がある。金出してやるプロジェクトなんだから当然のことだ。ところが、そこにコンサルが入って次期システムのあるべき姿という「素晴しい夢」を説く。「夢」の話は楽しいし前向きだから、みんなそれに夢中になる。いつの間にか、「本当に必要なもの」は実現されて当然ということで、話から消えてしまい、「夢」の方ばかりになる。 もちろん冷静な人達は、そういった「夢」はあくまでも「夢」だと思う。それでも「現場」の多くはその「夢」が忘れられない。「夢」をベースとした要求が起きる。 プロジェクトが遅滞してヤバくなって来ると、「夢」を見ていた人達も冷静になって来る。それでもやっぱり「夢」は忘れられない。また、「夢」で浪費してしまった時間は取り返せない。 僕の知ってる「特許庁」の話 | おごちゃんの雑文 僕が今やっているシステム開発はこの「夢」に近い
大きなリリースの際にチェックすべき34のこと
以前に作っておいた大きめなリリースをする際にチェックしておくべきことのリストが役に立ちそうなので公開しておきます。 僕の場合は普段はワンクリックデプロイが多いんだけど、かなり大掛かりな変更をするケースが年に数回あったりするので、その際にこういうリストを使ってリリース計画をチェックしています。(もちろん大掛かりなリリースでもワンクリックでできるのに越したことはないし、そもそもビッグバンリリースにならないようにできるだけ小さい単位で頻繁にリリースできるに越したこともない) 体制当日の体制は決まっているか夜間立会いの場合、日中の営業時間の対応体制は決まっているか翌営業日以降の体制は決まっているか連絡担当と作業担当は分離されているか作業担当はペア作業になっているか。作業者と確認者を定めているか顧客の連絡先を抑えているか顧客の連絡順番を抑えているか、お客様の当日の所在を抑えているか顧客への連絡タイミ
［スクープ］特許庁、難航していた基幹系刷新を中止へ - ニュース：ITpro
特許庁が5年前から進めてきた基幹系システムの刷新プロジェクトを中止する方針を固めたことが、日経コンピュータの取材で分かった。当初は2011年1月の稼働を予定していたが、業務分析の遅れなどから要件定義と設計が難航。稼働を3年遅らせたが、立て直すことができなかった。 政府が策定したレガシーシステムの刷新指針に基づき、特許庁は2004年10月に「業務・システム最適化計画」を策定した。この刷新指針は、特定のITベンダーとシステム保守などを長期契約することによるITコストの高止まりを解消する目的で策定されたものだった。同庁はさらに、入札に分割調達の仕組みを採用して競争原理を働かせることを目指した。 要となるシステム設計とシステム基盤の構築については、東芝ソリューションが入札予定価格の6割以下の99億2500万円で落札した。ところがプロジェクトが始まると、現行の業務やシステムを理解した職員と技術者が足
とあるサービスの高負荷チューニング日記
とあるサイトのとあるサービス機能について相談を受けた。高負荷が原因で 95% の確率でリクエストを無処理で NULL を返す仕様になっているとかなんとか。 正直 95% が結果が NULL なサービスは存在価値そのものから疑う必要があるわけだが、必要な機能らしい。 と言うわけでサーバへログインしてみた。 高負荷サイトのチューニングについて以前記述した手順でサイトの状態を把握していきます。 1. top をみて上位に張り付いているプロセスを確認しつつ CPU or I/O のどちらが原因か判別 top で apache の幾つかのプロセスが CPU を食いつぶしていることが確認できます。メモリ不足というわけではなさそうです。 top - 19:11:41 up 294 days, 9:51, 4 users, load average: 1.66, 1.18, 1.05 Tasks: 416
『サービス構築の実行コストは構築側より提案側のほうが上回ってるんじゃないかって話』
一昔前ならシステム構築の手間って膨大な時間と労力をつぎ込んで作るものってイメージがありました。 例えちょっとした機能変更でさえも、開発側の担当者は「それは多くの機能に影響を与えるからかなり時間がかかる」とか何かと理由を付けて拒む姿勢もよく見かけました。 まぁ、これは担当者が面倒くさがっていたり、品質や納期の観点からこの時期にその要求を受け入れるリスクを嫌っていってたのかもしれません。 しかし、今ではその労力というのはだいぶ軽減されてきています。 もちろん要件の規模によりますけど、その一部の機能を構築するのにも昔に比べたらはるかに楽になっているでしょう。 技術の標準化や多様なライブラリ、ネット上に発信される多くのノウハウ、IDEなど開発環境の進化などその理由は多々ありますが、そういった開発コストの低下の中で思うのは、システムを構築する手間っていうのはもはや構築をする側より仕様を決める側の方が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://jp.techcrunch.com/2012/04/20/jp20120420how_do_you_reduce_the_cost_of_development/
