First some administrative stuff! Before you start you will need to supply the following:
- Team Members
- Project Description
- Tech stack (and short reason why)
- Project Name
- Preferences for mentor (if any)
There are many reasons for picking a project:
- Are you trying to build something impressive for prospective employers?
- Are you trying to explore a technology?
- Are you trying to practice your existing set of skills?
Think about this, since it will set the tone for what you'll do.
Let's begin with some high-level rules:
Time is short, so KISS!
KEEP IT STUPID SIMPLE
or
KEEP IT SIMPLE, STUPID
(your pick)
You need to be able to summarize what you want to accomplish in one sentence. Everything else comes after that.
This answers the first question: WHAT?
Don't worry about implementation details at first, but make a list of what you'll need. Use this to break the problem you want to solve into its component parts.
This begins to answer the second question: HOW?
While you're doing this, remember YAGNI
You Ain't Gonna Need It
Remove everything that feels optional. Ask yourselves what's the bare minimum for your idea to work. That's your Minimum Viable Product (MVP).
Don Burks made an amazing list of things to do next: https://gist.github.com/donburks/9f47f22cc2fb54ac7396
But in short:
- Take your list of features and make user stories
- Figure out the data you'll work with
- Create workflows on how the users will provide that data and interact with it
- Wireframes!
- Storyboards!
- Tools:
- https://wireframe.cc
- https://moqups.com/
- Good ol' whiteboarding
- It's always better to think from the perspective of the user, not what's easier to implement
- How to write user stories: https://medium.com/@jonatisokon/a-framework-for-user-stories-bc3dc323eca9
-
GIVE YOURSELF MILESTONES
- Set due dates
- Set development targets
- Meet them
- Use Trello to track your user stories
-
SMART Goals (because you must know when something is actually done)
- Specific
- Measurable
- Achievable
- Relevant
- Time-based
- Use git!
mastershould always be sane - in other works, it should always contain runnable code- Use feature branching
- A very good tutorial: https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
- Git cheatsheet: http://www.ndpsoftware.com/git-cheatsheet.html
- Use database migrations and seeds
- Remember: each developer will have their own copy of the database, so migrations will be used to keep the schema in sync, while seeds will provide initial data (e.g admin users)
- Write tests if you can
mochais your friend
- Good programmers are lazy
- Use Express Generator to create an app skeleton, if you're using Express
- There's a
npmpackage for that- If you're using an external service, look for a package
- There's a CSS framework for that
- Bootstrap
- Materialize
- Hundreds of others!
This is the way TinyApp works. Every link and form submission results on the page being completely reloaded from scratch. Every single request needs its own EJS template inside /views.
The server code receives regular HTTP requests and plain form data, and returns rendered HTML pages based on EJS templates.
By the way, those EJS templates are server-side. This means the server builds the HTML with the data you provide as templateVars and sends the completed HTML to the browser.
Tweetr is a good example of this. The HTML is completely static (not EJS) and every action is handled by client-side Javascript code (inside /public in Express) with AJAX requests.
The server-side code only receives and outputs data, usually in JSON format. This means every form, button and link must have an attached JS function.
In other words the server will NOT use EJS or other server-side templates. All requests and responses will use JSON.
You may have static HTML pages in the /public folder, but the data will always be displayed using client-side Javascript to render HTML using JSON data received from the server.
This means more client-side code, but the results are more interactive. React, Ember and Angular are examples of client-side frameworks geared towards making single-page applications.
Some pages are request-response (welcome page and login form, for example) while others have SPA features.
A good example would be an e-commerce application showing a sticky shopping cart panel. Every time an item is chosen, the cart updates without reloading the page. On the other hand, the whole page reloads when the user presses the "order" button on the cart.
This is usually the quickest approach to write a good, interactive web app for your midterms - or if you have a content-heavy app in general. It's very common for professional apps to start like this and then migrate to a full SPA architecture.
Some large applications are structured as multiple SPAs with a few request-response actions in between. For example, Facebook and Twitter have a request-response login page, while the main application is a large SPA. A good exercise is using a few of your favourite web apps and trying to figure out which requests reload the whole page.
Midterm projects are about exercising what you've learned, gathering feedback from mentors and improving your skills. Final projects, on the other hand, are about impressing potential employers and people in general. So be ambitious and make it look good.
Your user interface will certainly be at least 70% of your code. Do not underestimate the time you will spend on it - even if you use an UI library such as React-Bootstrap.
You don't need to create everything from scratch - we already know you're capable of building apps. Feel free to use libraries and cloud services, as long as they provide something useful for you. This brings us to our next point...
If you see a cool library or service you want to try, set aside a fixed amount of time to do a test drive - an afternoon should do. If you can do something usefull with it and think it will save time in your project, go for it! On the other hand, if the time to get it up and running exceeds your timebox or if the gains are negligible, scrap it.
Always! You need to have a very good idea of what are the main features and what can be left out. Remember this doesn't mean delivering an incomplete app, but a polished, working app that does what it's supposed to do with no frills.
Unit testing (i.e. testing individual functions and methods) is nice, but integration tests are way more important. You should definitely test interface points - the areas of your app where the user interacts with it and where your client-side interacts with your API. If you're making a SPA, do try to test your API endpoints!
It can be tempting to go solo, but past experience at Lighthouse Labs tells us this isn't a good idea. Building a polished app in 2 1/2 weeks is no small feat, so having at least two people working together is a must.
- Ensure your local
masteris up to date:git checkout master && git pull origin master - Start your feature branch:
git checkout -b my_feature - codecodecode,
git commit, codecode, goddammit!, codecodecode,git commit, YAY! - Switch back to
masterand update it again:git checkout master && git pull origin master - Merge your feature in:
git merge my_feature - Resolve any conflicts (hopefully you don't have any!)
- Test the updated
masterbranch locally git push origin master