This page is being redesigned for the 2022-2023 school year. New information will be added/updated as needed. That said, be sure to REFRESH this page daily so that you make sure you are seeing the latest updates.
If you get stuck and/or something doesn't make sense, contact your teacher immediately.
The Hackathon Project is usually the culminating project of the Fall Semester. You will follow the directions on this page - rather than the directions on the Code.org website - as we will make several significant changes to the Code.org version of this project.
In general, this project will be a very similar type of project to what you will create in the spring for your official project that you send to the College Board as part of your AP Exam. If you do well with this project, you should be in great shape for your spring project. If you don't do well, you still have several months to improve your skills so that you complete your official project with confidence.
For the Hackathon Project, you will create a program that includes the following elements:
Has a user interface that requires user input for the program to work.
Uses data from an external data set
Uses existing data (from dataset) and user input to create new data
Has a user-defined function that includes:
sequencing
selection
iteration
(Bonus) Has a user-defined function that incorporates at least one parameter.
You can make any type of program that incorporates these elements.
If you are having trouble figuring out where to start with this project, I strongly suggest that you first find a data set that you want to work with. Once you find the data set, figure out what kind of app you would like to make that could take advantage of that data.
The general criteria for grading will be based on the following:
How well a student properly PREPARES and PLANS OUT the entire project before attempting the first build (your PREP phase)
How well the student honestly REFLECTS, ASSESSES, and makes appropriate ADJUSTMENTS (as necessary) to the project build.
The quality of final ARTIFACT. This will be assessed in the following ways:
The UX (User Experience) of the finished product (does the program actually work, etc.)
How well the student follows good programming conventions when writing the code (whitespace, indentation, comments, naming conventions, user-created functions, organization/structure, etc.).
The quality of WRITTEN RESPONSES in the final evaluation. The final evaluation in this project is set to mimic the types of responses your will have to do for your project in the spring.
This project can be broken up into FIVE main chunks:
Project Proposal
Project Planning
Iterative Project Development (building, testing, and continually making small improvements/adjustments)
Final Project Submission
Evaluation, Feedback, and Reflection
While we generally do these in order, there is overlap between the last four chunks. For example, we are constantly reflecting on the project from the very first day (via our programming journal) and there are Reflection elements built in to the Iterative Project Development . . . that, in turn, can cause us to go back and refine our original plan.
This is a very interactive and flexible process.
The Project Proposal can be chunked into TWO main steps:
Determine the Scope of your Project
What do you plan to build (a new project or are you extending another project)?
How much time do you have to build it?
Create your Project Proposal (ONE-PAGER)
You will need to complete a project you can accomplish in the time we have allocated for this project. This may sound obvious but coming up with a REALISTIC idea of what you can successfully build in the allotted time is an important skill to develop. We are not looking for the best project you can make. We are looking for the best project you can make in the given time. Make sure you understand the difference and keep that in mind as you craft your ONE-PAGER.
Some project elements will be easier to tackle than others. Make sure you arrange your time so that you can accomplish as many elements as possible in the given time. Tackle the easiest parts of the project first and progressively layer in the more advanced elements.
You are better off with a solid, working project that maybe doesn't have all the elements rather than a projects that attempts all the elements and is buggy and clunky.
Remember that is is practice for your CREATE PT project (the project that you will send to the College Board as part of your AP Exam). Your project is evaluated on six discrete elements. You will get a score from 0-6. If you know you can nail 5 of the elements, it's better to make a project that meets those five elements (and gets a 5/6) rather than try to force that sixth element and jeopardize your other points.
Traditionally, your ONE-PAGER is printed in hard-copy form and is limited to one page (kind of like a resume). However, will be creating and submitting a DIGITAL document that will incorporate digital pictures so we will not hold to a page limit.
. . . but we will still call it a ONE PAGER.
Your ONE-PAGER must be approved in order for you to earn points on the rest of your project.
A typical ONE-PAGER for a New Web App should contain all the important facts about the project you intend to build. Typically, it should contain the following:
State the theme/genre of your APP.
State the overall purpose for creating the APP.
Explain how the app functions:
How do you start the app?
How does the user interact with the app? (be as detailed as possible)
How does the user get help if they get stuck?
Sketches of the UI. All APPs are different so what you sketch will depend on YOUR APP. Your sketch(es) should make it clear to a stranger what you expect your APP will look like AND what the experience will be like. On each sketch, you should:
identify all the UI elements that will appear on the screen. Make a distinction between the UI elements that the user can (and can't ) interact with.
identify the naming convention(s) you plan to use for the UI elements
Sketches of your Data Table:
Give a sample of what the columns of your data table will look like AND a few sample rows of data.
Identify which columns you plan to import into your program as a list.
Make a copy of the Hackathon Project: ONE PAGER document and follow the embedded DIRECTIONS in the document.
Keep the document PRIVATE but give your teacher COMMENTING rights. You can't earn any points for your work if I can't see your work.
The formatting of the ONE-PAGER document is entirely up to you. Arrange your page in a way that best communicates your information. Use use solid visual communication and design strategies.
Finally, seek help if you have any questions or you are having any trouble completing this assignment.
When you are sure you have completed all the requirements for the ONE-PAGER, go to the ONE PAGER section of the AP CSP: Class Projects: Submission Forms page to submit your digital document for approval.
Once your ONE-PAGER IS approved, you can start earning points on the rest of your project.
Your first big assessment will be on the quality of the PLANNING you do before you start your build.
To get your project started off on the right footing, you need a solid plan.
If you plan well, the rest of your project usually runs smoothly. If you plan poorly, you will likely encounter a lot of frustration while trying to build and complete your project.
The Project Planning can be chunked into THREE main steps:
Establish and set up your Programming Journal
Complete the Version Schedule in your Programming Journal (this should be completed prior to starting your first build).
Complete the "Prep" section of your Programming Journal (this should be done prior to starting your first build).
Your programming journal is where you will document your project scope, your project planning, and your prep work.
Make a copy of the Hackathon Project: Programming Journal.
The directions for completing each section of the PJ are embedded in the digital Programming Journal document - EXCEPT for the Version Schedule. You will find additional instructions on how to complete the VS below.
We will also do a review of how to complete the VS in class.
[Hidden]
In order to make your document available for periodic checkups (as well as your final submission), you are going to SUBMIT your document NOW. Don't worry, you can keep on making edits to your document after you submit.
Before submitting, be sure to keep the document PRIVATE but give your teacher COMMENTING rights. You can't earn any points for your work if your teacher can't see your work.
Go to the Programming Journal section of the AP CSP: Class Projects: Submission Forms page to digitally submit your work.
The VERSION SCHEDULE (VS) is the final step of your PREP work. The VS serves several purposes:
It helps you plan your project by identifying all the iterative steps you plan to build throughout the project
It helps you manage your time by either:
helping to keep you on schedule, or
knowing when you might need to adjust your plan because you are too far behind (or too far ahead) of schedule.
It keeps links to archives of your completed builds for quick access.
The TASK column will help you organize your build. This column should list a description of each iteration/build of your project. You should organize the tasks in the order that you plan to complete each of these builds. This part of the table should be completed first. Once you've laid out all your builds, and you have them organized in a logical, sequential order, you can begin to complete the rest of the table.
The SCHEDULE TO FINISH column will help you plan out and schedule your time. Look at each task. How long will it take you to complete that task? What day to you expect to complete that task? Remember, you only have three weeks. Many students start with a specific plan for their project. Then, once they plan out how much time it will take to complete each task, they realize that they may need to modify (add or remove tasks) in order to either finish the build in three weeks OR in order to continue iterating their project over the course of three weeks.
In the VERSION column you will list VERSION NUMBER that you assign for that task. Your numbering system should match the modified semantic versioning we use for our class projects (see the section below for more information). Be sure to identify your major updates vs. your minor updates vs. your "baby-steps."
The DATE COMPLETED column will only be filled out when you successfully complete a working version of that task/build AND you have linked to the REMIXED version of that project. Your task is not considered complete until it is bug free, archived, and linked to your VS. Only then should you fill out the Date Completed section of your VS.
As you are working, you may find that some tasks take longer than your had anticipated and you might complete other tasks sooner than anticipated. This is normal. It's hard to predict, in the very beginning of your project, exactly how everything will play out in the future. Even if you find that you are getting wildly behind schedule, don't adjust your VS. Just keep an accurate record of when you complete your work.
However, if you find that you are way ahead of schedule, you will need to modify your VS by adding more tasks to complete. Remember, your goal is to continue to iterate throughout the entire project. Do NOT, under any circumstances, stop working if you complete all your tasks. Your job is to use all your time to make the best possible project.
{Hidden]
If you are starting a NEW project, your version numbering should start at 0.0.1 and (ideally) the final version of your project should be version 1.0.0 (a fully functional and complete project - ready for people to use and enjoy). However, depending on the scope of the project, you may not be able to build a project from 0.0.0 to 1.0.0 in three weeks. Therefore, it is possible to submit a project that is still incomplete (has not reached version 1.0.0) and still receive a good grade. Likewise, it is also possible that you could complete a fully functional project (made it to 1.0.0) and receive a poor grade because the project you planned out for your three-week project could have been finished in one week. EVERY. PROJECT. IS. DIFFERENT.
Remember, your goal is to continue to iterate for the entire three weeks. Your grade is based more in the journey (constant iterative development) rather the end (whatever project you end up with).
Our class versioning system follows the basic principles of Semantic Versioning but is adapted for our class use. We still use three places with each number separated by a dot (i.e., X.Y.Z where each letter represents a number).
It is important to note that this is NOT a decimal system. Each number (X, Y, or Z) can be any size. For example, 1.6.2 is just as valid as 2.823553.38 - it all depends on how you identify the tasks in your build. For our class we are usually trying to build our project up to VERSION 1. Version 1 is usually considered your first major release of your completely finished, working, and stable project. Therefore, unless you are extending an already working project, all your version numbers will likely be somewhere in the range from 0.0.0 to 1.0.0.
The X place holds the major version number. This is what we usually hear about with games. Is this version 1 of the game or version 3 of the game. It is reserved for major releases. In our class, if we take a game as an example, we would consider version 1.0.0 to be a fully working game with a splash screen, end screen, a scoreboard to keep track of stats, and multiple levels of increasing difficulty.
The Y place holds the major improvement to your program as you iterate though the builds towards version 1. For example, version 0.4.0 would be two major iterations BEFORE version 0.6.0 but neither of these iterations (versions) would be our final fully functional program (which would be 1.0.0).
The Z place holds all the iterations of your build as you work through your major improvements. In class, we usually call these the baby-steps of your iterations. These are the tiny changes you make in between major improvements of your build. For example, if between version 0.4.0 and 0.5.0 there were SIX baby-steps that I needed to accomplish the make this change, I would expect to see all of the following version numbers (listed in order from oldest (top) to newest (bottom):
0.4.0
0.4.1
0.4.2
0.4.3
0.4.4
0.4.5
0.4.6
0.5.0
If 0.4.6 is the last baby-step I need to do to finish my next major change, I don't need 0.4.7. Instead I jump straight to 0.5.0. Remember, this is NOT a decimal system. It is not uncommon to have version numbers that look like this: 0.17.32. It all depends on YOUR task list.
Finally, EVERY TIME you change your versioning (which is every time you complete a specific task) you should have a saved (REMIXED) file of the game at that version. EVERY saved version of your project should be bug free.
Never REMIX a "broken" project and never leave a task unfinished. ALWAYS make sure your new task is working BEFORE you move on to the next step.
If you are new to versioning, you should checkout the sample used on the DODGER game starter tutorial before you get started. Additionally, you should watch the two videos below to give you more background.
Still a little confused about how the versioning system works? Watch this video where I analyze the version numbering system used for the Dodger Game Starter Tutorial.
Still confused about how to fill out the versioning schedule in your PROGRAMMING JOURNAL? Watch this video where I evaluate and critique some previously submitted programming journals.
{Hidden]
The remaining first several pages of your PROGRAMMING JOURNAL are dedicated to the rest of your planning documents. These include tables for your:
element IDs
variables
Conditionals/Loops
onEvent functions
user-defined functions
These are all considered part of your PREP work for this project. Fill out each page/table as required. Be as thorough and as detailed as possible. The better attention you pay to the details in the PREP section, the more likely that you will have an easy time BUILDING your program.
Building a programming project is a series of small, incremental steps. Because most programming languages are so exact, it is important that you constantly test your work to catch, and fix, all bugs as they happen.
{Hidden]
Using your Version Schedule (VS) as your guide, you should attempt to tackle your first build (or, if you have already started your project, the next build on your list).
{Hidden]
Once you have completed your task (from your Version Schedule (VS)), you need to test and make sure that your build is bug free and stable/working. If you find bugs, you must fix them before you move on.
Never attempt to add new coding structures when you have bugs in your code.
{Hidden]
If your build/task is stable and bug free, you need to make an archive of that build so that you will have it for future reference. It should be a snapshot of that moment in your project.
Do NOT continue to iterate an archived build. Once a build is archived, you should not touch it anymore.
{Hidden]
Once you have archived your build, create a link to that archived build in your Version Schedule so that you can have quick access to it when needed.
{Hidden]
At this point, you should review your Version Schedule (VS). Are you on track? Do you need to modify anything regarding your project? If you do, make those changes to your VS. If not, select the next task in your VS and repeat the steps above.
Continue this process every day until it's time to submit a version for evaluation.
{Hidden]
{Hidden]
Navigate to the Peer Evaluations section of the AP CSP Class Projects: Submissions Forms page to complete the Peer Evaluations for this project.
{Hidden]
Make a copy of the Hackathon Project: Final Reflection and Self Evaluation document and follow the embedded instructions.
{Hidden]
Navigate to the Final Reflection section of the AP CSP Class Projects: Submission Forms page to submit your work.
{Hidden]