diff --git a/ci/robot-software/generic/.clang-format b/.clang-format similarity index 100% rename from ci/robot-software/generic/.clang-format rename to .clang-format diff --git a/.prettierrc b/.prettierrc new file mode 100644 index 0000000..222861c --- /dev/null +++ b/.prettierrc @@ -0,0 +1,4 @@ +{ + "tabWidth": 2, + "useTabs": false +} diff --git a/ci/robot-software/generic/.styleguide b/.styleguide similarity index 100% rename from ci/robot-software/generic/.styleguide rename to .styleguide diff --git a/.styleguide-license b/.styleguide-license new file mode 100644 index 0000000..636a722 --- /dev/null +++ b/.styleguide-license @@ -0,0 +1 @@ +// Copyright (c) FRC Team 3512, Spartatroniks {year}. All Rights Reserved. diff --git a/Assets/arch.png b/Assets/arch.png new file mode 100644 index 0000000..10df8fa Binary files /dev/null and b/Assets/arch.png differ diff --git a/Assets/github.png b/Assets/github.png new file mode 100644 index 0000000..9490ffc Binary files /dev/null and b/Assets/github.png differ diff --git a/Assets/image.png b/Assets/image.png new file mode 100644 index 0000000..bdbf8d7 Binary files /dev/null and b/Assets/image.png differ diff --git a/Assets/mac.png b/Assets/mac.png new file mode 100644 index 0000000..def0977 Binary files /dev/null and b/Assets/mac.png differ diff --git a/Assets/revit.jpeg b/Assets/revit.jpeg new file mode 100644 index 0000000..6181a53 Binary files /dev/null and b/Assets/revit.jpeg differ diff --git a/Assets/ubuntu.png b/Assets/ubuntu.png new file mode 100644 index 0000000..92a2fa9 Binary files /dev/null and b/Assets/ubuntu.png differ diff --git a/Assets/windows.png b/Assets/windows.png new file mode 100644 index 0000000..d956820 Binary files /dev/null and b/Assets/windows.png differ diff --git a/Assets/youtube.png b/Assets/youtube.png new file mode 100644 index 0000000..88c0fe1 Binary files /dev/null and b/Assets/youtube.png differ diff --git a/admin/goals.html b/admin/goals.html new file mode 100644 index 0000000..04474ad --- /dev/null +++ b/admin/goals.html @@ -0,0 +1,117 @@ + + + + + + + Goals - FRC Team 3512 + + + + <> + + + +
+ +
+
+
+
+
+

Goals +

+
+
+
+

+ 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. +

+
    +
  • Produce an effective product
    • +
  • Employ industry best practices
    • +
  • Expand our knowledge and capabilities
    • +
  • Involve less experienced team members
    • +
  • Find tasks requiring less experience
    • +
  • Create an autonomous software team / encourage learning
    • +
  • Provide access to resources for motivated students
    • +
+
+
+

Curriculum Goals

+

Teach incoming members enough C++ to be useful

 +

Integrate modern C++ development paradigms, tools, and practices

+

Teach a set of skills motivated by industry best practices

 +

By industry best practices, we don't mean extremely conservative, waterfall model practices. + We're more focused on breaking down and solving problems using industry standard tools. + We emphasize reliability, but reliability and innovation aren't mutually exclusive.

+

Software shall meet embedded and real-time requirements

+

Prepare students for Computer Science at university

 +

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.

+

Teach an introduction to control theory for those interested

 +

This is also needed for a reliable / maximally efficient robot and includes state machines, + motion profiles, filters, and feedback/feedforward controllers.

+
+
+

Lab design guidelines

+

Provide implementations for things unrelated to the lab's learning outcomes

 +

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.

+

Assuming a few prerequisites is acceptable to enable showcasing a topic's utility

 +

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.

+

Labs should encourage students to develop practical methods for solving problems

 +

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.

+

Use graphical tools to gain insight

 +

Basically, a picture or movie is worth a thousand words. The following are good examples of + visualization tools.

+

rltool from MATLAB aids in students' intuitive understanding of how root locus plots + represent a system's response and how the pole and zero locations affect the plot.

