Let the project begin!

After three days of hashing out ideas, completing necessary administrative tasks, and specifying personal goals for our project, we’ve started implementation of Lost Pet App.  Well, that’s what we’re calling it for now.. a memorable, meaningful name to follow.

Each morning starts with establishing daily goals and discussing any research or work our team did the night prior.  One person from our team then meets with either Tom or Dan, our instructors, along with one teammate from each of the other groups to touch base.  We discuss what we’re working on, any foreseeable road blocks, anything we may need help with, and to share things we’ve learned. It’s amazing to hear about the other projects our classmates are working on and thinking back to only 8 weeks ago when none of this seemed possible, yet here we are.

By Friday of this week we plan to have our MVP (minimum viable product) outlined, wireframes completed (maybe digitally?), details on the API’s we plan to use, BDD testing descriptions written, and some user stories outlined.  We’re almost there and we still have two full class days to complete these goals!  Go team!

By spending quality time clearly defining our goals and by choosing a project that meets all of our requirements (personally and academically), we are setting ourselves up for success… and it feels good!


Hello World


Welcome to the blog about our Portland Code School capstone project! We’re excited to share our journey from blank page to developed application.

This is the most ambitious application our team has ever planned. So we’re nervous, but totally stoked. All engines are go for viable product, and no idea is off the table.

You can keep up with our entire process, and track all of our milestones and artifacts on Twitter, and Instagram. If you’re tech-curious, you’re welcome to follow our organization on GitHub. Feel free to submit advice, ideas, and pull-requests.

We’d like to start off by sharing some of our personal goals for this product cycle. Check in with us about our progress, and even hold us accountable!

Personal Goals

We agreed on the following personal goals:

  1. Make a meaningful open-source contribution.
    We believe in the open-source community. All of the best developer tools currently available are open source. We care about perpetuating the open-source paradigm.  That means explicitly seeking ways to give back, and make improvements on the hard work of our predecessors.
  2. Make something accessible to all kinds of people.
    Charlie Chaplin wrote:

    “The aeroplane and the radio have brought us closer together. The very nature of these inventions cries out for the goodness in men – cries out for universal brotherhood – for the unity of us all. Even now my voice is reaching millions throughout the world – millions of despairing men, women, and little children – victims of a system that makes men torture and imprison innocent people.”

    That was 1940, and no one had yet imagined the internet. We believe anyone making things on the internet should take advantage of the inherent qualities of the medium – openness, accessibility, and freedom of information – or else make something else. It’s not easy, but we want our programming to be mindful of the broad spectrum of people with access to the internet. Our work should be as open, inviting, and accepting of all people as possible at every level, as well as being usable by people with varying physical and mental abilities.

  3. Implement 100% test coverage.
    If you’re not testing, you’re just tinkering. The internet is wild, and your stuff will break. Being proactive and thoughtful is the only way to minimize the damage, and ease repairs.
  4. Take advantage of RESTful API’s.
    If you want to write novels, start by writing, not book-binding. Many data sets are public and accessible. Our project should take advantage of that wherever possible, even if the resulting program’s are more difficult to write.
  5. Use some technology none of us has experienced.
    We learned a lot of technology, really fast. Some of it we love, and some we don’t. But we want to prove we’re devoted, agile learners, and that we can continue to learn in the wild. So we explicitly intend to incorporate some technology we have not had any exposure to.
  6. Build something functional cross-platform.
    The beauty of the internet is that it is accessible in many different ways. We are conscious of that, and want to build with an open heart. As robotics developer Ron Evans says: “we are promiscuous developers.” We’re always open to something different, and our code should be too.
  7. Make something broadly interesting, not developer-centric.
    The tech community is amazing, full of clever, funny, thoughtful people. And yet, it can be a little incestuous. Developer tools are great, but we want our project to be something our friends and families see value in. Its easy to get caught solving tech problems, and lose sight of solving people’s problems.
  8. Employ an intelligent build-process.
    That said, we want to use all the clever tools people have built for us. Computers are good at things that humans are not – so let computers do computer stuff, like remembering to compile your source when you make changes.
  9. Take full advantage of version control tools.
    GitHub can be scary. It’s easy to pseudo-use git and get by. But we want to leverage git, not just live with it. Version controlling is a critical element of open-source, and iterative product development.
  10. Leave impeccable documentation.
    Our code, and its implementation, should be crystal clear to anyone literate in our stack. In fact, we’d prefer it pretty much make sense to everyone! Writing clear documentation, with empathy and care, is the best way to accomplish that. We’ve all been on the bad end of unfriendly docs (or no docs…). We refuse to perpetuate the cycle.
  11. Build something worth refactoring.
    We do not want this to be a big, one-off, hack job that we’re excited to be done with. We want to write interesting code that invites refactoring, optimization, and stream-lining. It doesn’t have to be perfect the first time, but it has to be welcoming to improvements.
  12. Implement clear, organized project management.
    There are lots of project management styles and development approaches. We aren’t opinionated about them, but we do think you need one. Haphazard delegation is a fast-track to spaghetti code, and mutual resentment. We want to have fun, and be friends, on top of producing a great project.
  13. More importantly than shipping a polished product, tell an interesting story.
    We know the world of software is all about shipping, and we get that. But right now we have the luxury of being accountable to no one. We want to take advantage of that, and focus on having a compelling personal story, more than a compelling end product.
  14. Incorporate user testing, and take the results seriously.
    If you want to know your safe works, hire a safe-cracker. Remember when we said 100% test coverage? Well, testing doesn’t end with Mocha. We don’t consider “cross-your-fingers…” a viable strategy.
  15. And most importantly, learn a TON.
    Most of all, we want to learn as much as possible. If you want to be mentally flexible, you’ve gotta do mental yoga. The cool postures don’t just happen, you’ve gotta show up everyday, ready to learn. We accept our limitations as developers – and as people! Beginner’s mind-set is the agile programmer’s best friend.