Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

タグ

developmentに関するmathatelleのブックマーク (21)

  • ビルドツールまとめ。Gruntとかgulpとか (フロント寄り) - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    ビルドツールまとめ。Gruntとかgulpとか (フロント寄り) - Qiita
  • アプリ開発を効率化する 方法あれこれ

    Convert to study guideBETATransform any presentation into a summarized study guide, highlighting the most important points and key insights. Convert

    アプリ開発を効率化する 方法あれこれ
  • Amazon流の開発術では、まずプレスリリースを作る | fladdict

    Amazonでは製品開発をするとき、まず最初にプレスリリースを書くらしい。これは”Working-Backwards“と言うデザイン手法。面白げなので色々と調べてみた。 Working-Backwards法の商品開発では、お客様の視点をスタート地点にするため、開発前にプレスリリースを作成する。プレス内容は、既存プロダクトの問題点と、それを新製品がどう解決するかが中心になる。 プレスがユーザーに響かなかった時点でプロジェクトはボツ。そもそもその商品は作らない。これにより見当違いな商品を作るリスクを、一番最初の段階で低コストに回避できる。 このWorking-Backwards法で書くプレス内容は主に以下のとおり。 見出し 顧客が商品を理解できるタイトル 副題 ターゲット層と、彼らのメリットを1行で。 概要 商品の特徴と利点をまとめる。この段落で全てを理解できるように。 課題 このプロダクトが

  • 自分なりの iPhone アプリ開発手法とかこだわりとか書いてみた

    Twitter で vの人こと @voluntas さんに 無 茶 振 り されたので、自分なりのポリシーとかこだわりとか開発手法とかをまとめてみることにしました。今仕事iPhone アプリの開発を主にやっているので、 iPhone アプリに関する内容が多いですが、それ以外の開発でも使えると思います。 あまり技術的な内容やツールに関する内容はありません。それらは別エントリーにまとめようと思います。 ■大前提: 自分を知る まず何はなくともこっからです。なんだか開発とか全然関係ないじゃないか、怪しい自己啓発じゃねえかと思われるかもしれませんが、敵を知り己をを知れば百戦危うからずと昔のエライ人も言ってます。それにそもそも私がどのような人間なのかを理解しないと、せっかくの開発手法もそのまま真似してはうまく合わない・上手く回らない・賛成できないということになりますので、非常に大事だと思います。

  • 常に地に足をつけて仕事をするということ

    こちら(北米)で仕事をする場合、一番の褒め言葉は「あいつはAccountableだ」という言葉。辞書には、Accountableには「責任のある」などの訳語が乗っているが、仕事の場面で使う場合は「安心して仕事をまかせておける」という意味。 プログラミングにしろ他の仕事にしろ、何をしていてもさまざまな「予想外の問題」が生じるもの。そういう問題への対処も含めた上で、「あの人に仕事をまかせておけば安心」と思ってもらうには、さまざまなところに予防線を張り、常に「地に足をつけた」状態で、着実に仕事を進めて行くことが何よりも大切。

  • iPhoneアプリを作る際に注意すべき5つのポイント

    毎日のように「iPhoneアプリApple Design Awardを取るぞ!」と騒いでいるので、知り合いに「それって(現実が分かっていない)大学生のノリですよ」と指摘されてしまった私だが、マイクロソフトを2000年に退社してからは、ひたすらモバイル・組み込みの世界で仕事をしてきた私としては「俺が取らなくて誰が取る?」という気分。その超楽天的な態度が彼が言うところの「大学生のノリ」なのだろう。 市場に受け入れられるアプリを作るためには、もちろん「誰にどんな価値を提供するのか」が一番大切。しかし、そこには残念ながら成功の一般方程式はないので、今日は比較的に一般化しやすい「どう作るか」という部分に関して、まとめることにした。 1. ユーザーの利用シーン・使用パターンを良く考えて作る パソコンやゲームコンソール向けのソフトと大きく違うのが、ユーザーの使用パターン。iPhoneに限らず、携帯電話

  • 新サービスを開発するときに気をつけてること : a++ My RSS 管理人ブログ

    もう全然気合が足りないので、自分への戒めも含めて「新サービス開発」について思いつくままにメモ残します。 新サービスを開発するときには: コンセプト = メタファーを決める メタファーとは、「そのサービスって、つまり○○だよね」の○○に当てはまる具体的な言葉です。 どんなサービスでも「既存の言葉」に当てはめないと理解しにくいので。 「GPS機能で配送遅延から距離を感じられるオンラインメッセージングツール」じゃなくて「それって伝書鳩」みたいな。 これは知り合いに説明してみるとヒントが得られること多しです。 サービス名を決める ドメイン取るとかの理由もありますが、名前が決まっているかどうかで作業のはかどり方が全然違います。 アイデア ⇒ 開発 ⇒ 仕上げ の苦しみ度合いを理解しておく 実は開発する作業が一番楽です。厳しいのは仕上げ。途中で萎えないような工夫が必要だったりします。 時間をかけて悩ん

  • ニッポンIT業界絶望論:江島健太郎 / Kenn's Clairvoyance - CNET Japan

    IT業界は救いようがない。絶望的としか言いようがない。 IT業界不人気なんて、この業界に重くのしかかる決して晴れることのない暗雲の氷山の一角に過ぎない。はてな匿名ダイアリーにもどうせ理系出身者なんていらねえんだよ。なんて書かれていたけど、これが現実なのだよ、学生諸君。 ちょっと補足しておくけど、ここでIT業界っていうのは、SIerのことだ。お客さんの要件をヒアリングして、その要求に沿ったシステムを受託開発するっていうビジネスのことを指している。 ぼくもその昔、その世界のループに組み込まれていた。そして華麗なるコミュニケーション能力とやらをいかんなく発揮し、場の空気を読み、生意気なぐらいのチャレンジ精神で、それなりに仕事のできるよい子だったようだ。 いや、正直に言うよ。正直に言うとだね、結構楽しかった。 だって、考えてみてごらん。お客さんのところに出向いて行って、その業界のことをじっ

    ニッポンIT業界絶望論:江島健太郎 / Kenn's Clairvoyance - CNET Japan
  • ユメのチカラ: 開発工程を別々に担当してはいけない

    古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更

  • PC

    パソコンの断・捨・離 いいことずくめのアプリ断捨離、不要なサブスクや悪意あるアプリも排除 2024.03.15

    PC
  • 受託開発事業から自社媒体事業へシフトするための意識改革のポイントとは? - livedoor ディレクター Blog

    こんにちは、小久保です。今回は受託開発事業と自社媒体事業におけるディレクターの意識の違いについて書きたいと思います。 弊社はもともとウェブ関連のSI事業から始まっており、私が入社した5年前もほとんどの仕事がウェブの受託開発・運用でした。 そこから紆余曲折がありながら、現在のメディア事業中心の会社へと変化してきたわけですが、その過程における組織変更はまさに試行錯誤の連続でした。 以前、面白法人カヤックの柳澤社長が「受託開発と自社開発の両立」という記事を書かれていましたが、この記事を読んだときに「やっぱりどこも同じような悩みをかかえているんだなぁ」と激しく共感したことを覚えています。 ところで皆さんは、受託事業と自社媒体事業について一般的にどのようなイメージを持たれているでしょうか? 弊社が事業シフトの過渡期にあったときに頻繁に出ていた声は以下のようなものでした。 受託 = クライアントに詰め

    受託開発事業から自社媒体事業へシフトするための意識改革のポイントとは? - livedoor ディレクター Blog
  • 「エンジニアは魔法使い」という幻想 : LINE Corporation ディレクターブログ

    こんにちは、ライブドアの櫛井です。今回はディレクターとエンジニアの意思疎通についてお届けしたいと思います。 ■魔法使いはいない? 一般的な受託案件などの場合、サイトのプログラムやサーバーまわりの調整などはシステム開発会社の担当の人が一手に引き受けてくれます。しかし、 livedoor のように社内に開発部がある会社では、ディレクターが自力でエンジニアに「何をしたいか」「なぜそうしたいのか」「それをすることで何を目指すのか」ということを正確に伝えていく必要が出てきます。 サイトの規模によってはエンジニアがディレクターを兼ねる場合もあるかもしれませんが、ウェブ業界全体を見てみても「ディレクターで元エンジニア」という人は希少で、ほとんどの場合プログラムやサーバーサイドの仕組みを十分理解できているディレクターというのは稀な存在といえます。 システムの知識を十分持っていないディレクターたちが抱く幻想

    「エンジニアは魔法使い」という幻想 : LINE Corporation ディレクターブログ
  • 1・10・100、それぞれの力 : 小野和俊のブログ

    7月31日に未踏ソフトウェア創造事業の採択結果が発表されました。 未踏ソフトの結果が発表されるたびに、 また面白そうなアイデアが出てきたな、と楽しみに感じる一方で、 いつもどこか心苦しくなるようなところがあります。 とりわけソフトウェアの世界においては、 新しいアイデアを思い描く能力は重宝されやすい傾向にあります。 しかし、 アイデアが世の中に出て行く過程で当に大変なのは、 アイデアを思いついた後です。 アイデアを形にするには10、 それを世の中に受け入れてもらうには100の、 それぞれの間で10倍もの大きさの、越えなければならない壁があります。 これを優秀さという言葉で置き換えれば、優秀さには、 (1) 思い描く能力 (2) それを形にする能力 (3) さらにそれを普及させる能力 の3つの種類のものがある、と言い換えることもできます。 さらにこれらをソフトウェアの世界に当てはめれば、

    1・10・100、それぞれの力 : 小野和俊のブログ
  • 小野和俊のブログ:人月ビジネス、プロダクト、ウェブのサービス

    IT 系の会社の経営者の方と話をしていると、 人月ビジネスをやめて、パッケージやサービスに移行したいという話をよく耳にします。 しかし、半年か一年経ってその後どのようになったのかを聞いてみると、 パッケージやサービスの開発プロジェクトが立ち上がるところまでは行ったものの、 結局は中途半端なものにしかならず断念したという話が多く、 事業内容をスムーズに移行することができたという話はあまり聞きません。 このようなビジネスの転換がうまく行かないケースには、 いくつかの共通点があるように思えます。 第一の関門は、経営陣が、まったく異なるビジネスに対して、 考え方を切り替えられるかどうかという点にあります。 パッケージやサービスのビジネスというのは、基的に先行投資のビジネスです。 まずソフトウェアを完成させるまでに時間がかかり、 次にソフトウェアが世の中で認知されるまでに時間がかかり、 認知されて

    小野和俊のブログ:人月ビジネス、プロダクト、ウェブのサービス
  • つくるぶ -デベロッパー応援プロジェクト

    This domain may be for sale!

  • ODD - おもいやり駆動開発:An Agile Way:オルタナティブ・ブログ

    思いやり駆動開発(ODD) ソフトウェア開発を成功させる、もっともシンプルな「こころがけベース」のアプローチである。オブジェクト倶楽部2007夏イベントで発表された。ここでは、ついカッとなって私なりにこのコンセプトを膨らませてみたい。 ソフトウェア開発はコミュニケーションでできている。ソフトウェアの欠陥が発生しやすいのは、人と人の境界、プロジェクトプロジェクトの境界。そしてそこにはコミュニケーションが生まれている。コミュニケーションには相手があり、その相手を「思いやる」ことが、大切だ。読み手のことを思いやるコードを書こう。システムのユーザを思いやる仕様にしよう。そんなシンプルな「こころがけ」だ。 具体的には、こういうこと。 システムを実際に使う「ユーザー」を思いやろう。ストレスなく使え、「思った機能がそこにある」ようなシステムにしよう。そのユーザが普段使っている言葉のUIを提供しよう。製

    ODD - おもいやり駆動開発:An Agile Way:オルタナティブ・ブログ
  • 【特集】Leopardを先どり - Apple Dashcodeで楽々Widget (1) Dashboardウィジェット開発環境「Dashcode」のベータ版がリリース | エンタープライズ | マイコミジャーナル

    2006年の暮れに、Appleの開発者向けサイトから、「Dashcode」のベータ版がリリースされた。Dashcodeとは、Mac OS X Leopardで登場する予定のDashboardウィジェット開発環境のことである。2006年に開催されたApple主催のデベロッパー向けカンファレンス「Worldwide Developers Conference」(WWDC 2006)では、大きな話題にもなっていた。 今回公開されたのは、そのベータ版であるが、現行のMac OS X Tiger上で動作する。どうやらDashcodeの開発はTiger上でも行われており、正式なリリース前に、広くフィードバックを募りたいようだ。ちなみに、Dashcodeの正式版はLeopard対応版のみのリリースとなり、Tiger上で動作するベータ版は今年の7月15日で期限切れとなる。 今回リリースされたDashc

  • FC2ブログ 現在アクセスが集中しています。

    現在アクセスが集中しており表示しにくい状態となっております。 申し訳ございませんが、しばらく時間を置いてからアクセスするようお願いいたします。 ・FC2フォーラム ・FC2インフォメーションブログ ・最新障害情報・メンテナンス情報ブログ

    mathatelle
    mathatelle 2007/01/22
    サービスウェア理論
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • CNET Japan Blog - 江島健太郎 - Kenn's Clairvoyance:あらためて感じる、開発の進め方の難しさ

    あらためて感じる、開発の進め方の難しさ 公開日時: 2006/04/16 14:43 著者: kenn 最近めっきり開発者モードへと還って失われた日々を取り戻しつつ目下急成長中(注:当人比)の江島でございます皆様いかがお過ごしでしょうか。 色々模索しながらやってきた新サービス開発プロジェクトですが、同僚のダニーがバックエンドのコードを書き、ぼくがUIの部分を担当するという大まかな分業に落ち着いてきています。 すでにpretrieve.comというパブリックレコード検索エンジンを開発してリリースした経験のあるダニーはともかく、ぼくは格的なウェブのサービス開発というのは初めてなので、あちこちで頭をぶつけながら修行中です。 この手のウェブのプロジェクトは、一見簡単そうに見えて実際やってみるとスピーディにやるのは結構難しくて、とくに進め方についてはずっと暗中模索でちょっとずつ前進という