+

GRIP facilitates experimentation with complex image processing operations via an + easy-to-use package.

+

Common wisdom imparted through lectures should be motivated in labs with data

 +

For example, it is understood that mutexes are preferred over lock-free data structures unless + there are scalability requirements for distributed, concurrent accesses. A lab requiring the + implementation of an atomic data structure may motivate the exercise by making a mutex + implementation first, then benchmarking both. (This would be a good opportunity to show the + utility of and best practices for benchmarking software, by the way.)

+

Use industry standard tools to handle auxiliary tasks

 +

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.

+
+
+
+ + diff --git a/admin/goals/index.html b/admin/goals/index.html deleted file mode 100644 index 905df87..0000000 --- a/admin/goals/index.html +++ /dev/null @@ -1,345 +0,0 @@ - - - - - - - Goals - FRC Team 3512 - - - - - -
-

Goals

-

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.

- -

Curriculum design guidelines

-
    -
  1. - Teach incoming members enough C++ to be useful -

    Integrate modern C++ development paradigms, tools, and practices. - The C++ language has improved a lot since 2003; we don't need to - program in the dark ages anymore.

    -
    2. -
  2. - Teach a set of skills motivated by industry best practices -

    By industry best practices, we don't mean extremely conservative, - waterfall model practices. We're more focused on breaking down and - solving problems using industry standard tools. We emphasize - reliability, but reliability and innovation aren't mutually - exclusive.

    -

    Software shall meet embedded and real-time - requirements.

    -
    3. -
  3. - Prepare students for Computer Science at university -

    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.

    -
    4. -
  4. - Teach an introduction to control theory for those interested -

    This is also needed for a reliable / maximally efficient robot and - includes state machines, motion profiles, filters, and - feedback/feedforward controllers.

    -
    5. -
-

Lab design guidelines

-
    -
  1. - Provide implementations for things unrelated to the lab's learning - outcomes -

    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.

    -
    2. -
  2. - Assuming a few prerequisites is acceptable to enable showcasing a - topic's utility -

    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.

    -
    3. -
  3. - Labs should encourage students to develop practical methods for - solving problems -

    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.

    -
    4. -
  4. - Use graphical tools to gain insight -

    Basically, a picture or movie is worth a thousand words. The - following are good examples of visualization tools.

    -
      -
    • - LiveGrapher - allows visualizing physical phenomena in real time. -
      • -
    • rltool from MATLAB aids in students' intuitive - understanding of how root locus plots represent a system's response - and how the pole and zero locations affect the plot.
      • -
    • GRIP facilitates experimentation with complex image processing - operations via an easy-to-use package.
      • -

    -
    5. -
  5. - Common wisdom imparted through lectures should be motivated in labs - with data -

    For example, it is understood that mutexes are preferred over - lock-free data structures unless there are scalability requirements for - distributed, concurrent accesses. A lab requiring the implementation of - an atomic data structure may motivate the exercise by making a mutex - implementation first, then benchmarking both. (This would be a good - opportunity to show the utility of and best practices for benchmarking - software, by the way.)

    -
    6. -
  6. - Use industry standard tools to handle auxiliary tasks -

    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.

    -

    In the previous example, Clang's thread sanitizer tool may be used - to verify correctness of the data structures' synchronization.

    -
    7. -
-

Learning outcomes

-

This is a list of topics we hope to teach software team members - throughout their membership. These may not all be accomplished in one - season. They are mainly structured in a way for which we can test - competence.

-

They include programming-specific topics such as C++, program planning - and implementation, testing and debugging, version control, and - robot-specific topics including control theory. Inter-team communication is - important for most of these.

-

C++ programming language

-

The list of topics below is largely based on part 1 of Programming: - Principles and Practice Using C++ (2nd edition).

