Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
7. Securing you application: This one is probably more about configuration than anything, depending on all the security features your frameworks and servers have. Explain e.g. the OWASP Top 10 and mention how the particular project would be secured from them or why a security risk is already mitigated. I always missed talks about making your software secure at university.
Homework: Test your project for $risk and explain why it is or is not affected.
8. Performance and optimization. Show how to measure the performance of all the applications and how to identify bottlenecks. Also talk about bundle size optimization and things like minfying, uglifying or duplicate code elimination. Also talk about how you can minimize your footprint by selecting the right libraries in the first place. Discuss when native code is absolutely crucial and when not. Maybe use native modules you call from your platform agnostic mobile framework as an demonstrative example.
(TBC) -
Homework for 8: (in the case of react-native) Write a native module of your choice (Android or iOS) of a performance critical task and use it in your app.
9. Wrap-up, assignment of small projects the students can make out of their existing ones. Maybe help them already start their projects for the rest of the lesson.
Homework: Do the assigned project.
(It may be better to have two weeks between the ninth and tenth lesson to ensure that the students get enough time for it. Even better would be 3 - 4 weeks with an intermediate lesson to help fix some bad problems).
10. Presentation of projects, final discussion and feedback for the teacher. -
Afterwork for the teacher:
- Read all the feedback and think of whether it makes sense to adapt the class to it. Give yourself a reason why or why not. Then adapt it for the next students. If there is feedback to your presentation skills or the like, also take it seriously. One thing that was never taken too seriously at my university and that is kinda sad. Because some teachers were very cool guys.
- Identify typical technical problems and write them down (you will not remember them all after half a year), including their solutions or workarounds. Emphasize on parts where students typically struggle more. Strip out things which take too much time and find alternatives.
- If the teacher is working in the industry like me, consider offering the best students a job application at your company (or other contacts you know at least have a fitting tech stack).
Sorry for the long post. Had to write that thing finally down (it was in my head for a couple of months now).
To me this is one of the most interesting topics. I always dream about creating the perfect programming class (not aimed at absolute beginners though, in the end there should be some usable software artifact), because I had to teach myself at least half of the skills I need everyday.
The goal of the class, which has at least to be a semester long, is to be able to create industry-ready software projects with a distributed architecture (i.e. client-server).
The important thing is to have a central theme over the whole class. Which means you should go through the software lifecycle at least once.
Let's say the class consists of 10 Units à ~3 hours (with breaks ofc) and takes place once a week, because that is the absolute minimum time to enable the students to do their homework.
1. Project setup, explanation of the whole toolchain. Init repositories, create SSH keys for github/bitbucket, git crash course (provide a cheat sheet).
Create a hello world web app with $framework. Run the web server, let the students poke around with it. Let them push their projects to their repositories.
The remainder of the lesson is for Q&A, technical problems and so on.
Homework: Read the docs of $framework. Do some commits, just alter the HTML & CSS a bit, give them your personal touch.
For the homework, provide a $chat channel/forum/mailing list or whatever for questions where not only the the teacher should help, but also the students help each other.
2. Setup of CI/Build automation. This is one of the hardest parts for the teacher/uni because the university must provide the necessary hardware for it, which costs money. But the students faces when they see that a push to master automatically triggers a build and deploys it to the right place where they can reach it from the web is priceless.
This is one recurring point over the whole course, as there will be more software artifacts beside the web app, which need to be added to the build process. I do not want to go deeper here, whether you use Jenkins, or Travis or whatev and Ansible or Puppet or whatev for automation. You probably have some docker container set up for this, because this is a very tedious task for initial setup, probably way out of proportion. But in the end there needs to be a running web service for every student which they can reach over a personal URL. Depending on the students interest on the topic it may be also better to setup this already before the first class starts and only introduce them to all the concepts in a theory block and do some more coding in the second half.
Homework: Use $framework to extend your web app. Make it a bit more user interactive with buttons, forms or the like. As we still have no backend here, you can output to alert or something.
3. Create a minimal backend with $backendFramework. Only to have something which speaks with the frontend so you can create API calls going back and forth. Also create a DB, relational or not. Discuss DB schema/model and answer student questions.
Homework: Create a form which gets transformed into JSON and sent to the backend, backend stores the user information in the DB and should also provide a query to view the entry.
4. Introduce mobile apps. As it would probably too much to introduce them both to iOS and Android, something like React Native (or whatever the most popular platform-agnostic framework is then) may come in handy. Do the same as with the minimal web app and add the build artifacts to CI. Also talk about getting software to the app/play store (a common question) and signing apps.
Homework: Use the view API call from the backend to show the data on the mobile. Play around with the mobile project to display it in a nice way.
5. Introduction to refactoring (yes, really), if we are really talking about JS here, mention things like typescript, flow, elm, reason and everything with types which compiles to JS. Types make it so much easier to refactor growing codebases and imho everybody should use it.
Flowtype would make it probably easier to get gradually introduced in the already existing codebase (and it plays nice with react native) but I want to be abstract here, so that is just a suggestion (and 100% typed languages such as ELM or Reason have so much nicer errors).
Also discuss other helpful tools like linters, formatters.
Homework: Introduce types to all your API calls and some important functions.
6. Introduction to (unit) tests. Similar as above.
Homework: Write a unit test for your form.
(TBC)
undefined
wk92