Skip to content

Commit ecee08a

Browse files
EveStarLITEEveStarLITE
committed
Complete Admin
1 parent 5bb7e87 commit ecee08a

File tree

9 files changed

+575
-188
lines changed

9 files changed

+575
-188
lines changed

‎admin/goals.html

Lines changed: 72 additions & 36 deletions
Original file line numberDiff line numberDiff line change
@@ -37,45 +37,81 @@
3737
<div class="top">
3838
</div>
3939
<div class="bottom">
40+
<h1>Goals
41+
</h1>
42+
</div>
43+
<div class="Info_Wrapper_2">
44+
<div class="Info_Main">
45+
<p>
46+
The following is a list of goals the software team tries to meet each year.
47+
They inform decisions regarding our curriculum design and operating procedures.
48+
</p>
49+
<ul>
50+
<li>Produce an effective product</li>
51+
<li>Employ industry best practices</li>
52+
<li>Expand our knowledge and capabilities</li>
53+
<li>Involve less experienced team members</li>
54+
<li>Find tasks requiring less experience</li>
55+
<li>Create an autonomous software team / encourage learning</li>
56+
<li>Provide access to resources for motivated students</li>
57+
</ul>
58+
</div>
59+
<div class="Info_Main" id="Lone">
60+
<h2>Curriculum Goals</h2>
61+
<b><p>Teach incoming members enough C++ to be useful</p></b>
62+
<p>Integrate modern C++ development paradigms, tools, and practices</p>
63+
<b><p>Teach a set of skills motivated by industry best practices</p></b>
64+
<p>By industry best practices, we don't mean extremely conservative, waterfall model practices.
65+
We're more focused on breaking down and solving problems using industry standard tools.
66+
We emphasize reliability, but reliability and innovation aren't mutually exclusive.</p>
67+
<p>Software shall meet embedded and real-time requirements</p>
68+
<b><p>Prepare students for Computer Science at university</p></b>
69+
<p>The focus should be on "Design before build". That is, developing a specification for behavior
70+
before implementing it.</p>
71+
<p>Teach common development practices like Git and code review.</p>
72+
<b><p>Teach an introduction to control theory for those interested</p></b>
73+
<p>This is also needed for a reliable / maximally efficient robot and includes state machines,
74+
motion profiles, filters, and feedback/feedforward controllers.</p>
75+
</div>
76+
<div class="Info_Main" id="Lone">
77+
<h2>Lab design guidelines</h2>
78+
<b><p>Provide implementations for things unrelated to the lab's learning outcomes</p></b>
79+
<p>The student shouldn't get bogged down in setting up infrastructure for their solution if the lab
80+
is intended to teach something specific. For example, the state machine lab here provides a template
81+
with all the subsystems necessary to implement a robot's state machine. The comments tell the student
82+
where to insert their state machine logic, as practicing writing state
83+
machine logic is the purpose of the lab.</p>
84+
<b><p>Assuming a few prerequisites is acceptable to enable showcasing a topic's utility</p></b>
85+
<p>By showcasing advanced topics in an approachable, introductory way, students can appreciate the breadth
86+
of knowledge they can and will learn. If prerequisites are skipped, the lab should provide requisite
87+
knowledge as it is needed to understand or implement dependent concepts.</p>
88+
<b><p>Labs should encourage students to develop practical methods for solving problems</p></b>
89+
<p>Labs exist to provide hands-on experience with a topic. They should supplement the theoretical
90+
material covered in lecture to foster practical or intuitive understanding. After finishing a
91+
module and its labs, students should be capable of applying topics initially introduced in
92+
lecture.</p>
93+
<b><p>Use graphical tools to gain insight</p></b>
94+
<p>Basically, a picture or movie is worth a thousand words. The following are good examples of
95+
visualization tools.</p>
96+
<p>rltool from MATLAB aids in students' intuitive understanding of how root locus plots
97+
represent a system's response and how the pole and zero locations affect the plot.</p>
98+
<p>GRIP facilitates experimentation with complex image processing operations via an
99+
easy-to-use package.</p>
100+
<b><p>Common wisdom imparted through lectures should be motivated in labs with data</p></b>
101+
<p>For example, it is understood that mutexes are preferred over lock-free data structures unless
102+
there are scalability requirements for distributed, concurrent accesses. A lab requiring the
103+
implementation of an atomic data structure may motivate the exercise by making a mutex
104+
implementation first, then benchmarking both. (This would be a good opportunity to show the
105+
utility of and best practices for benchmarking software, by the way.)</p>
106+
<b><p>Use industry standard tools to handle auxiliary tasks</p></b>
107+
<p>Students should be able to leverage existing tools to make their jobs as
108+
software developers easier. Labs are encouraged to use tooling if it doesn't automate
109+
what the student is intended to learn through practice.</p>
110+
</div>
111+
</div>
40112
</div>
41113
<div class="Footer">
42114
<p>FRC 3512 2022</p>
43115
</div>
44116
</body>
45117
</html>
46-
47-
<!-- Goals
48-
The following is a list of goals the software team tries to meet each year. They inform decisions regarding our curriculum design and operating procedures.
49-
50-
Produce an effective product
51-
Employ industry best practices
52-
Expand our knowledge and capabilities
53-
Involve less experienced team members
54-
Find tasks requiring less experience
55-
Create an autonomous software team / encourage learning
56-
Provide access to resources for motivated students
57-
Teach incoming members enough C++ to be useful
58-
Integrate modern C++ development paradigms, tools, and practices.
59-
60-
Software shall meet embedded and real-time requirements.
61-
62-
Prepare students for Computer Science at university
63-
The focus should be on "Design before build". That is, developing a specification for behavior before implementing it. Teach common development practices like Git and code review.
64-
65-
Teach an introduction to control theory for those interested
66-
This is also needed for a reliable / maximally efficient robot and includes state machines, motion profiles, filters, and feedback/feedforward controllers.
67-
Use graphical tools to gain insight
68-
Basically, a picture or movie is worth a thousand words. The following are good examples of visualization tools.
69-
70-
Use industry standard tools to handle auxiliary tasks
71-
Students should be able to leverage existing tools to make their jobs as software developers easier. Labs are encouraged to use tooling if it doesn't automate what the student is intended to learn through practice.
72-
Lab design guidelines
73-
Provide implementations for things unrelated to the lab's learning outcomes
74-
The student shouldn't get bogged down in setting up infrastructure for their solution if the lab is intended to teach something specific. For example, the state machine lab here provides a template with all the subsystems necessary to implement a robot's state machine. The comments tell the student where to insert their state machine logic, as practicing writing state machine logic is the purpose of the lab.
75-
76-
Assuming a few prerequisites is acceptable to enable showcasing a topic's utility
77-
By showcasing advanced topics in an approachable, introductory way, students can appreciate the breadth of knowledge they can and will learn. If prerequisites are skipped, the lab should provide requisite knowledge as it is needed to understand or implement dependent concepts.
78-
79-
Labs should encourage students to develop practical methods for solving problems
80-
Labs exist to provide hands-on experience with a topic. They should supplement the theoretical material covered in lecture to foster practical or intuitive understanding. After finishing a module and its labs, students should be capable of applying topics initially introduced in lecture.
81-
-->

