タグ

関連タグで絞り込む (230)

タグの絞り込みを解除

開発に関するtknzkのブックマーク (336)

  • 社内向けWebサービス開発のススメ - kotas.tech

    社内向けWebサービス「ニコニコプロデュース」 例えば、コードレビューをしている時に誰かが鋭いツッコミを入れてくれた時。 例えば、社内のチャットで、ふと誰かが名言を書き込んだ時。 そんな「もっと評価されるべき」を、「評価」する手段が欲しい。 そんな思いから、社内向け Web サービス「ニコニコプロデュース」を作りました。 画面はこんな感じです。 使い方は簡単で、「だれうま」とか「GJ」とか思ったらポイントをあげる。それだけです。もらったポイントの使い道は特にありません。 こんな感じで、趣味としてちょこちょこ社内向けサービスを作ったり、簡単なツールを作ったりしているので、その魅力について語りたいと思います。 作っている間 なにせ自分で1から企画して自分で全て実装するので、作っている間はとても楽しいです。 「こういうページがあってー、こういう UI でポイントをつけれてー・・・あ、ユーザー認証

    社内向けWebサービス開発のススメ - kotas.tech
  • メール駆動開発は時代遅れではないか - プログラマの思索

    マネージャになるほど膨大な量のメールを処理するのが主な仕事になってくる。 また、SEの仕事の殆どは、顧客やメンバーからのメールや添付されたExcelを元に、設計書をどんどんブラッシュアップしていくことだ。 倉貫さんのつぶやきを読んで、同感すると共に、果たしてそれが当に良いことなのかラフなメモ。 【元ネタ】 Twitter / @kuranuki: メールで5人とかに送って、ひとりtypoとかで届かなかったときの残念さったらない。もう一度5人に送り直すか、その人だけに送り直すか。前者は他の人にはウザいし、後者はこれからの返信に漏れるし。もう複数人でのメールやだ。 Twitter / @kuranuki: メールでは手紙で出来ること以上のことをやっちゃいけないんだよ。 Twitter / @kuranuki: メールのccにいつまで偉い人を入れておくのか判断が難しい。遠慮なく入れた方が良いの

    メール駆動開発は時代遅れではないか - プログラマの思索
    tknzk
    tknzk 2011/12/11
  • 中国市場から撤退する弊社から、中国でアプリを売りたい皆さんへ - やまもといちろうBLOG(ブログ)

    弊社・イレギュラーズアンドパートナーズ株式会社は、投資先と合弁で行っていた大連の開発拠点事務所を閉鎖し、社員および他拠点ごと合弁先に全株譲渡し、中国での開発から撤退しました。残るラインは、国内で吸収するか、ベトナム・ダナンかハノイかに事業協力先とご一緒し新設する会社に移行させようか悩んでおります。どうしたら合理的なんでしょうねえ…。 いま、ソーシャルゲームを含むデジタルコンテンツの開発などで中国に進出する会社が増えていて、成功例も徐々に出てきているのですが、提携や合弁会社を設置した当初は凄く良好だった関係も、なぜかビジネスがうまくいったり、特定の中国人の才能やセンスに依存したモノづくりになった瞬間に、どうしても関係がギクシャクしてしまうことが多いように感じます。 中国でのアプリ販売は確かに伸びておりまして、信頼できる良い提携先が見つけられるのであれば、中国独資か合弁会社を設立するかに関わら

    中国市場から撤退する弊社から、中国でアプリを売りたい皆さんへ - やまもといちろうBLOG(ブログ)
  • IDEA * IDEA

    ドットインストール代表のライフハックブログ

    IDEA * IDEA
  • 「失敗しないアジャイルの導入の仕方」 - 楽天テクノロジーカンファレンス2011 #rakutentech - ヲトナ.backtrace

    11/19 に開催された楽天テクノロジーカンファレンスで上記のタイトルで講演させていただきました。 当日の資料を公開しておきます。 How to not fail at adapting agile software delopment View more presentations from Nishimura Naoto 今回は、僕があちこちでお手伝いしているアジャイルの導入で気をつけている事ややり方などを中心にお話ししました。 もちろん、このやり方だけが正解では無いですし、みなさんなりの導入の仕方のヒントになれば幸いです。 そして、参加していただいた皆さん、サポートしてくださったスタッフの皆さん、当にありがとうございました。 また、一緒に土壌作りとかお手伝いしてよって方がいましたら、お気軽にご連絡下さいww

    「失敗しないアジャイルの導入の仕方」 - 楽天テクノロジーカンファレンス2011 #rakutentech - ヲトナ.backtrace
  • 週に1日、エンジニアが開発に集中できる日を作ろう

    毎週決められた曜日には、会議も電話もメールもチャットもなく、上司から話しかけられもせず、エンジニアが開発に集中できる日が確保される。クラウド上でRuby on RailsなどのPaaSを提供しているHerokuでは、エンジニアが開発に集中できる日「Maker's Day」が毎週設定されているそうです。 Publickeyが月曜日に公開した記事「アジャイル開発手法でクラウドを作るHerokuのやり方とは」で、HerokuエンジニアCraig Kerstiens氏のブログ」を基に、Herokuでの開発の様子を紹介しました。Kerstiens氏はその続きとして「How Heroku Works - Maker's Day」をポストし、Maker's Dayを紹介しています。 トム・デマルコ氏とティモシー・リスター氏による有名な書籍「ピープルウェア」でも、エンジニアにとって集中できるオフィス環境

    週に1日、エンジニアが開発に集中できる日を作ろう
  • テスト手法や複数人開発の詳しい人に質問です。…

    テスト手法や複数人開発の詳しい人に質問です。 (CodeCompleteの内容は前提知識としてあるぐらい) コードのマージ時にマージミスで重複行が発生してしまうのを防ぐ 良い方法ってご存じでしょうか。 具体的にはマージ時に、マージのミスで call_method(foo) if cond call_method(foo) end みたいな重複行が発生することをチェックする仕組みがや取り組みが知りたいです。 なおテストケースではc1は網羅しててもメソッドの重複呼び出しだと場合によりテストが失敗しないので、テストをもっと書くべきというアドバイス以外でお願いします。

  • 日本国民総プログラマー化計画について! 【増田(@maskin)真樹】 | TechWave(テックウェーブ)

    1990年代初頭から記者としてまた起業家としてITスタートアップ業界のハードウェアからソフトウェアの事業創出に関わる。シリコンバレーやEU等でのスタートアップを経験。日ではネットエイジ等に所属、大手企業の新規事業創出に協力。ブログやSNSLINEなどの誕生から普及成長までを最前線で見てきた生き字引として注目される。通信キャリアのニュースポータルの創業デスクとして数億PV事業に。世界最大IT系メディア(スペイン)の元日編集長、World Innovation Lab(WiL)などを経て、現在、スタートアップ支援側の取り組みに注力中。 [読了時間:2分] TechWaveでは、より多くの人にITプロダクトの創出プロセスを理解してもらう目的で、総力を結集して「日国民総プログラマー化計画」を推進していきます。子供から学生、社会人、定年退職後の皆さんまで趣味として職業としてプログラミングをさ

    日本国民総プログラマー化計画について! 【増田(@maskin)真樹】 | TechWave(テックウェーブ)
  • 転職して感じたウォーターフォール文化とアジャイル文化の違いについて - 達人プログラマーを目指して

    今月から新しい会社に転職して、あっという間に半月が過ぎてしまいました。いろいろな会社の規則や、開発環境、フレームワーク、仕事の進め方など、とにかくたくさんのことを短期間で詰め込む必要があり、もともと想定していたことではありますが自分としてはかなりたいへんでした。 やはり、自分としては、外資系の会社で英語でのコミュニケーションが必要となるということが、最も気がかりなことでした。実際、初日の歓迎ランチはいきなり名前もわからない多くの外国人に囲まれる状況でしたし、電話会議を使って中国アメリカのチームと一緒に行う日々の進捗ミーティングも英語で行われています。自分としては、特に、リスニングが苦手ということもあり、いまだに完全に会話についていくのが困難なところはありますが、同僚やマネージャーもみんなすごく親切に教えてくれるので安心しました。私は新しい環境に慣れるのに結構時間がかかる方なので、まだまだ

    転職して感じたウォーターフォール文化とアジャイル文化の違いについて - 達人プログラマーを目指して
    tknzk
    tknzk 2011/10/19
  • ゲーム開発プロジェクトマネジメント講座(SQUARE ENIX OPEN CONFERENCE)

    ゲーム開発 プロジェクトマネジメント講座 2011年10月8日 株式会社スクウェア・エニックス CTO 橋 善久 1©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか? 2©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ(コンテンツの範囲)の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース(人員・環境)の問題 • ビジネスの問題 4©SQUARE-EN

  • 工数見積もりで陥りやすい罠 - プログラマの思索

    「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記:一部修正した。 ※追記:Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念~Velocity: プログラマの思索 ソフトウェア開発に特有な技術~ソフトウェア見積り: プログラマの思索 チームは加速するのか~Velocityの使い

    工数見積もりで陥りやすい罠 - プログラマの思索
  • 小規模Webサービス向け安上がりシステム構成と開発フロー(怖話.jp) - Fjord, Inc(株式会社フィヨルド)

    こちらのエントリーが大変参考になったので、僕らが作ってる怖話.jp(kowabana.jp)のシステム構成や開発方法についても公開していこうと思います。 怖話.jpはスマホ向けWebサービスなのでPC向けとはPVとかの傾向がちょっと違うかも知れません。 怖話.jpとは スマホで17,000話以上のサウンドノベル風の怖い話が閲覧・投稿できるサイト(アプリではありません)です。詳しくは下記エントリーを参照してください。 スマホでサウンドノベル風怖い話投稿サイト | FJORD, LLC(合同会社フィヨルド) 7月16日にRubyKaigi2011に合わせて無理矢理ベータテストオープンして、8月9日に正式オープンしましたので正式オープンからは1ヶ月経ってないまだまだのサイトです。開発期間は約1ヶ月ぐらいです。 サイト情報 (これAnalyticsを直接貼るのはどうやればいいんだろう?) 直近一ヶ

    小規模Webサービス向け安上がりシステム構成と開発フロー(怖話.jp) - Fjord, Inc(株式会社フィヨルド)
  • Amazon.co.jp: 「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか: 小森裕介: 本

    Amazon.co.jp: 「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか: 小森裕介: 本
  • 継続開発のススメ - Twisted Mind

    概要 開発をすればリリースがあり、リリースが終われば開発があります。継続開発をする以上はリリースと開発の繰り返しです。 開発手法やリリース手段は沢山あるのですが、あまりしっくりくるものが無かったので自分でまとめてみました。 これで完璧というものは残念ながらこの世にないと思うので、これからも臨機応変に良い流れを作って行ければと思います。 この文章は以下のような構成になってます。書き殴りですみません。 バージョンの付け方 ソースコード管理とリリース タスク駆動 環境方針 定義 いくつか事前に定義しておかないと話しが訳わからなくなりそうなので。 バージョン管理には git を採用しています。 開発というのはコードを書く事だけを指してはいません。 ここでいうフレームワークは「自身で開発している」として扱います。そうしないとちょっと難しいので。 ライブラリは自身の開発とそれ以外があると思いますので、

    継続開発のススメ - Twisted Mind
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

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

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • こだわりのある職人プログラマーほど、無駄なコードを少なくしたいものという事実を理解してほしい - 達人プログラマーを目指して

    ちょっと興味深いエントリが目に留まりました。「プログラミングへのこだわり」を方向づける: 設計者の発言基的に、この方自身もプログラマーや開発者をされているようですし、他のエントリを読んでも「プログラマーの地位向上をすべき」ということで、私にとっても非常に共感することをおっしゃっているのです。それでも、ちょっとこのエントリの内容については疑問に思うところがあったので、勝手ながら私の意見を書かせていただきたいと思います。 業務システムの生産性や保守性を高めるための基は「コードを1行でも減らす」である。なぜなら、コーディングとこれにともなうテスティングこそが、開発作業の中でもっとも人手のかかる作業だからだ。個別案件においては、良いコードだろうが悪いコードだろうが少なければ少ないほどよい。 これは、まさにおっしゃる通りですね。もちろん、可読性ということもあるため、厳密には最少のコードが最良とい

    こだわりのある職人プログラマーほど、無駄なコードを少なくしたいものという事実を理解してほしい - 達人プログラマーを目指して
  • ドメイン駆動式ソフトウェアの育て方 - Digital Romanticism

    レッツゴーデベロッパー2011での発表原稿とスライド 導入 2011年05月28日「レッツゴーデベロッパー2011@仙台」が開催されました。このイベントのテーマは「共有と交流」。"「共有」には、最新技術、知識、復興への想い、それぞれの決意を共有することを、「交流」には、東北と東北圏外のデベロッパーやコミュニティ同士の交流を深めることを込めて。" このイベントにてDDDセッションに登壇させて頂きましたので、そのときの発表原稿とスライドを公開致します。なお、当日はワークとして参加者の方にペアモデリングを行って頂きましたが、このドラフトではその部分を割愛しています。 スライドはこちら また映像はこちらで公開して頂いています。 さて今年4/9にDDD日語版が出版されました。それから2ヶ月弱、翔泳社様から、はやくも増刷のお知らせを頂きました。多くの方々とおかげと深く感謝しています。さて、この増刷が

    ドメイン駆動式ソフトウェアの育て方 - Digital Romanticism
    tknzk
    tknzk 2011/06/06
  • Stargazer : Hacking the Stars: ソフトウェア開発、ウェブサービス開発、そしてドッグフード

    ソフトウェア開発における概念でドッグフードというものがあります。残念ながら Wikipedia には英語の記事しかありませんが、これを簡単に説明すると自分たちが作ったものを世に出す前に自分たちで使ってみる (ってみる) という概念です。ここで重要なのは、自分たちというのは開発者たちだけではなく、なるべく社内で広く使ってもらうという事です。言うまでもなく、ウェブサービスもソフトウェアですし、人が使うモノを作っている時点で適用される概念です。米国のソフトウェア企業では製品の公開前によく使われている手法のようです。 ここで紹介できる私の人生における実例を語ると昔話になりますが、私が株式会社ミクシィで働いていた頃、 mixi Echo (現 mixi Voice) というサービスを作りました。これは世間的に昔ほど日記を書かなくなったという声を身内やウェブ上で耳や目に入り、それが時代の流れであれば

  • Private Presentation

    Private content!This content has been marked as private by the uploader.

    Private Presentation
  • ゲームプランナーが知るべき25のこと

    1. 万人に受け入れられるゲームは理想だが存在しない ラピュタみたいな物 2. 正しいデザインは機能性と相反しない デザイナーを説得しろ 3. スケジュールは工数を当てはめるパズルではない 無理な物は無理だ 4. 言わずに後悔するより言って後悔しろ ああすればよかったのに…という後悔は無駄だ 5. リサイクルよりフルスクラッチ 他人が作った物を直すより最初から作った方が速い この点においてプログラマーを信じるな 6. プログラマー、プランナー、デザインの言う「可能」はそれぞれ意味が違う 時間があれば出来る、なんとなく出来ると思っている、気が向いたら完成する 7. 企画書は企画が通ったら捨てろ さて、俺の好きなゲームをゼロから構築するぜ! 8. よく出来ている は褒め言葉ではない どちらかと言うとdisの言葉だ 9. パクリを気にするな お前の作っている物も多分パクりだ 10. 理論的な説明