奥别产デベロッパの祭典＠东京：奥别产エンジニアの视点
- 2. 自己绍介
- 3. 高桥征义
- 4. 所属
- 5. 株式会社 ツインスパーク
- 6. 仕事
- 8. 别の肩书
- 9. 日本Ruby の会 会長
- 10. 日本Ruby の会
- 11. 目的
- 12. Ruby利用者 の支援
- 13. Ruby開発者 の支援
- 14. 活动内容
- 15. 日本Ruby 会議の開催
- 17. 各種イベント への参加
- 18. 地域Ruby 会議の後援
- 19. 本日の お題
- 20. Web エンジニア の視点
- 21. 開発現場 からの視点で
- 22. 研究開発 ではなく
- 23. 事業戦略 でもなく
- 24. 技術とビジネス のベタな話
- 25. 思い ついた話
- 26. とある宴会 での議論
- 27. デザイナーと プログラマ
- 29. 意見が 対立
- 30. 話が噛み 合ない
- 32. 違う ビジネス
- 33. 異なる 前提
- 34. 残念な すれ違い
- 35. 本日の 内容
- 36. 3つ
- 37. 第１部
- 38. 4つの 世界
- 39. Web開発にも いろいろある
- 40. ジョエルの パクリ
- 41. 第２部
- 42. Web開発 の変遷
- 43. 技術の 変わり方
- 44. 言語を 中心に
- 45. 第３部
- 46. 未来の话
- 47. どうなる どうする
- 48. 正直よく 分からない
- 50. よろしく お願いします
- 51. 第１部
- 52. 4つの世界
- 53. 5つの世界
- 54. ジョエル?オン ?ソフトウェア
- 56. ソフトウェアに 関するエッセイ
- 57. 5つの世界
- 58. Webでも 公開
- 62. １つ目
- 63. パッケージ
- 64. 箱売り
- 65. ダウンロード 販売
- 66. オープン ソース
- 67. ２つ目
- 68. インターナル
- 69. 業務 システム
- 71. ユーザビリティ
- 72. 優先度は 高くない
- 73. 開発速度 は重要
- 74. ３つ目
- 75. 组み込み
- 76. ハードと セット
- 77. アップデート できない
- 78. 品質要求 が高い
- 79. 速度重要
- 80. プロセッサ の遅さを カバー
- 81. ４つ目
- 82. ゲーム
- 83. 当たれば でかい
- 84. ほとんど 当たらない
- 85. どこで儲けて どこで損するか
- 86. どこまで損して 大丈夫か
- 87. ポートフォリオ が重要(らしい)
- 88. 5つ目
- 89. 使い捨て
- 90. ちょっとした コード
- 91. 仕事中に よく書く奴
- 92. 一回だけ 使用
- 93. 二度と 使わない
- 94. スクリプト が典型
- 95. 違う世界 での事例
- 96. 当てはま らない
- 97. 自分は どの世界に いるのか
- 98. 情報収集時 は要注意
- 99. Web の世界
- 100. 異なる世界 に分かれる
- 101. 4つの世界
- 102. 2×2の マトリクス
- 104. 2つの 対立軸
- 105. 業務システム vsメディア
- 106. 自社惫蝉受託
- 107. 私はメディア で受託が中心
- 108. 業務システム vsメディア
- 109. 業務 システム
- 110. 業務に使わ れるもの
- 111. インターナル に近い
- 112. ユーザ層 は限定
- 113. メディア
- 114. コンシューマ 向けサイト
- 115. ITというより メディア産業 の一種かも
- 116. コーポレート サイト
- 117. コミュニティ サイト
- 118. ポータル サイト
- 119. セールス プロモーション サイト
- 120. この２つは 性格が異なる
- 121. 受託の场合
- 122. 顧客の 違い
- 123. 業務システム の顧客
- 124. 情報システム 部門
- 125. 予算は 大きめ
- 126. メディア の顧客
- 127. 企画宣伝 部門
- 128. 予算は 少なめ
- 129. 直接収益化は 困難?無理
- 130. 機能の 違い
- 131. 業務システム の機能
- 132. 差別化の 根幹
- 133. 絶対に譲れ ないものも
- 134. メディアの 場合
- 135. 機能は なくても可
- 136. 差別化の ポイント
- 137. 早さ
- 138. リリース 時期
- 139. 広い意味の ユーザ体験
- 140. 伝達する 情報とセット
- 141. 素朴でも 構わない
- 142. 静的でも 構わない
- 143. 速度と コスト
- 144. ここでの ポイント
- 145. 私たちは何を 売っているのか
- 146. 何が売り なのか
- 147. 見失い がち
- 148. 技術の 変化
- 149. メディアに 業務システム の速度感
- 150. 業務システムに メディアの コスト感
- 151. 混乱
- 152. もう一つ の軸
- 153. 自社か 受託か
- 154. 主な违い
- 155. 要件管理
- 156. 自社でなければ 細かく管理 できない
- 157. Webは 更新が重要
- 158. 受託の 難しさ
- 159. 自社開発 の困難
- 160. 正直 詳しくない
- 161. 人材を常に 抱えておく のが難しそう
- 162. 運用時と 開発時
- 163. 常に开発
- 164. コスト的に 見合うように する必要
- 166. まとめ
- 167. 自分の位置を 把握する
- 168. 第２部
- 169. Web開発 の変遷
- 170. 3つの 時代区分
- 171. ～2000年顷
- 172. Webの 黎明期
- 173. CGIの 全盛期
- 174. C/Perl/ VB(ASP)
- 175. 既存言語＋ 便利な関数
- 176. 回線も 貧弱
- 177. ブラウザ も貧弱
- 178. 牧歌的な 時代
- 179. 2001年～ 2005年頃
- 180. Webアプリ の特性への 理解が進む
- 182. サーバサイド の特徴を 踏まえた開発
- 183. 開発の パターンが 見えてきた
- 184. Webアプリ ケーション フレームワーク
- 185. 作業の省力化 ?効率化が 進む
- 186. 主に 業務システム 寄りの動き
- 187. もう一つ の流れ
- 188. PHP
- 190. 便利な関数が てんこもり
- 191. HTMLに言語 を埋め込み
- 192. 手軽さに 軸足を置く
- 193. メディア側 で歓迎
- 194. 2006年以降
- 195. Ruby on Rails
- 196. 必要最低限の ことのみ 記述
- 197. フレームワーク の徹底化
- 198. 書かなくても 良い部分は 一切書かない
- 199. 汎用言語の 枠内で実現
- 203. プログラミング 言語について 掘り下げ
- 204. もう一つの 言語
- 205. 設定 ファイル
- 206. プログラミング 言語の ２つの視点
- 208. 自由度
- 209. 書きたいことが 何でも書ける
- 210. 难易度
- 211. 書きたいことが 簡単に書ける
- 212. 何でも書ける 言語の極北
- 213. アセンブラ
- 214. C/C++
- 215. ポータビリティ 等の問題
- 217. 書けないことも ある言語で十分
- 218. 簡単に書ける 言語の極北
- 219. 設定 ファイル
- 220. CSV ini XML 独自記法
- 221. プログラマ ではない人でも 書ける
- 222. 決められた事 しか書けない
- 223. 特にロジックを 書くのが困難
- 225. 中間が 欲しい
- 226. DSL
- 228. ドメイン 特化言語
- 229. 一種の 簡易言語
- 230. ほどほどの 記述力
- 231. ほどほどの 書きやすさ
- 232. 言語内 DSL
- 233. 独自言語の ように見える 汎用言語
- 234. Ruby on Railsで駆使
- 235. class Person < AR:Base has_many :groups belongs_to :company validates_presence_of :name end
- 237. 他フレーム ワークにも 多大な影響
- 238. ご清聴 ありがとう ございました