SEI-30
SEI Singapore#
Welcome to General Assembly's Software Engineering Immersive - Singapore Edition! This repo is the primary resource used throughout the course, save it to your favorites and refer to it often!
Instructional Team#
| Name | Title |
|---|---|
| Simon Lau | Instructional Lead |
| Neo Jun Siang | Teaching Assistant |
| Samuel Tan | Teaching Assistant |
| Kerin Ong | Student Success Specialist |
| Tania Mancilla | Career Coach |
Important Policies#
Course Completion Requirements#
In order to qualify for any subsidy and to receive outcomes job search support each student must fulfill the requirements of the course.
Pre-work#
You should have completed the pre-work in preparation for the course. This is to ensure that you can handle the pace of the class.
Attendance#
Our attendance policy for graduation is no more than 3 absences during the course. 15 minutes late = 1 tardy. 3 tardies = 1 absence. If you know you'll be late or absent, please let us know and we'll arrange to have your tardy or absence excused.
Practice Work and Projects#
Practice Work: 80% needs to be submitted. Completion of the requirements IS NOT required. Only submission. Submission must be before 9am the next day. Projects: Must complete the minimum requirements for each project.
Behavior#
Code Of Conduct#
Here is a link to the code of conduct. Everyone is expected to behave in a cordial and professional manner during the course. If you feel that anyone is breaking the code of conduct, don't hesitate to contact your instructor, TAs or GA admin staff.
Plagiarism: addendum#
Copying and using code you didn't write is a natural part of learning and is expected and encouraged. However you are expected to be able to explain to a satisfactory degree any code you include in a project or assignment and clearly be able to identify which code you are personally responsible for writing and which you are not.
Social Rules#
From: Recurse Center Social Rules These rules are intended to be lightweight, and to make more explicit certain social norms that are normally implicit. Most of our social rules really boil down to "don't be a jerk" or "don't be annoying." Of course, almost nobody sets out to be a jerk or annoying, so telling people not to be jerks isn't a very productive strategy. That's why our social rules are designed to curtail specific behavior we've found to be destructive to a supportive, productive, and fun learning environment.
0. "I don't know" & "I don't understand" are important and accepted statements#
1. No feigning surprise#
The first rule means you shouldn't act surprised when people say they don't know something. This applies to both technical things ("What?! I can't believe you don't know what the stack is!") and non-technical things ("You don't know who RMS is?!"). Feigning surprise has absolutely no social or educational benefit: When people feign surprise, it's usually to make them feel better about themselves and others feel worse. And even when that's not the intention, it's almost always the effect. As you've probably already guessed, this rule is tightly coupled to our belief in the importance of people feeling comfortable saying "I don't know" and "I don't understand."
2. No well-actually's#
A well-actually happens when someone says something that's almost - but not entirely - correct, and you say, "well, actually…" and then give a minor correction. This is especially annoying when the correction has no bearing on the actual conversation. This doesn't mean this isn't about truth-seeking or that we don't care about being precise. Almost all well-actually's in our experience are about grandstanding, not truth-seeking. (Thanks to Miguel de Icaza for originally coining the term "well-actually.")
3. No back-seat driving#
If you overhear people working through a problem, you shouldn't intermittently lob advice across the room. This can lead to the "too many cooks" problem, but more important, it can be rude and disruptive to half-participate in a conversation. This isn't to say you shouldn't help, offer advice, or join conversations. On the contrary, we encourage all those things. Rather, it just means that when you want to help out or work with others, you should fully engage and not just butt in sporadically.
4. No subtle -isms#
Our last social rule bans subtle racism, sexism, homophobia, transphobia, and other kinds of bias. This one is different from the rest, because it covers a class of behaviors instead of one very specific pattern. Subtle -isms are small things that make others feel unwelcome, things that we all sometimes do by mistake. For example, saying "It's so easy my grandmother could do it" is a subtle -ism. Like the other three social rules, this one is often accidentally broken. Like the other three, it's not a big deal to mess up – you just apologize and move on. If you see a subtle -ism, you can point it out to the relevant person, either publicly or privately, or you can ask one of the faculty to say something. After this, we ask that all further discussion move off of public channels. If you are a third party, and you don't see what could be biased about the comment that was made, feel free to talk to your instructors, TAs or GA admin staff. Please don't say, "Comment X wasn't homophobic!" Similarly, please don't pile on to someone who made a mistake. The "subtle" in "subtle -isms" means that it's probably not obvious to everyone right away what was wrong with the comment. We want this to be a space with as little bigotry as possible in it. Therefore, if you see sexism, racism, etc. outside, please don't bring it in. So, for example, please don't start a discussion of the latest offensive comment from Random Tech Person Y. For many people, especially those who may have spent time in unpleasant environments, these conversations can be very distracting. We want to remove as many distractions as possible so everyone can focus on programming. There are many places in the world to discuss and debate these issues, but there are precious few where people can avoid them.
5. Why have social rules?#
The goal isn't to burden everyone with a bunch of annoying rules, or to give us a stick to bludgeon people with for "being bad." Rather, these rules are designed to help all of us build a pleasant, productive, and fearless community. If someone says, "hey, you just feigned surprise," or "that's subtly sexist," don't worry. Just apologize, reflect for a second, and move on. It doesn't mean you're a "bad" person. As we said above, these rules are meant to be lightweight. We've all done these things before. Sometimes pointing out that someone broke a social rule can be challenging or feel awkward. If you don't feel comfortable pointing out to someone that they are consistently breaking a social rule, please feel free to ask for help from a GA staff.
Schedules#
Course Weekly Schedule#
Week 1 - Javascript (Programming Language)#
| Monday | Tuesday | Wednesday | Thursday | Friday | |
|---|---|---|---|---|---|
| Morning | Course Intro/Expectations, Navigating terminal, intro to JavaScript and Programming | Git and GitHub, Intro to Conditionals and Loops | Functions, Scope | Object-ception | Callbacks |
| Afternoon | Conditionals, Booleans, Loop | Arrays and Iteration | Program Design, Objects | Combining Datatypes | Array Methods w/Callbacks |
Week 2- Jquery (DOM Library)#
| Monday | Tuesday | Wednesday | Thursday | Friday | |
|---|---|---|---|---|---|
| Morning | OOP (object methods, classes) I | DOM Intro | DOM Manipulation with Functions and Loops, Populating Dom from Data | Event Bubbling | AJAX, Code Organization |
| Afternoon | OOP (object methods, classes) II | jQuery | DOM Events (listeners and handlers) | DOM capturing input, iteration, targets | DOM events in a loop |
Week 3 - Project 1 (Javascript Game)#
| Monday | Tuesday | Wednesday | Thursday | Friday | |
|---|---|---|---|---|---|
| Morning | Project | Project | Project | Project | Project |
| Afternoon | Project | Project | Project | Project | Project |
Week 4 - React (Front end)#
| Monday | Tuesday | Wednesday | Thursday | Friday | |
|---|---|---|---|---|---|
| Morning | Intro To React, Components and JSX | State - useState I | Lifting State | React Lifecycles & useEffect | useContext |
| Afternoon | Nested Components, Passing Props | State - useState II | Controlled vs Uncontrolled Input | Fetching API's | useReducer |
Week 5 - React ecosystem#
| Monday | Tuesday | Wednesday | Thursday | Friday | |
|---|---|---|---|---|---|
| Morning | React Router I | Styling Components | Custom Hooks | React Lab | Recap |
| Afternoon | React Router II | Intro to Redux | React Testing | React Lab | Project Ideas Presentation |
Week 6 - Project 2 (Front end with API)#
| Monday | Tuesday | Wednesday | Thursday | Friday | |
|---|---|---|---|---|---|
| Morning | Project | Project | Project | Project | Project |
| Afternoon | Project | Project | Project | Project | Project |
Week 7 - Express (Backend)#
| Monday | Tuesday | Wednesday | Thursday | Friday | |
|---|---|---|---|---|---|
| Morning | Intro to Express | REST: Index and Show | REST: New and Create, | REST: Delete | Mongo |
| Afternoon | Params and Routing | MVC and EJS | cURL, Static Assets | REST: Edit, Update | Mongoose and Schemas |
Week 8 - MERN (Mongo, Express, React, Node)#
| Monday | Tuesday | Wednesday | Thursday | Friday | |
|---|---|---|---|---|---|
| Morning | CRUD: Read, New, Create | CRUD: Delete, Edit, Update | Sessions, Authentication | MERN Stack | Recap |
| Afternoon | Seed | Express Router | Heroku | MERN Stack | Project Ideas Presentation |
Week 9 - Project 3 (Group)#
| Monday | Tuesday | Wednesday | Thursday | Friday | |
|---|---|---|---|---|---|
| Morning | Project | Project | Project | Project | Project |
| Afternoon | Project | Project | Project | Project | Project |
Week 10 - Python (programming language)#
| Monday | Tuesday | Wednesday | Thursday | Friday | |
|---|---|---|---|---|---|
| Morning | Variables | Loops, Functions | Dictionaries, Sets and Tuples | Variable Scope, Intermediate Variables | Intermediate Python, Scripting |
| Afternoon | Conditionals, List | Advanced Function Arguments | Classes, Inheritance | Debugging Principles and Techniques | Code Abstraction, Modules and Libraries |
Week 11 - Django (Python web framework)#
| Monday | Tuesday | Wednesday | Thursday | Friday | |
|---|---|---|---|---|---|
| Morning | Intro to SQL | Django Models | Django REST | CS or Capstone Modules | Recap |
| Afternoon | Data Modelling | Django Views | JWT | CS or Capstone Modules | Project Ideas Presentation |
Week 12 - Project 4 (Capstone)#
| Monday | Tuesday | Wednesday | Thursday | Friday | |
|---|---|---|---|---|---|
| Morning | Project | Project | Project | Project | Project |
| Afternoon | Project | Project | Project | Project | Project |
Course Daily Schedule#
| Time | Activity |
|---|---|
| 09:30 - 10:00 | Stand up Prompt |
| 10:00 - 10:30 | Warm up |
| 10:30 - 01:00 | Main Topic |
| 01:00 - 02:00 | Lunch |
| 02:00 - 05:30 | Other Topic / Lab |
| 05:30 - 06:00 | Homework |
Projects#
| Name | Project 1 | Project 2 | Project 3 | Project 4 |
|---|
Licensing#
All content is licensed under a CC-BY-NC-SA 4.0 license. All software code is licensed under GNU GPLv3. For commercial use or alternative licensing, please contact legal@ga.co.