Skip to content
View csasbach's full-sized avatar
  • HCSS
  • Fremont, Nebraska

Block or report csasbach

Block user

Prevent this user from interacting with your repositories and sending you notifications. Learn more about blocking users.

You must be logged in to block users.

Please don't include any personal information such as legal names or email addresses. Maximum 250 characters, markdown supported. This note will be visible to only you.
Report abuse

Contact GitHub support about this user’s behavior. Learn more about reporting abuse.

Report abuse

Pinned Loading

  1. adventures-in-problem-solving adventures-in-problem-solving Public

    Using a GitHub repo as a Software Engineering blog? Why not?

  2. design_principles.md design_principles.md
    1
    # Design Principles
    2
    
                  
    3
    The resources below cover a lot of ground with regard to designing code that is easy to test and maintain in the first place, as well as how to refactor existing code to accomplish the same.  
    4
    
                  
    5
    Good code design is a critical ingredient of a delivery pipeline with fast feedback loops. Fast feedback loops in turn enable us as developers to deliver stable software in a truly (not just in name) Agile team.  When it is quick and easy to research, design, experiment, test, deliver, and repeat; development is exciting and rewarding and customers get the features they want and the fixes they need without delay.
  3. testing.md testing.md
    1
    # Testing
    2
    
                  
    3
    # Why?
    4
    
                  
    5
    - In order to test your code, your code must first be testable.  If you write testable code from the beginning, you will be writing well-designed code or at least code that is more well designed than you would have otherwise written.  If you are adding tests to an existing code base, you will be led by the hand into precisely the refactoring that code base needs.  Testable code is, by virtue, loosely coupled code.  Nearly all of the important design principles are geared towards keeping your code loosely coupled.  If you only focused on making your tests easy to write and paid no attention to design principles at all, you will still have accomplished a pretty good design nearly by accident.  The more loosely coupled your code is, the easier it is to change.  The first virtue of good code is changeability, usability comes second.  Code that is usable today but cannot be easily be changed may not be usable tomorrow and will only be made usable again with significant effort.  Code that is easily changeable can always be changed into code that is usable with no more effort than what that task legitimately requires.  **To use the technical debt metaphor: Tested code is an investment, untested code is a loan.  If you are always taking out loans and never making investments then you will end up working very hard and long hours to stay solvent.**
  4. dart_flutter.md dart_flutter.md
    1
    # Dart / Flutter
    2
    
                  
    3
    # Why?
    4
    
                  
    5
    The fundamental reason we use Dart is simply that it is the language used to develop for Flutter.  The reason we use Flutter is that it is a framework developed and supported by Google for 
  5. SpecTestExamples SpecTestExamples Public

    Some basic examples of spec and unit tests using .Net Core 3.1, React, Specflow, Selenium, and Nunit

    TypeScript

  6. MonogameSandbox MonogameSandbox Public

    A sandbox for boilerplate Monogame code and testing Monogame proofs of concept.

    C#