-
    -
  1. Can build and run programs -
      -
    1. "Hello World!"
      2. -
    2. Understands the building/linking process
      3. -
    -
    2. -
  2. Can declare, initialize, and assign variables
    3. -
  3. Can perform input/output operations (std::cin, std::cout)
    4. -
  4. Understands the various commonly used types -
      -
    1. Signed and unsigned integer
      2. -
    2. float and double
      3. -
    3. std::string
      4. -
    -
    5. -
  5. Understands expressions and statements -
      -
    1. Are "i++", "3 + 2", and "int i = 0;" each an expression or - statement?
      2. -
    -
    6. -
  6. Understands implicit/explicit (casting) conventions
    7. -
  7. Understands loops/iteration (counters, range-based, iterators)
    8. -
  8. Can prototype, define, and call a function -
      -
    1. With a return type of void
      2. -
    2. With a return type of int
      3. -
    3. Can return a value which is used by the caller
      4. -
    -
    9. -
  9. Can instantiate a std::vector -
      -
    1. Add elements
      2. -
    2. Index into vector
      3. -
    -
    10. -
  10. Understand different kinds of errors and how to deal with them -
      -
    1. Compile time errors
      2. -
    2. Run time errors (extremely important to handle properly)
      3. -
    3. Exceptions thrown by standard containers, etc.
      4. -
    -
    11. -
  11. Knows when to utilize functions to deduplicate behavior and manage - complexity
    12. -
  12. Can define a class -
      -
    1. Contains member variables and functions
      2. -
    2. Contains a constructor and destructor
      3. -
    3. Uses the default constructor or "= default" for empty - implementations
      4. -
    4. Includes static member functions -
        -
      1. Understands the significance of static member functions
        2. -
      -
      5. -
    5. Creates appropriate files (ClassName.hpp, ClassName.cpp)
      6. -
    6. Defines class in header with include guards
      7. -
    7. Includes header in source file
      8. -
    8. Writes implementation in source file
      9. -
    -
    13. -
  13. Understands the uses of public, protected, and private class - membership
    14. -
-

Constructing a Program

-
    -
  1. Makes effective use of language features
    2. -
  2. Follows commonly accepted best practices
    3. -
  3. Uses proper format/style
    4. -
  4. Follows an appropriate problem solving process -
      -
    1. Understand the problem
      2. -
    2. Formulate a design
      3. -
    3. Implement the design
      4. -
    4. Test the design
      5. -
    -
    5. -
-

Testing and Debugging

-
    -
  1. Can effectively debug a program through analysis of its behavior via - a debugger or print statements
    2. -
  2. Knows how to thoroughly test one's code to ensure a quality - product
    3. -
  3. Consistently delivers well-tested software
    4. -
  4. Can use Google as an aid in solving one's problem
    5. -
-

Git

-
    -
  1. Can create a new Git repository
    2. -
  2. Can make commits in separate branches
    3. -
  3. Gerrit -
      -
    1. Can push branches to Gerrit for review and provide feedback to - others -
        -
      1. Knows how to rebase patches to push them for review
        2. -
      -
      2. -
    2. Can fetch changes from Gerrit
      3. -
    3. Can resolve conflicts when merging or rebasing
      4. -
    4. Understands the value of code review in quality assurance
      5. -
    -
    4. -
-

Robot

-
    -
  1. WPILib -
      -
    1. Can write code to control a simple two-wheeled robot -
        -
      1. Two joysticks: one for forward speed; one for turning
        2. -
      2. DifferentialDrive
        3. -
      -
      2. -
    2. Can interface with various sensors (encoders, limit switches, - gyroscopes) and perform actions based on their outputs
      3. -
    -
    2. -
  2. Embedded systems -
      -
    1. Understands the tenets of event-driven design -
        -
      1. What is an event?
        2. -
      2. How are they used in state machines?
        3. -
      -
      2. -
    2. Can design a state machine to model the desired actions of a - robot when completing a task
      3. -
    -
    3. -
  3. Control Theory -
      -
    1. Knows the dynamics of a PID controller, its limitations, and how - to tune one
      2. -
    2. Knows how to use motion profiles with feedback controllers and - the importance of feedforwards
      3. -
    3. Can apply filters when necessary to obtain better estimates of - system outputs
      4. -
    4. If students have time, they can learn feedback controller design - (more feedback controllers exist besides PID)
      5. -
    -
    4. -
