Ameroadが生まれてから売却するまでの五日間まとめ：村上福之の「ネットとケータイと俺様」：オルタナティブ・ブログ
GumroadのパクリサイトAmeroadを作って、ヤフオクに出したら、株式会社Razestの木村社長に150万円で落札していただきました。ありがとうございました。 今回、ヤフオクで売るというスキームは非常に面白いと思いました。このスキームは話題性のあるサービスでないと、傾向的に値段がつきにくい上に、ヤフオク商品で稟議決済ができる会社もそんなにあるはず無いはずなので、あまりオススメできません。しかし、2/14にサイトができて、2/19にバイアウトするというのは、前例があまりないモデルだと思います。超短期小額バイアウトモデルとして面白かったです。「値段安すぎ」というツィートも多いですが、僕個人としては、試みとして、やってよかったと思います。経緯を書きます。 つづきは、本でも買って下さい。すいません。 ソーシャルもうええねん
ヤフオク!
以下の内容をご確認ください。 1）ご指定のオークションIDは正しいですか。 オークションIDについては、ヤフオク!用語集をご覧ください。 2）商品ページが削除されている可能性があります。 ページ削除の詳細については、こちらをご確認ください。
ホッテントリを書いた時「自己満度」をブーストさせる方法 - ゆーすけべー日記
数ヶ月前から、アクセス解析サービス Google Analyticsにベータ版として「リアルタイム」機能がつきました。 このリアルタイム。その名の通り今まさに起こっていることが丸わかりですっごいんです。 なんというか「tail -f access.log」しているような感覚です。 しかし、あまりにも瞬間的な計測なので、 リアルタイムデータをどう活かせばいいのか結構悩みどころ。 一つ言えるのは、リアルタイム解析を見るタイミングによっては Webクリエータや運用者にとって、最高の自己満ブーストツール になるってことです。 特に何かを「リリースした瞬間」が有効になります。つまりBlog記事やサービスが公開された時です。 さらにはそのリリースしたものが、はてなブックマークでホットエントリー入りなんてした日には... より自己満足に浸れます。では、理由を見て行きましょう。 1. 今の訪問者を分析でき
僕と君とSIerの生きる道 - ひがやすを技術ブログ
SIerに対するバッシングは、高まる一方です。 私もSI業界からはさっさと抜けだしたほうがいいのエントリでSIerには未来がないからサービスを作る側に回ったほうが良いと書きました。 確かに私自身は、サービスを作る側に回った(まだISIDにいるけど、ベンチャーで働いているようなものです)のですが、身を持って面白いサービスを作る難しさも経験しました。 面白いサービスを作るのはほんとうに難しい。その後、マネタイズにも成功するのはさらに難しい。サービスを作る側に回って成功するのはほんの人握りの人なんです。 これは、自分でやってみての正直な感想。やらなきゃわからなかったことなので、自分のしたことに対する後悔はありませんが、日々ものすごいプレッシャーです。 チャレンジし続けないと落ちぶれてしまうのエントリの通り、私は現状維持を嫌い、常に新しいことにチャレンジする前向きな性格ですが、それでもこのプレッシ
英国政府、新ポータルGov.ukをクラウド、アジャイル、Rubyで開発。ソースはGithubで公開
クラウド上でRubyを使って開発し、成果物はオープンソースとして公開。開発プロセスにはアジャイル開発を採用し、毎日スタンドアップミーティングを実施。まるでベンチャー企業が新サービスを開発するようなスタイルを採用しているのが、英国政府のポータル「Gov.uk」の開発チーム。 Welcome to GOV.UK Beta (Test) - simpler, clearer, faster access to UK government services and information Gov.ukは、英国政府の情報とサービスを利用するためのポータルサイトとして開発が進んでおり、現在β版が公開されています。 グーグルのプロジェクトのようにGov.ukは作られている Gov.ukがどのように開発されているのか、ブログGovernment Digital Serviceにポストされたエントリ「Int
システム開発に欠かせない見積もり前提条件について | DevelopersIO
こんにちは！おおはしりきたけです！今日はシステム開発に欠かせない見積もり前提条件について書きたいと思います。 ■はじめに 弊社では、受託開発を多くやっております。受託開発は、最初のスタートが重要です。私見ですが最初のスタートで成功確率の80%は決まっているといっても過言ではないと思っております。そのくらいスタートというのは大切だと思っております。エンジニアの方々の中には、営業さんが「あとはヨロシクッ！」と言って金額しか決まっていないプロジェクトを経験し苦い思いをした方も多いのではないでしょうか。弊社では、そのような事が起こらないよう営業さんとは密な連携を取りプロジェクトが成功可能かという判断をし、成功可能なプロジェクトに対し開始するということを行っています。その作業の中でも特に重要なのは、見積もりの前提条件です。 ■なぜ前提条件が必要か 見積もりを出すときの流れは大まかにいうと以下のように
スマホサイト案件の見積もりについて
スマホサイト案件の見積もりについて 「Android案件の見積り」や「スマホ案件の見積もりについて」を受けて、アプリではなくHTML+CSSでつくるスマホサイト制作の見積もりではまりやすいポイントをまとめています。 HTML+CSS構築ではPCの0.７倍くらいの単価 スマホサイトはPCより小さいのでHTML+CSSの構築コストも安くみます。ただ、CSS3で作ったほうが良いところで画象の切り出しより手間がかかることもあります。ならすとページ単価はPCの0.７倍くらいの感じじゃないでしょうか？ 検証コストは増大 対応端末が多く検証コストはPCと比較して増大します。iPhone3G、iPhone3GS、iPhone4、iPhone4Sの中から2端末ぐらい(iOS4.x系とiOS5系)。Android2.2、Android2.3から売れてる端末で2端末ぐらい検証するのがよいでしょう。(場合によって
Android案件の見積り | DevelopersIO
Android案件を何件か担当して見積り前に確認しておいた方がいいと思うことや決めておくこと、 事前に説明しておくべきことがいくつかあったのでまとめます。 ①ハードウェアの選定 ・どの端末をサポートしますか？ 動作確認を行う端末を決めてもらいます。 複数の端末をサポートする場合、テストも複数の端末で行うため工数もそれに応じて増やす必要があります。 ・サポートするAndroidのバージョンは？ 端末を決めた時点でほぼ決まってしまいますが"Android 2.2以上"のようにサポートする最小のバージョンを決めます。 特にお客様にご要望がない場合はアプリのリリース時期と端末、OSのシェアなどを考慮して提案しています。 ・タブレットでの使用は想定していますか？ これはスマートフォン用に開発している案件で後からタブレットでも使用したい、 というご要望を受けることがあるためです。 ・マルチデバイス対応
開発に必要な力は二つしかない - 神様なんて信じない僕らのために
最近開発をしてきて開発者に重要だと思うのは、 ・問題を発見する力 ・問題を解決する力 の二つだと思っている。 実際にコードが綺麗とか、技術が卓越している、というのは個人の手腕であり、 持ちうるスキルではあるのだけれど、 それは「問題を解決する際に使われる力」だ。 そして、これには「コミュニケーション力」や「交渉力」、 「論理的思考」や、「選択肢の中から成否を見据える力」も含まれている。 そして、これを行うためには「問題を発見する力」が欠かせない。 「何が問題なのか？」を考えずにこれらの力をふるうことはできない。 いかな高い技術力があっても、それを使う場所や使うべき場面が解らなければ何の意味もない。 要するに重要なのは「問題を発見し、解決する力」だ。 これが出来れば職場も個人の問題も、何でも解決できる。 そして、組織が強いのは沢山の眼があること、沢山の思考があること。 要するに重要な力は２つ
メルマガ「ゆーすけべーラジオ」明日創刊 - ゆーすけべー日記
まぐまぐ！での有料メルマガ「ゆーすけべーラジオ」を明日創刊させます。 ゆーすけべーラジオ 既に配信の準備は整ったので、あとは時間が来るのを待つのみです。ちょっとドキドキ。 そもそもメルマガをはじめようとしたキッカケはまぐまぐ！の中の人からメールで声をかけられたからです。ちょうど、今年からiPhoneアプリを中心とした受託以外の事業に自分のビジネスを変革していこうと考えていた矢先のことでした。弊社のHPにも明記してある通り、情報発信というのも事業としてやりたいことの一つ。このBlogもその一環ですが、メルマガというビジネスもまぐまぐ！の中の人の話を聞くにあたって有りだなと思った次第です。そこで、試してみなきゃーわからないってもんでやってみようかと。 あ、値段設定の「月額840円」というのもまぐまぐ！の中の人のアドバイスで、ちょっと高めかなと思いますが、最初はこのくらいの方がいいと。確かに他の
大きなリリースの際にチェックすべき34のこと
以前に作っておいた大きめなリリースをする際にチェックしておくべきことのリストが役に立ちそうなので公開しておきます。 僕の場合は普段はワンクリックデプロイが多いんだけど、かなり大掛かりな変更をするケースが年に数回あったりするので、その際にこういうリストを使ってリリース計画をチェックしています。(もちろん大掛かりなリリースでもワンクリックでできるのに越したことはないし、そもそもビッグバンリリースにならないようにできるだけ小さい単位で頻繁にリリースできるに越したこともない) 体制当日の体制は決まっているか夜間立会いの場合、日中の営業時間の対応体制は決まっているか翌営業日以降の体制は決まっているか連絡担当と作業担当は分離されているか作業担当はペア作業になっているか。作業者と確認者を定めているか顧客の連絡先を抑えているか顧客の連絡順番を抑えているか、お客様の当日の所在を抑えているか顧客への連絡タイミ
auのターゲット広告がアンドロイドというプラットフォームにダメージを与える理由 - FutureInsight.info
[追記] 本件のKDDI側の対応が記載されていますので、是非ご一読ください。 auが通知バーでの宣伝自粛、スマホ時代の情報配信の形 - ケータイ Watch auがau one marketというau独自のアプリマーケットに絡めて、ターゲット広告を開始しました。 KDDI、Android の通知バーまで広告に活用開始 - Engadget 日本版 しかも、この広告の解約方法がなんと電話するのみという仕様です。 au one - ターゲティング情報配信の停止について メールアドレスと2年契約によりユーザーが自由に選ぶことが実質出来ないキャリアがターゲット広告を行うことの是非についての議論やセキュリティ、プライバシーに関する議論もあると思いますが、今回はその話を置いといて、この件を一つのケーススタディとしてアンドロイドというプラットフォームの特性を考えてみようと思います。 Androidの通知
ソフトウェアをつくるための３つの役割〜アジャイルに外部設計は必要か | Social Change!
ソフトウェア開発にはどんな役割が必要だろうか。よくあるウォーターフォールの世界では「要件定義」「基本設計（外部設計）」「詳細設計（内部設計）」「実装」などといった名前で工程を分けることで役割を分けています。アジャイル開発のスクラムでは「プロダクトオーナー」「スクラムマスター」「チーム」といった名前で分けています。役割の名前が違えば、ソフトウェアのつくり方が違うかというと、そうではなくて「やるべきこと」は同じだと考えています。 ソフトウェアをつくる上で「やるべきこと」は何か ソフトウェアをつくる上で「やるべきこと」は何かをざっくりと分けてみます。 最初に、どんな困った問題を解決したいか、どんなことを便利にしたいか、といった根源的なことが思いつきます。次に、どうやって解決するか、何をつくれば良いか、というアプローチを考えます。そして、それを実際に動くようにプログラミングしていく訳です。 一人で
EU：「忘れ去られる権利（right to be forgotten）を明示した個人データ保護指令の改正案を提示 - Cyberlaw
下記の記事が出ている。 Europe proposes data protection reforms USA Today (AP): January 26, 2012 http://www.usatoday.com/tech/news/story/2012-01-25/EU-internet-privacy/52791466/1 批判もある。 Critics: EU's proposed data protection rules could hinder Internet Computer World: January 25, 2012 http://www.computerworld.com/s/article/9223717/Critics_EU_s_proposed_data_protection_rules_could_hinder_Internet Assessing the
ソフトウェア技術者軽視のシステム開発を続けるのはもう限界かもしれない - 達人プログラマーを目指して
つい先日、富士通がグループで抱える3万人ものSEを再教育して、職務転換を行う計画であるというニュースを知りました。 富士通の3万人SE職務転換大作戦は成功するのか？ - GoTheDistance 一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むＳＥは仕事がなくなり、余剰人員問題が顕在化するからだ。 クラウドの普及により、オーダーメイドでシステムをゼロから構築する必要がなくなり、そもそも顧客からの要件をまとめてシステムを設計するSEの仕事が不要になったり、基盤を構築、運用するエンジニアが不要になるということは、最近になってよく言われることであり、特に新しいことではありません。もちろん、クラウドの普及によって、これらの伝統的なSEの仕事が少なくなり、人員が余るという議論は間違いではないと思います。 ただし、一方でより本質的
各国プログラマーのステレオタイプ的分類 - himaginary’s diary
タイラー・コーエンが、なぜソフトウエアでは一物一価の法則が成り立たず、米国や日本企業は自国の高いソフトウエア技術者を使い続けるのか――香港やシンガポールや中国ではもっと安価で雇えるにも関わらず――という一読者の疑問をブログエントリ化した。それに対し250を超えるコメントが付いたが、予想される通り、ソフトウエア開発においては単なるコーディングだけではなく、発注元と発注先とのコミュニケーションが重要なウェイトを占めるのだ、という指摘が相次いだ。その中で、各国のプログラマをステレオタイプ的に寸評したコメントが少し面白かったので、以下に訳してみる： Well, while we are being rude let me speak… It’s not the individuals of course, but the culture. And culture is why Americans
小野和俊のブログ:罪悪感駆動開発(zaiakukan-driven development; ZDD)
みなさんは罪悪感駆動開発(zaiakukan-driven development; ZDD)という言葉をご存知だろうか。私はつい先ほどまでこの概念を知らなかった。なぜなら先ほど自分で思いついたばかりだからだ。 仕事をしていく中で、やるべきことが山積みなのについネットサーフィンをしてしまい、「うわ、今日仕事全然進んでない、やばい」という罪悪感から、その後の仕事が妙に捗る、という経験をしたことがある人は少なくないだろう。 罪悪感駆動開発は、こうした危機感や罪悪感といった人間が本来持っている感情を引き出すことで、より高い仕事の成果を上げていくことを志向する。 罪悪感を感じるポイントは人によって個人差があるが、一般に仕事中に罪悪感が高まりやすい充填行為として、次のようなプラクティスが広く認知されている。 (a) 昼寝 (b) ネットサーフィン (c) ゲーム (d) タイピングソフトでランキング
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Forkwell - アウトプット志向エンジニアを応援するソーシャルポートフォリオサービス
sekailog.com
TechCrunch | Startup and Technology News
