タグ

開発に関するdameninngenn_owataのブックマーク (14)

  • プログラムが書けない人に「仕様変更」について説明するには | tech - 氾濫原

    「仕様変更」という言葉はプログラム書く人じゃないと、そのイメージが掴めないと思う。イメージが掴めない人に対してそれを説明するとしたら何がいいだろう? と思った。 とりあえず、料理に例えたらいいのではないかと思ったので、それに例えて考えてみる。 仕様とはレシピのことであり、最終的には具体的に「べることができる美味しい料理」すなわち「うまく動くプログラム」を作ることを目的としている。 仕様というのは、最初は「イタリア料理」「日料理」「中華料理」程度しか示されない。当然この時点では方針程度しか考えることができない。材を買うこともできない。せいぜい使う調味料を揃えるぐらいしかできない。 もう少し進むと、料理名まで具体化される。スパゲティを作りましょうとか、ピザを作りましょうとかだ。とりあえずここまできたら小麦粉を買おうとかまではできるかもしれない。でも実際に作りはじめることはできない。 さら

  • この先生きのこるには

    ちょっとずつ複雑なことをやっていっているのですが、正直まだ自分で作っていくイメージがついていません。 加速と減速=イージングタイムラインパネルのフレーム数がでてるとこの下のスライダーでワークエリアの幅を操作できるグラフエディターというのが存在する。値グラフと速度グラフ。グラフを編集するときに触るのはハンドルだけイージングの速度が早くてコマが見える時はモーションブラーをかける(13:40)モーションブラーは色々ごまかせてしまうので最後につけたほうがいい。処理が重いから最初のほうでつけるとプレビューのときにしんどいとかもある(ただプレビューのときだけオフにするとかもできる)

    この先生きのこるには
  • 「ボケて」のスケールアップとスケールアウト - ゆーすけべー日記

    オモロキで鎌団子さんと二人で開発している写真で一言ボケるWebサービス「ボケて」。 バックエンドの改修作業、それに伴うバグ等の修正を施し、やっと落ち着いて来たので、 そのことについて書いておこうと思います。 ボケてとは? 改修作業の詳細に入る前に「ボケて」とは、を紹介します。 ボケては「お題」と呼ばれる「写真」に一言「ボケ」を加えて笑いをつくりだせるWebサービスです。 ユーザーはお題写真のアップロードやそうした写真に対するボケのテキストを入力でき、 最新のものや評価されたお題とボケを見ていくことができます。 評価の高いものはやっぱり面白くて見てると吹き出しちゃうものもたくさんあります(当社比)。 開発は上記した通り鎌団子さんと二人でやっていて、 鎌団子さんがデザインやHTML絡み、 僕がバックエンドやシステム周りを行っています。 5月13日、爆発 さて、そのボケてですが、今年の「5月13

    「ボケて」のスケールアップとスケールアウト - ゆーすけべー日記
  • ソフトウェア開発プロジェクトをとりまく6つの誤解〜プログラミングを経験しないとわからないこと | Social Change!

    続きを書きました → 伝えなければ伝わらないという当たり前の話 ソフトウェア開発に関する相談を受ける中で、どうもソフトウェアというものの特性について誤解をされているな、という思いを持つことがあります。 そうした場合、聞いてみるとプログラミングの経験が無かったり、殆どプログラミングには携わったことがないという方が多いです。 ソフトウェアを開発しようとするならば、ソフトウェアという特性をよく知った上で、プロジェクトは運営した方が良いし、うまくいくはずです。そしてソフトウェアならではの特徴を知るのに、プログラミングの経験はとても重要です。 この記事では、プログラミング経験の無い方が陥ってしまいがちな、ソフトウェア開発にまつわる誤解について考えてみました。 Harry Potter is Ready for Divination / weekbeforenext 誤解:既にあるソフトウェアを流用し

    ソフトウェア開発プロジェクトをとりまく6つの誤解〜プログラミングを経験しないとわからないこと | Social Change!
  • プログラマが欲しい仕様書とは

    3. ソフトウェア工学とは • ソフトウェアの開発・運用・保守に ついて体系化、分析、研究する分野 • 高度で安全なソフトウェアを短期間 で設計するための研究を行う

    プログラマが欲しい仕様書とは
  • 愛宕山太郎坊/Staff

    愛宕山太郎坊 アニメーション制作進行支援ソフト 愛宕山太郎坊 ログイン 会社id ユーザー名 パスワード ユーザー名またはパスワードが正しくありません。 閉じる ログイン

  • 「鉄拳タッグトーナメント2」を60fpsで動作させるために開発者が知恵を絞ったポイント

    日2011年9月6日(火)より9月8日(木)までパシフィコ横浜にて開催されている、日最大のゲーム開発者向けカンファレンス「コンピュータエンターテインメントデベロッパーズカンファレンス2011(CEDEC2011)」の一環として「2体から4体!? ~鉄拳タッグトーナメント2における描画システムと負荷削減について~」という、2011年9月14日から全国で稼働を開始する人気格闘ゲーム最新作「鉄拳タッグトーナメント2」において使用されている描画システムと負荷削減(主に描画)について、描画プログラムのリーダーを務めたバンダイナムコゲームスの堂前嘉樹さんが講演を行ったので聴講してきました。以下に掲載する講演の全内容とスライドを読めば、現地で聴講した気分をかなりリアルに味わえるはずです。 プログラミング | CEDEC 2011 | Computer Entertaintment Developer

    「鉄拳タッグトーナメント2」を60fpsで動作させるために開発者が知恵を絞ったポイント
  • Javaプログラマが知るべき9のこと - @katzchang.contexts

    はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下: 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ

    Javaプログラマが知るべき9のこと - @katzchang.contexts
  • 子供のスマホ知恵袋

    PRあり 2023年末~2024年春に実施されている学生や22歳以下向けの割引キャンペーン情報を一か所にまとめてみました↓

  • iOS向けゲームが15分で開発できる、高速HTML5ゲームエンジン「IMPACT」登場 【増田(@maskin)真樹】 | TechWave(テックウェーブ)

    [読了時間:1分] 先日、リリース間近とお伝えしたHTML5ゲームエンジン「IMPACT」が12月21日未明、正式に公開となった。同エンジンで開発されたゲームは、iOS上では60フレーム/秒を実現するとされており、HTML5対応のウェブブラウザであればプラグインなどをインストールする必要なく実行できるという特徴を持つ。サイトには、効率の良い開発スタイルを説明するビデオやサンプルソースコードなどが公開されている。ライセンスは価格は99ドル。 エンジンを開発した独Dominic Szablewski氏は、HTML5に対応したモダンブラウザ上で高速に動作するゲーム「Biolab Disaster」を公開、その開発のために使用したエンジンを一般に提供すると告知していた。今回の正式リリースで、このゲームもアップグレード。公言通り、iOS上でも快適に動作するようになっている。 lMPACTは、HTML

    iOS向けゲームが15分で開発できる、高速HTML5ゲームエンジン「IMPACT」登場 【増田(@maskin)真樹】 | TechWave(テックウェーブ)
  • 都議会、ソフトウェアのソースコードを規制する条例を可決 - カタチづくり

    2010年12月某日、都議会ではソフトウェアのソースコードを規制する条例案を可決した。 条例の内容は、可読性やメンテナンス性の悪いコードを不当に賛美あるいは誇張する書物を規制するもので、ソフトウェア工学を学んでいる学生の目に触れないようにすることを目的としたものである。条例が運用段階に入ると、都内の大学生協の書籍売場からはそういった書籍が姿を消す可能性が高い。また都議会では、今後都に対して納入されるシステムについてもソースコードを厳しく監視し、可読性やメンテナンス性に著しく劣ると判断されたコードは検収を上げないとも述べている。 これに対し、都内のギークたちが一斉に反発。「可読性」「メンテナンス性」「不当に賛美」といった指標は判断基準が明確でなく、解釈次第で規制の対象がどこまでも広げられるというのがその理由だ。 一方で、条例には賛同する声もある。都内のとあるSEは「ひどい連中は誰にも引き継げ

    都議会、ソフトウェアのソースコードを規制する条例を可決 - カタチづくり
  • 少人数開発に役立つ5つのまとめ

    if ( $blog == " Webエンジニアのためのライフハック " ) { print " 1-byte.jp "; } ホーム1-byte.jpとは 書いてるヒトは ここ2ヶ月間で気になる記事がたくさん上がっていました。 特に少人数チームにおける開発に関する記事です。 昨日、書き上げた”1年間の技術的負債を返すために読んだ3冊の“にある通り、お知らせメールでは1年間の技術的負債を返そうとしています。 そのためには今まで曖昧だった箇所を浮き彫りにし、改善する必要があります。 また、せっかくなので新しいモノも取り入れたい。 こうしたことを考えながらの2ヶ月だったので、自然と目に止まった記事が3つありました。 スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ 複数人(2-3人)でウェブサービスを開発するコツ A successful Git branching m

  • A successful Git branching model を翻訳しました

    Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら: http://nvie.com/posts/a-successful-git-branching-model/ (翻訳の公開と画像の利用は人より許諾済みです) このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト仕事でもプライベートでも)で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書

    A successful Git branching model を翻訳しました
  • nabokov7; rehash : 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム

    October 22, 201010:13 カテゴリプログラミング組織とyou 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム perl 界隈の皆様、YAPC::Asia 2010 おつかれさまでした。 @nipotan のライトニングトークはシャッフルに関する話でした。で、ここで、なぜそもそもシャッフルが出てきたのかについて、チームマネジメント的な観点から補足したいと思います。 (元の発表はこちら: 動画 / スライド ) ■相互チェック体制の運用 ライブドアのプログラマは、だいたい一人でひとつのサービスを受け持っています。一人が複数のサービスを受け持つのは普通ですが、一つのサービスに複数のプログラマがフルコミットするという贅沢な状況はあまりありません。 担当が一人ずつしかいないと、担当の人が休むと何も進まない。やりたいことが色々あ

  • 1