-

Slack

-
    -
  1. Is a member of frc3512.slack.com
    2. -
  2. Can effectively explain one's problem when asking for help -
      -
    1. Can use Google first -
      2. -
    2. - - How to Ask Questions the Smart Way -
      3. -
    -
    3. -
-

Veterans

-

Us mentors assume you already know how to write software. Software - engineering is what we really want to teach you. If you can explain this - year's robot code and why you designed it that way versus the other - possible designs, you have succeeded and have likely earned a varsity letter. It shows you contributed in the design - phase and know the trade-offs (engineering is essentially the process of - choosing the least bad design based on some criteria and justifying that - choice). Our role as mentors is to show you what tools are available in the - C++ language so you can make an informed design decision.

-
- - diff --git a/admin/index.html b/admin/index.html index 6b24ee8..d816243 100644 --- a/admin/index.html +++ b/admin/index.html @@ -1,114 +1,104 @@ - - - - - - Administration - FRC Team 3512 - - - - - -
-

Administration

-

Goals

-

Contains our goals, curriculum design guidelines, and learning - outcomes.

-

Varsity

-

Contains our varsity letter requirements.

-

Software for non-software team - members

-

What non-software team members should know about the software team.

-

Style guide

-

Contains the software team style guide.

-

Student organizational - structure

-

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.

-

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.

-

Role of the mentor

-

Pursuant to the goals listed here, the 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.

-

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.

-

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.

-

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.

-

Learning versus reuse

-

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.

-

Why I mentor

-

Tyler Veness

-

My time as a student in FRC was basically one giant R&D experience - for me. By always being on the cutting edge of 3512, I learned a lot - along the way (successes and failures included). This exercise in - independent learning made a big impact on my future, and I want to give - students here the same opportunity.

-

Even in college, hands-on engineering projects like FRC are rare. I was - on an FSAE team at UCSC. We didn't receive any support from the engineering - department (and not for lack of trying) because they are more focused on - research. Students should make the most of their FRC experience while they - can.

-

I tell college students this often: "Don't let schooling interfere with - your education.". Seek out projects that you're interested in and learn - everything you can. It opens a lot of avenues for you later.

-
- + + + + + + Admin - FRC Team 3512 + + + + + + + +
+ +
+
+
+
+
+

Administration

+
+
+
+

Student Structure

+

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.

+

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.

+
+
+

Role of The Mentor

+

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.

+

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.

+

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.

+

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 + t is for the students; giving them a sense of accomplishment and ownership keeps them engaged and + eturning each year.

+
+
+

Learning vs Reusing

+

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.

+
+
+
+
+ Goals +

Our goals, curriculum guidelines, and learning outcomes

+
+
+ Varsity +

Contains our varsity letter requirements

+
+ +
+
+ diff --git a/admin/software-for-non-software-team-members/index.html b/admin/software-for-non-software-team-members/index.html deleted file mode 100644 index e8c85da..0000000 --- a/admin/software-for-non-software-team-members/index.html +++ /dev/null @@ -1,151 +0,0 @@ - - - - - - - Software for non-software team members - FRC Team 3512 - - - - - -
-

Software for non-software team members

-
- This is an email Tyler sent in response to a verbal request for - feedback on formal varsity letter requirements. It is being preserved - here for posterity. -
-

Hi Grace,

-

Since you mentioned on Tuesday that the team was putting together more - formal varsity letter requirements, you may be interested in the - requirements the software team has been using for the last 2+ years. They - are linked on https://frc3512.github.io/admin/. This - email was originally intended just to mention that, but the fact that - varsity letter requirements are even an issue implies there are more - systemic issues. The rest of this email elaborates on what I mean and how I - feel these issues should be addressed.

-

Varsity letter requirements

-

I'm hoping the software team's varsity letter requirements can be - incorporated into the team-wide requirements in some way. Having every - subteam document what constitutes a varsity letter in terms of specific - hard and soft skills as the software team has done would not only give new - students an idea of what to expect as a member of each subteam, but would - also help leadership develop an appreciation for the work each subteam - does. This would address frequent complaints of varsity letter - recommendations being overruled, only to have them reversed when the - subteam in question challenges it.