‎admin/index.html

Lines changed: 59 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -37,37 +37,68 @@
3737
<div class="top">
3838
</div>
3939
<div class="bottom">
40+
<h1>Administration</h1>
41+
</div>
42+
<div class="Info_Wrapper">
43+
<div class="Info_Main" id="Lone">
44+
<h2>Student Structure</h2>
45+
<p>Since 3512 was founded, the software team has enjoyed a certain level of autonomy.
46+
With that, we've been free to establish our own internal leadership structure.
47+
Rather than a typical top-down leadership structure, we operate more like a "software committee".
48+
Everyone is equal and contributes to the code base on their own volition with mentors
49+
performing quality control. There is a software lead who handles meetings and shields the
50+
members from administrative stuff, but the title doesn't imply any superiority or power over the
51+
other members.</p>
52+
<p>This works best when everyone is equal in skill level, so the mentors work hard to promote
53+
learning among rookies to raise their level of competency to that of their peers.
54+
We encourage collaboration with the other students to aid in this process.</p>
55+
</div>
56+
<div class="Info_Main" id="Lone">
57+
<h2>Role of The Mentor</h2>
58+
<p>Mentors teach rookies the basics of writing software and enough of the tools to make them productive
59+
contributors. The veterans already know how to write software, so the mentors can focus on actually
60+
teaching them software engineering. Ideally, the students contribute during the design process and
61+
are able to justify their design decisions.</p>
62+
<p>The students learn the subject matter most efficiently with mentor guidance, so the mentors are
63+
fundamentally in a partnership with the students. While the students should do the work, the mentors
64+
should use their experience to inform the students of available tools and potential pitfalls so an
65+
informed design decision is made. In this sense, the mentors are primarily in an advisory role.</p>
66+
<p>Furthermore, mentors should always provide an unbiased analysis. Transparency helps build trust,
67+
and specific solutions always have drawbacks. The mentor should be honest about them so the students
68+
develop a level-headed view of the world.</p>
69+
<p>However, the mentors also possess the long-term vision for the team and should push the boundaries of
70+
the team's accomplishments each year to achieve it. To do this, the mentors may implement tricky
71+
bits of framework code, but the students should still understand what has been written and should
72+
be walked through it step-by-step if necessary. Remember that FIRST is a mentor-based program, but
73+
t is for the students; giving them a sense of accomplishment and ownership keeps them engaged and
74+
eturning each year.</p>
75+
</div>
76+
<div class="Info_Main" id="Lone">
77+
<h2>Learning vs Reusing</h2>
78+
<p>I like to take the "add tools to the toolbox" approach with my software team. We try some random
79+
alternative to improve on previous architecture, and a student or two takes that on as an
80+
R&D project. They usually stabilize and end up on the robot by the time competition occurs.
81+
We've done probably four different approaches to state machines at this point, and our controls
82+
solutions have evolved a lot. Prefer evolution over revolution.</p>
83+
</div>
84+
</div>
85+
<div class="Links_Wrapper">
86+
<div class="Links">
87+
<a href="goals.html">Goals</a>
88+
<p>Our goals, curriculum guidelines, and learning outcomes</p>
89+
</div>
90+
<div class="Links">
91+
<a href="varsity.html">Varsity</a>
92+
<p>Contains our varsity letter requirements</p>
93+
</div>
94+
<div class="Links" id="Lone">
95+
<a href="styleGuide.html">Style Guide</a>
96+
<p>Contains the software team style guide</p>
97+
</div>
4098
</div>
4199
<div class="Footer">
42100
<p>FRC 3512 2022</p>
43101
</div>
102+
</div>
44103
</body>
45104
</html>
46-
<!--
47-
Administration
48-
Student organizational structure
49-
Since 3512 was founded, the software team has enjoyed a certain level of autonomy. With that, we've been free to establish our own internal leadership structure. Rather than a typical top-down leadership structure, we operate more like a "software committee". Everyone is equal and contributes to the code base on their own volition with mentors performing quality control. There is a software lead who handles meetings and shields the members from administrative stuff, but the title doesn't imply any superiority or power over the other members.
50-
51-
This works best when everyone is equal in skill level, so the mentors work hard to promote learning among rookies to raise their level of competency to that of their peers. We encourage collaboration with the other students to aid in this process.
52-
53-
Role of the mentor
54-
Mentors teach rookies the basics of writing software and enough of the tools to make them productive contributors. The veterans already know how to write software, so the mentors can focus on actually teaching them software engineering. Ideally, the students contribute during the design process and are able to justify their design decisions.
55-
56-
The students learn the subject matter most efficiently with mentor guidance, so the mentors are fundamentally in a partnership with the students. While the students should do the work, the mentors should use their experience to inform the students of available tools and potential pitfalls so an informed design decision is made. In this sense, the mentors are primarily in an advisory role.
57-
58-
Furthermore, mentors should always provide an unbiased analysis. Transparency helps build trust, and specific solutions always have drawbacks. The mentor should be honest about them so the students develop a level-headed view of the world.
59-
60-
However, the mentors also possess the long-term vision for the team and should push the boundaries of the team's accomplishments each year to achieve it. To do this, the mentors may implement tricky bits of framework code, but the students should still understand what has been written and should be walked through it step-by-step if necessary. Remember that FIRST is a mentor-based program, but it is for the students; giving them a sense of accomplishment and ownership keeps them engaged and returning each year.
61-
62-
Learning versus reuse
63-
I like to take the "add tools to the toolbox" approach with my software team. We try some random alternative to improve on previous architecture, and a student or two takes that on as an R&D project. They usually stabilize and end up on the robot by the time competition occurs. We've done probably four different approaches to state machines at this point, and our controls solutions have evolved a lot. Prefer evolution over revolution.
64-
65-
Goals
66-
Contains our goals, curriculum design guidelines, and learning outcomes.
67-
68-
Varsity
69-
Contains our varsity letter requirements.
70-
71-
Style guide
72-
Contains the software team style guide.
73-
-->

