Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Development of a Simple Blog App

Development of a Simple Blog App

An end-to-end look at the development of a simple blog app using a modified Agile workflow and Ruby on Rails. This is meant to provide you with a high level overview of the entire process used to create real applications.

Viking Education

June 18, 2014
Tweet

More Decks by Viking Education

Other Decks in Education

Transcript

  1. Design to Deploy Inside the process of building a real

    application from idea to production
  2. Our Goals 1. Show off a real development workflow from

    beginning to end, something most beginners haven’t seen before. 2. Get you exposed to some of the tools and processes we’ll be learning later on in the program. 3. This is just an overview and is NOT meant to teach you code or everything about the tools!
  3. Who Uses This Workflow? • This is the workflow you

    might take to build an application for yourself or a client, where you’re doing it all on your own. • If you were in a larger team, roles would be divvied up but the process wouldn’t be too much different. • So, basically, anyone should find this useful.
  4. How it Works 1. Figure out User Needs 2. Build

    a Mockup of our site 3. Break the mockup into bite-sized Stories. For each story: I. Determine and set up required Data Architecture II. Build the Back End of the story III. Build the Front End! 4. Refactor, iterate and then Ship the site to production.
  5. Data Architecture Back End Front End Story Mockup For Each

    Story: Refactor & Iterate The Workflow Mockup(s) User Needs Break into Stories Ship it!
  6. 1. Figure out User Needs • Joe, Jane, and Sarah

    are old school bloggers. • They remember the days when blogging was brand new and they’ve been feeling nostalgic. • They want something simpler and more communal than today’s fancy tools…
  7. 1. The ability to create posts. I. No need to

    edit or delete posts — they’re up there for good. II. The post creator can fill in their own name 2. The ability to comment on posts. I. No need to edit or delete comments either. II. The comment creator can fill in their own name 3. No logins required — this is all honor-system. 1. Figure out User Needs
  8. 2. Build a Mockup • Turn user needs into critical

    product functions • Brainstorm a product to fulfill user needs • Iterate and test with the users to find a successful mockup
  9. 3. Break into Stories • Slice up the mockup into

    bite-sized pieces based on very specific user needs, for example: ✴ “As an [author], I want to [publish posts on the site] so that I can [put my thoughts on the web],” ✴ “As a [reader], I want to [easily view the most recent posts] so that I can [stay up to date]” ✴ “As a [reader], I want to [write a comment on that post] so that I can [offer my thoughts on a post]” • Then prioritize the stories to tackle first and get started
  10. Tackle a Story: “As a reader, I want to write

    a comment on a post so I can offer my thoughts on that post”
  11. Story I: Determine Data Needs • Need to “save” the

    comments • Comments need fields for content, author, and the parent post’s ID • A post can have many comments Post Comment Comment Comment Comment ! content (string, 140 max) author (string, 20 max) post_id (integer)
  12. Story Part IV: Refactor + Iterate • Consolidate repetitive code

    • Check with the user / client that the story meets their specifications • Iterate as necessary to get it right
  13. Review • You’ve seen that we have got a pretty

    handy approach to tackling a new project: ! ! ! • You got to see some real coding too! Ship! User Need Mockup To Stories Build Mockup! Data! Back End! Front End! Iterate?!