-

Basic knowledge

-

As an example of what I mean by appreciation of each subteam's work, the - leadership (at minimum) should be able to understand at a basic level what - each subteam mentions at opening and closing meetings. At least with - software, this requirement hasn't been met. When we mention our problems - and plans for addressing them, one of two things happens: 1) we explain - things in sufficient detail and everyone just nods, and says "oh, more big - words from the software people"; 2) we explain things with hopelessly vague - descriptions because we have to strip out all our descriptive terminology, - then we get yelled at for being too vague. I find both of these responses - disrespectful because the majority of the things we mention are basic - software concepts that all our rookies learn within their first year. I'm - not saying everyone needs to be an expert on every subteam, but they should - at least know the basics of what each subteam is capable of and how they - work. I want to avoid subteams ignoring each other's needs as well as - subteams attempting to compensate for this with well-meaning gestures but - useless gestures that are a result of their ignorance. The mechanical team - generally knows you need a router and CAN wires going from the roboRIO to - the power distribution panel and that motors require electricity across - their leads to run. Why can't the same high-level basic understanding be - afforded to software or business? An analog for this exists in the - corporate world, by the way: technical managers. They know how to manage a - team, but aren't clueless about the tasks they hand out to their - subordinates. This means they know how much work something will - realistically take, be able to determine if a subordinate is slacking off, - and be able to plan more effectively for the future.

-

What - leadership should know about the software team

-

On the software team, we've seen that if all our members know what needs - to be done, the role of a lead becomes redundant because they can - coordinate tasks amongst themselves. Being able to function without direct - oversight from a lead and work toward a common vision has made us really - effective over the years. However, a prerequisite to this is visibility - into how the subteam works at all. Pursuant to this, I would expect - non-software leadership to know the following about the software team:

-
    -
  1. We have standard operating procedures and our own set of goals. They - are detailed in https://frc3512.github.io/admin/goals/. -
    2. -
  2. Software is not magic that makes the robot move. Robots follow simple - instructions and basic logic, and you can write them yourself in English - (If this condition is true, then do that thing. Drive for 5 meters, then - turn right, etc.).
    3. -
  3. There are important factors involved in making a mechanism - controllable by software. See - 971's video on it. -
    4. -
  4. Sensors are not magic, and the average electrical student should - understand what kinds of sensors there are and what kinds of robot motion - they can measure.
    5. -
  5. We use version control. Each robot's code is stored in a - "repository". We work on features separately in what's called a "branch", - which are eventually merged into the "main" branch that always contains - working code. We do this at competition too.
    6. -
  6. We do code review for quality assurance. The site we use is - https://github.com/frc3512, - which lets us leave comments on code and push fixes to feature branches - based on that review. We always push what we've worked on to that - server at the end of each day, so no one programmer is required to be - at a build session on any given day to continue another's work. -
    7. -
  7. If anyone wants to see the robot code's progress, they can do so by - viewing the relevant repository at - https://github.com/frc3512. -
    8. -
  8. All our curriculum is online: https://frc3512.github.io/ci/. Everything the software - team learns on a yearly basis is documented there somewhere. This is how - we've managed to do consistently well with just one local mentor and one - mentor that's typically hours away. The rest of the team should consider - documenting what they know somewhere so that knowledge isn't lost every - time a student graduates. -
    9. -
  9. The software team is not an IT department. When the Driver Station - stops connecting to the robot, we're just as clueless as you are. We - usually just press power buttons at random and reboot things until it - works. In fact, your average "IT expert" is basically just following the - steps in this webcomic: https://xkcd.com/627/. As one of these - supposed "IT experts", I can confirm this is exactly what we do. -
    10. -
-

Hopefully this long-winded email helps explain some things.

-

- Tyler

-
- - diff --git a/admin/styleGuide.html b/admin/styleGuide.html new file mode 100644 index 0000000..0be5603 --- /dev/null +++ b/admin/styleGuide.html @@ -0,0 +1,78 @@ + + + + + + + Style Guide - FRC Team 3512 + + + + + + + +
+ +
+
+
+
+
+

