P4p20120408

3,377 views

Published on

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,377
On SlideShare
0
From Embeds
0
Number of Embeds
1,970
Actions
Shares
0
Downloads
2
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • P4p20120408

    1. 1. p4p preprogram for planner
    2. 2. agenda• プランナー向けプログラム部とは• 決意表明• 知っておきたい技術 • gitで学ぶバージョン管理 • sinatraで学ぶrubyとWAF • herokuの紹介 • rails入門
    3. 3. プランナー向けプログラム部とは
    4. 4. プランナー向けプログラム部 とは• 対象はwebの知識はあるけどプログラムは少し敷居が高いと感じているプランナー向け• 作れるようになりたい人向け• アイデアを形にしたい人向け
    5. 5. プランナー向けプログラム部 とは• プログラマーとプランナー双方のノウハウ共有をしたい• プランニングforプローグラマーも需要あれば
    6. 6. 知っておきたい技術
    7. 7. 知っておきたい技術• バージョン管理 • git• ruby• WAF • sinatra • rails• PaaS • heroku
    8. 8. 多い
    9. 9. 今日はある程度さら りとやりますよ
    10. 10. 決意表明の時間
    11. 11. 知っておきたい技術
    12. 12. 知っておきたい技術• バージョン管理 • git• ruby• WAF • sinatra • rails• PaaS • heroku
    13. 13. バージョン管理
    14. 14. バージョン管理 システムとは“バージョン管理システム(バージョンかんりシステム)とは、コンピュータ上で作成、編集されるファイルの変更履歴を管理するためのシステム。特にソフトウェア開発においてソースコードの管理に用いられることが多い。” wikipediaより
    15. 15. 主な機能• ファイルの作成日時、変更日時、変更 点などの履歴を保管• 履歴から過去の状態に戻れる• ブランチによる歴史の分岐
    16. 16. リポジトリre・pos・i・to・ry /rpztri|-pztri, -tri/1a 貯蔵所,倉庫.b 納骨堂,埋葬所.2 〔知識などの〕宝庫 〔of〕.3 〔秘密などを〕打ち明けられる人〔of〕.
    17. 17. リポジトリのタイプ単一型(svnなど) 分散型(gitなど)
    18. 18. clone• リモートリポジトリから個人リポジト リへコピーする行為 git clone
    19. 19. com・mit /kmt/→(com・mit・ted; com・mit・ting)1 委託する: コミットとはa +目(+to+(代)名)〈人を〉〔刑務所・精神病院などへ〕引き渡す 《★しばしば受身で用いる》.→b +目+to+(代)名〈もの・人を〉〔処置・記録・記憶などに〕ゆだねる,付する.→c [∼ oneself で] 〔…に〕身を任す [ゆだねる] 〔to〕.→d 〈議案を〉(審議のために)委員会に付託する.2 掛かり合いにさせる: [∼ oneself で]a +目+to+(代)名(責任上)〔特定の目的・責務を〕引き受ける; 〔…を〕約束する 《★また過去分詞で形容詞的に用いる; →committed 2》.→b +目+to do〈…すると〉約束する.→c +目(+in+(代)名)〔…において〕のっぴきならぬ立場になる 《★また過去分詞で形容詞的に用いる; →committed 3》.→d +目+to+(代)名〔…に〕専心する,傾倒する,コミットする 《★また過去分詞で形容詞的に用いる; →committed 1b》.→e +目+on+(代)名〔掛かり合った問題などに〕自分の立場[態度]を明らかにする.→3 〈罪・過失などを〉犯す.→ラテン語「一つに組み合わせる,ゆだねる」の意 (COM-+mittere 「送る,譲る」); commission,
    20. 20. コミットバージョン管理においてコミットとは、ワークツリーで変更したファイルの記録をリポジトリへファイルへ記録すること
    21. 21. ワークツリー• 作業ファイル群• 主に、ローカルマシンで作業している ファイルやディレクトを差していると 考えれば良い
    22. 22. コミット時の哲学コミット単位は論理的に1つのまとまりを単位にして行うべきである(アトミックコミットと呼ぶ)。例を挙げると、トップページのお知らせを変更する目的としたコミットにおいて、ロゴの画像変更を同じコミットにするべきではない。ただしロゴの変更をお知らせに記載するような場合は同じコミットにすべきと考える。更に大きな単位で例を挙げるとredmineにおける別チケット作業は同じコミットにすべきではない。そもそもこの場合はbranchを分けるべきである。branchについては後述。アトミックコミットの利点は、個別の論理的な編集単位で取り消しややり直しが効くことである。これはバージョン管理を使う利点の1つでもあるので、この原則が守られていないプロジェクトはバージョン管理の利点を1つ損なっていると肝に銘じるべきである。
    23. 23. 意識高い
    24. 24. gitのお話します• index• push、pull• branch• merge
    25. 25. さらっとです
    26. 26. index• gitではcommitする前に、indexという領 域にデータを記録する。• work treeとrepositoryの間にindexという 概念が存在すると考えると分かりやす い。 git add
    27. 27. ワークツリーとインデックスとレポジトリの関係ワークツリー インデックス リポジトリ
    28. 28. コミットまでの流れ 作業中ワークツリー インデックス リポジトリ インデックスへ記録ワークツリー インデックス リポジトリ git add
    29. 29. コミットまでの流れ コミットワークツリー インデックス リポジトリ git commit インデックスへ記録ワークツリー インデックス リポジトリ git add
    30. 30. コミットまでの流れ コミットワークツリー インデックス リポジトリ git commit
    31. 31. svnの場合だと?ワークツリー リポジトリ svn commit
    32. 32. push, pullgit push git pull
    33. 33. branch /brnt|brnt/→→ branch1 (木の)枝 《★【類語】 branch は幹 (trunk) から出る枝; bough は大枝; twig は小枝; spray は葉や花がついた小枝; tree 1 さし絵》.→2 枝状のもの 〔of〕:a 支流.b (山の)支脈,支系.c =→branch line.3a 分家.b =→branch office.4 部門,分科 〔of〕.→→rot and brnch1 動(+副(句))〈木が〉枝を出す[広げる].→2a 動(+副)分岐する 〈off,away,out〉.→b (+副)+前+(代)名分岐して〔…に〕なる 〈out,off〉〔from,at〕.→3 +from+(代)名〔…から〕分かれて生じる.→→brnch ff
    34. 34. branch ブランチA マスター ブランチB
    35. 35. merge 取り込む mergeしたことで成長
    36. 36. gitコマンド• 初回のリポジトリからの取得はgit clone {repository_uri}• インデックスへの追加はgit add {file_name}• インデックスへの追加をアトミックに 行うにはgit add -pがオススメ
    37. 37. • リポジトリへの記録はgit commit• リモートリポジトリへの同期はgit push• リモートリポジトリからの同期はgit pull
    38. 38. • ブランチの作成はgit branch {branch_name}• ブランチの切り替えはgit checkout {branch_name}• マージはgit merge {branch_name}
    39. 39. 実習• githubに登録する• リポジトリを作る• 個人リポジトリへcloneする
    40. 40. Ruby
    41. 41. RubyRuby(ルビー)は、まつもとゆきひろ(通称Matz)により開発されたオブジェクト指向スクリプト言語であり、従来Perlなどのスクリプト言語が用いられてきた領域でのオブジェクト指向プログラミングを実現する。Rubyは当初1993年2月24日に生まれ、1995年12月にfj上で発表された。名称のRubyは、プログラミング言語Perlが6月の誕生石であるPearl(真珠)と同じ発音をすることから、まつもとの同僚の誕生石(7月)のルビーを取って名付けられた。機能として、クラス定義、ガベージコレクション、強力な正規表現処理、マルチスレッド、例外処理、イテレータ・クロージャ、Mixin、演算子オーバーロードなどがある。Perlの代替となることができることが初期の段階から重視されている。Perlと同様にグルー言語としての使い方が可能で、Cプログラムやライブラリを呼び出す拡張モジュールを組み込むことができる。Ruby処理系は、主にインタプリタとして実装されている(詳しくは#実装を参照)。構文は、ALGOL系を継承しながら、可読性を重視している。Rubyにおいては整数や文字列なども含めデータ型はすべてがオブジェクトであり、純粋なオブジェクト指向言語といえる。
    42. 42. Ruby長らく言語仕様が明文化されず、まつもとによる実装が言語仕様に準ずるものとして扱われて来たが、2010年6月現在、JRubyやen:Rubiniusといった互換実装の作者を中心に機械実行可能な形で明文化するen:RubySpecという試みが行われている。公的規格としては2011年3月22日にJIS規格(JIS X 3017)が制定され、その後2012年4月1日に日本発のプログラム言語初の「ISO/IEC 30270」として承認された [2]。フリーソフトウェアとしてRubyライセンス(Ruby License や Rubys と表記されることもある。GPLかArtisticに似た独自ライセンスを選択するデュアルライセンス。)で配布されている。
    43. 43. Ruby哲学開発者のまつもとゆきひろは、「Rubyの言語仕様策定において最も重視しているのはストレスなくプログラミングを楽しむことである (Enjoy programming)」と述べている。(ただし、まつもとによる明文化された言語仕様は存在しない。)Perlのモットー「やり方はいろいろある (TMTOWTDI; Theres More Than One Way To Do It)」は「多様性は善(Diversity is Good)」というスローガンでRubyに引き継がれてはいるものの最重要なものではないとも述べており、非推奨な手法も可能にするとともに、そのような手法を言語仕様により使いにくくすることによって自粛を促している。これは言語仕様が「望ましい」習慣の押し付けを行うということであり、洗脳言語(Babel-17)と言われる一面でもある。
    44. 44. 実習• http://dotinstall.com/• rubyをやりましょう
    45. 45. Sinatra• http://www.sinatrarb.com/• http://www.sinatrarb.com/intro
    46. 46. 実習• 一緒にコードを書きます
    47. 47. heroku
    48. 48. heroku• PaaS • プラットフォーム一式をサービスとして提供するビジネスモデルのこと。 • ネットワーク経由のアプリケーションを対象とした提供サービスがSaaS • これをクラウドコンピューティング時代にふさわしくプラットフォームや開発環境全般 に拡張させたものがPaaSである。• http://www.slideshare.net/ayumin/ heroku-12136993
    49. 49. heroku• heroku login• git initしたワークツリー内へ移動• heroku create xxxx -s cedar• git push heroku master
    50. 50. まとめ• 面白いと感じたらがんばろう• 作れるプランナーは最強

    ×