‎admin/styleGuide.html

Lines changed: 33 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -37,31 +37,41 @@
3737
<div class="top">
3838
</div>
3939
<div class="bottom">
40+
<h1>Style Guide</h1>
4041
</div>
42+
<div class="Info_Wrapper">
43+
<div class="Info_Main" id="Lone">
44+
<h2>Best Practices</h2>
45+
<b><p>The following requirements are used by 3512 to keep the code base consistent and readable.
46+
This aids in not only finding and fixing bugs quickly, but avoiding them altogether
47+
through well-informed design decisions.</p></b>
48+
<h2>Correctness of design and implementation</h2>
49+
<p>One shouldn't cut corners in design. More often than not, it bites us later at competition
50+
when we have to implement something new in a time crunch or fix a bug. https://en.wikipedia.org/wiki/Code_smell</p>
51+
<ul>
52+
<li>Maintainability</li>
53+
<li>Well-commented</li>
54+
<li>Readable</li>
55+
<li>Good encapsulation of functionality</li>
56+
<li>Well-chosen variable, function, and class names</li>
57+
<li>Miscellaneous rules</li>
58+
</ul>
59+
<p>Headers should be sorted into newline-delimited sections according to the Google style guide.
60+
Each section's headers should be lexographically ordered. In dir/foo.cc or dir/foo_test.cc, whose
61+
main purpose is to implement or test the stuff in dir2/foo2.h, order your includes as follows:</p>
62+
<ol>
63+
<li>dir2/foo2.h</li>
64+
<li>C system files</li>
65+
<li>C++ system files</li>
66+
<li>Other libraries' .h files</li>
67+
<li>Your project's .h files</li>
68+
</ol>
69+
<p>In addition to the practices and associated justifications presented here, see our formatting
70+
config file, uncrustify.cfg, in our robot code for specific formatting minutiae.</p>
71+
</div>
72+
</div>
4173
<div class="Footer">
4274
<p>FRC 3512 2022</p>
4375
</div>
4476
</body>
45-
</html>
46-
<!-- Style guide and best practices
47-
The following requirements are used by 3512 to keep the code base consistent and readable. This aids in not only finding and fixing bugs quickly, but avoiding them altogether through well-informed design decisions.
48-
49-
Correctness of design and implementation
50-
One shouldn't cut corners in design. More often than not, it bites us later at competition when we have to implement something new in a time crunch or fix a bug.
51-
https://en.wikipedia.org/wiki/Code_smell
52-
Maintainability
53-
Well-commented
54-
Readable
55-
Good encapsulation of functionality
56-
Well-chosen variable, function, and class names
57-
Miscellaneous rules
58-
Headers should be sorted into newline-delimited sections according to the Google style guide. Each section's headers should be lexographically ordered. In dir/foo.cc or dir/foo_test.cc, whose main purpose is to implement or test the stuff in dir2/foo2.h, order your includes as follows:
59-
60-
dir2/foo2.h
61-
C system files
62-
C++ system files
63-
Other libraries' .h files
64-
Your project's .h files
65-
In addition to the practices and associated justifications presented here, see our formatting config file, uncrustify.cfg, in our robot code for specific formatting minutiae.
66-
67-
-->
77+
</html>

0 commit comments

Comments
 (0)