Style Guide

+
+
+
+

Best Practices

+

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.

 +

Correctness of design and implementation

+

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. https://en.wikipedia.org/wiki/Code_smell

+
    +
  • Maintainability
    • +
  • Well-commented
    • +
  • Readable
    • +
  • Good encapsulation of functionality
    • +
  • Well-chosen variable, function, and class names
    • +
  • Miscellaneous rules
    • +
+

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:

+
    +
  1. dir2/foo2.h
    2. +
  2. C system files
    3. +
  3. C++ system files
    4. +
  4. Other libraries' .h files
    5. +
  5. Your project's .h files
    6. +
+

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.

+
+
+
+ + diff --git a/admin/styleguide/index.html b/admin/styleguide/index.html deleted file mode 100644 index ba8cdf1..0000000 --- a/admin/styleguide/index.html +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - Style guide and best practices - FRC Team 3512 - - - - - -
-

Style guide and best practices

-

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.

-

Correctness of design and - implementation

- -

Maintainability

- -

Miscellaneous rules

-

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:

- -

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.

-
- - diff --git a/admin/varsity.html b/admin/varsity.html new file mode 100644 index 0000000..e9e91e3 --- /dev/null +++ b/admin/varsity.html @@ -0,0 +1,94 @@ + + + + + + + Varsity - FRC Team 3512 + + + + + + + +
+ +
+
+
+
+
+

Varstiy

+
+
+
+

As a preface, a student isn't required to do anything. That is, they can work on as much or as + little as they want and show up when they please. With that said, one must earn their varsity letter. The + following is a list of guidelines for students on the software subteam to follow. Meeting + these guidelines signals to leadership that one has put in a varsity-level effort to learn what + is being taught and deserves recognition for it.

+

Requirments

+

Made a significant positive impact on the robot code base or other software project for the team

+

Rookie: needs to make enough contributions that we can feel confident we can tell them to + implement something we typically do, and they can figure it out themselves.

+

Veteran: should be able to implement something new and exciting themselves, + but not necessarily in the best way because that's what mentors are for. Mentors + use their experience to suggest alternative implmentations and teach students to consider + the trade-offs in their design.

+

Was involved in the design of the robot code's architecture ( + requirement gathering/synthesis, state machine design, application of control theory)

+

Veteran: can explain this year's robot code and defend their design decisions

+

Veteran: has shown growth from the previous year

+

Actively found ways to make meaningful contributions

+
+
+

Basic Knowledge

+
  • Is proficient in C++
    • +
  • Can use version control effectively
    • +
  • Exercises clean coding practices
    • +
  • See our learning outcomes for more
    • +
  • Can work productively with the other members
    • +
  • Can provide meaningful feedback for other members' code
    • +
  • Maturity
    • +
  • Handles design disagreements in a professional manner ( + contrast this with yelling at each other, which has happened before on the software team)
    • +
  • Considers other people's opinions, viewpoints, and advice before making a decision
    • +
  • Evaluates ideas based on their merits rather than emotional attachment
    • +
  • Treats mentors and other team members with respect
    • +

    Other:

    +
  • Be on Slack and engage in discussion
    • +
  • Easy to work with
    • +
  • Time commitment
    • +
  • Software strongly encourages working outside of build sessions
    • +
  • Step up and take on tasks
    • +
  • Follow through on tasks undertaken and assigned
    • +

    Keep in mind not every software team member will have the opportunity to write a + piece of production software from scratch. Maintenance programmers are important too. + The Ten Commandments of Egoless Programming provide a summary of what is expected in collaborative + work environments (not just software engineering).

    +
    +
    + + diff --git a/admin/varsity/index.html b/admin/varsity/index.html deleted file mode 100644 index 8efaf99..0000000 --- a/admin/varsity/index.html +++ /dev/null @@ -1,124 +0,0 @@ - - - - - - - Varsity letter requirements - FRC Team 3512 - - - - - -
    -

    Varsity letter requirements

    -

    As a preface, a student isn't required to do anything. That is, they can - work on as much or as little as they want and show up when they please. - With that said, one must earn their varsity letter. The following is - a list of guidelines for students on the software subteam to follow. - Meeting these guidelines signals to leadership that one has put in a - varsity-level effort to learn what is being taught and deserves recognition - for it.

    -
      -
    1. Made a significant positive impact on the robot code base or other - software project for the team -
        -
      1. Rookie: needs to make enough contributions that we can - feel confident we can tell them to implement something we typically - do, and they can figure it out themselves.
        2. -
      2. Veteran: should be able to implement something new and - exciting themselves, but not necessarily in the best way because - that's what mentors are for. Mentors use their experience to suggest - alternative implmentations and teach students to consider the - trade-offs in their design.
        3. -
      -
      2. -
    2. Was involved in the design of the robot code's architecture - (requirement gathering/synthesis, state machine design, application of - control theory) -
        -
      1. Veteran: can explain this year's robot code and defend - their design decisions
        2. -
      -
      3. -
    3. Veteran: has shown growth from the previous year
      4. -
    4. Actively found ways to make meaningful contributions
      5. -
    5. Basic knowledge -
        -
      1. Is proficient in C++ -
        2. -
      2. Can use version control effectively
        3. -
      3. Exercises clean coding practices -
        4. -
      4. See our learning - outcomes for more -
        5. -
      -
      6. -
    6. Can work productively with the other members
      7. -
    7. Can provide meaningful feedback for other members' code
      8. -
    8. Maturity -
        -
      1. Handles design disagreements in a professional manner (contrast - this with yelling at each other, which has happened before on the - software team)
        2. -
      2. Considers other people's opinions, viewpoints, and advice before - making a decision -
          -
        1. Evaluates ideas based on their merits rather than emotional - attachment
          2. -
        -
        3. -
      3. Treats mentors and other team members with respect
        4. -
      4. Easy to work with
        5. -
      -
      9. -
    9. Time commitment -
        -
      1. Software strongly encourages working outside of build sessions, - but that is not required -
          -
        1. Be on Slack and engage in discussion
          2. -
        2. Step up and take on tasks
          3. -
        3. Follow through on tasks undertaken and assigned
          4. -
        -
        2. -
      -
      10. -
    -

    Keep in mind not every software team member will have the opportunity to - write a piece of production software from scratch. Maintenance - programmers are important too. - The Ten Commandments of Egoless Programming provide a summary of what - is expected in collaborative work environments (not just software - engineering).

    -
    - - diff --git a/archives/angelscript/docs/_global_property_8h_source.html b/archives/angelscript/docs/_global_property_8h_source.html index 164c292..8dbf32c 100644 --- a/archives/angelscript/docs/_global_property_8h_source.html +++ b/archives/angelscript/docs/_global_property_8h_source.html @@ -303,7 +303,7 @@ Sets the members of a GlobalProperty.
    - Definition: GlobalProperty.cpp:17 +

    Definition:

    GlobalProperty.cpp:17
    - Definition: GlobalProperty.cpp:3 +

    Definition:

    GlobalProperty.cpp:3
    - Definition: GlobalProperty.cpp:30 +

    Definition:

    GlobalProperty.cpp:30
    - Definition: GlobalProperty.cpp:69 +

    Definition:

    GlobalProperty.cpp:69
    @@ -362,7 +362,7 @@ GlobalProperty class.
    - Definition: GlobalProperty.h:13 +

    Definition:

    GlobalProperty.h:13
    - Definition: GlobalProperty.cpp:10 +

    Definition:

    GlobalProperty.cpp:10
    - Definition: GlobalProperty.cpp:87 +

    Definition:

    GlobalProperty.cpp:87
    - Definition: GlobalProperty.cpp:56 +

    Definition:

    GlobalProperty.cpp:56
    - Definition: GlobalProperty.cpp:81 +

    Definition:

    GlobalProperty.cpp:81
    - Definition: GlobalProperty.cpp:75 +

    Definition:

    GlobalProperty.cpp:75
    @@ -454,7 +454,7 @@