Software Development

https://en.wikipedia.org/wiki/Software_development

https://en.wikipedia.org/wiki/Software_development_process

https://en.wikipedia.org/wiki/Category:Software_design_patterns

https://en.wikipedia.org/wiki/Software_engineering

Computer Science

https://en.wikipedia.org/wiki/Computer_science#Applied_computer_science

https://en.wikipedia.org/wiki/Outline_of_computer_science

https://en.wikipedia.org/wiki/Category:Computer_science

Topics:

Computer Science Curricula

Curricula
Criteria
Rubric

Computer Science criteria, guidelines, and curricula:

  • ACM Computer Science Curricula 2013: Curriculum Guidelines for Undergraduate Degree Programs in Computer Science (December 20, 2013)

    https://www.acm.org/education/CS2013-final-report.pdf

    • AL – Algorithms and Complexity (p.55)
    • AR – Architecture and Organization (p.62)
    • CN – Computational Science (p.68)
    • DS – Discrete Structures (p.76)
    • GV – Graphics and Visualization (p.82)
    • HCI – Human-Computer Interaction (p.89)
    • IAS – Information Assurance and Security (p.97)
    • IM – Information Management (p.112)
    • IS – Intelligent Systems (p.121)
    • NC – Networking and Communication (p.130)
    • OS – Operating Systems (p.135)
    • PBD – Platform-Based Development (p.142)
    • PL – Programming Languages (p.155)
    • SDF – Software Development Fundamentals (p.167)
    • SE – Software Engineering (p.172)
    • SF – Systems Fundamentals (p.186)
    • SP – Social Issues and Professional Practice (p.192)

  • ACM Computer Science Curriculum 2008: An Interim Revision of CS 2001

    http://www.acm.org/education/curricula/ComputerScience2008.pdf

  • Programmer Competency Matrix

    http://sijinjoseph.com/programmer-competency-matrix/

    https://competency-checklist.appspot.com/

    https://github.com/hltbra/programmer-competency-checklist

    • computer science
      • data structures
      • algorithms
      • systems programming
    • software engineering
      • source code and version control
      • build automation
      • automated testing
    • programming
      • problem decomposition
      • systems decomposition
      • communication
      • code organization within a file
      • source tree organization
      • code readability
      • defensive coding
      • error handling
      • IDE
      • API
      • frameworks
      • requirements
      • scripting
      • database
    • knowledge
      • tool knowledge
      • languages exposed to
      • codebase knowledge
      • knowledge of upcoming technologies
      • platform internals
      • books
      • blogs
    • experience
      • languages with professional experience
      • platforms with professional experience
      • years of professional experience
      • domain knowledge

Project Management

Wikipedia: https://en.wikipedia.org/wiki/Project_management

Everyone Codes

Q. Everyone? A. Everyone but

Agile

Wikipedia: https://en.wikipedia.org/wiki/Agile_software_development

Stand Up Meeting

Wikipedia: https://en.wikipedia.org/wiki/Stand-up_meeting

Note

Meeting participants need not actually stand; as in a Digital Stand Up Meeting.

Three Questions
Wikipedia: https://en.wikipedia.org/wiki/Stand-up_meeting#Three_Questions
  1. What did I accomplish yesterday?
  2. What will I do today?
  3. What obstacles are impeding my progress?
Digital Stand Up Meeting

A Digital Stand Up Meeting is a meeting conducted through digital means of communication; rather than through traditional in-person communication.

Pros:

  • Links: Realtime collaborative documents (live docs), team chat logs, and issue/ticket comment threads have URIs, are easier to remember, and more to the point.
  • Easier to prepare for
  • More time to read, think, and respond
  • More comfortable
  • Easier to get up to date with

Cons:

  • It’s not everyone in the same room
  • “Shouldn’t this all be in the issue tracker?”
    • Mailing Lists, Forums, SIOC <- Links to source, docs, issues
    • Bugs, User Stories -> Issue Tracker
    • Daily Stand Up Meeting log / minutes ->

Digital Stand Up Meeting Process Checklist:

  • [ ] Create a collaboratively edited document (“live doc”, “doc”)

    • Realtime collaborative editors: Etherpad Lite, Google Docs

    • An example of Three Questions for stand up meetings (in Markdown, with URIs, for GitHub, BitBucket):

      # team-name/project-name Daily Stand Up Log

## 2015-01-01

### @username1
1. yesterday: #1, #2, http://
2. today: #2
3. obstacles: -

### @username2
1. yesterday: #3, #2, https://
2. today: #2
3. obstacles: -

  • [ ] Share the link to the live doc with the team

    • [ ] Email, Text Chat
    • [ ] Meeting/event invitations (iCal)
  • [ ] Chat (Text, Voice, Video)
    • Text
      • Slack
      • Mattermost
      • HipChat
      • Gitter
      • XMPP
      • IRC
    • Voice/Video (cross-platform): Google Hangouts, Skype, Cisco WebEx, WebRTC
      • Live streaming
        • YouTube
        • Twitter
        • Facebook

See: Team Building (The same page, Collaborative Software)

Unified Process

Wikipedia: https://en.wikipedia.org/wiki/Unified_Process
EPFWiki: http://epf.eclipse.org/wikis/openup/
  • “Rational Unified Process” (RUP)
  • OpenUP is an Open Source Unified Process

Requirements Management

Wikipedia: https://en.wikipedia.org/wiki/Requirements_management

Agile Modeling

Wikipedia: https://en.wikipedia.org/wiki/Agile_modeling
Docs:

See also:

Behavior Driven Development

Wikipedia: https://en.wikipedia.org/wiki/Behavior-driven_development
Given-When-Then
Wikipedia: https://en.wikipedia.org/wiki/Given-When-Then
  • Given (context)
  • When (event)
  • Then (expect, should, assert)
Given When Then Given When Then
Hoare Logic precondition P command C postcondition Q
Terms Input: State, Context (,RDF), Database Input: Parametrized Event, Message Output Conditions, Rules, Expressions, Assertions, Expectations
HTTP 1.1 app state (etc, fs, db) request (URI(URN|URL))?attrs=values response ({json: True})
Channels app state (etc, fs, db) event(message_in) conditions(message_out)
Vows test suite, @Vows.Batch, Vows.Context, topic() vow – def should_quack(self, topic): vow – `` expect(topic.quack()).to_equal(value)``

User Story

Wikipedia: https://en.wikipedia.org/wiki/User_story

A user story is a couple of simple sentences expressing desired competencies, features, or behaviors of a system.

Ideally, user stories can simply be transformed to e.g. TDD and BDD tests.

Example user stories:

  • “[role] can [action [objects]] [in order to / so that [...]]”
  • “Users can login and post Things with a description and a url”
  • “Users can login and post Things with a description and a url in order to have something with a URL to share”
  • “Users can share shared Things with a URL”
Card, Conversation, Confirmation
Wikipedia: https://en.wikipedia.org/wiki/User_story#History
Docs: http://ronjeffries.com/xprog/articles/expcardconversationconfirmation/

The Three C’s of User Story Requirements Modeling are Card, Conversation, and Confirmation.

  • Card
    • Issue name and description (or description__markdown_github).
    • Codelabels
  • Conversation
    • Issue comment thread or threads (with full URLs)
    • Pull Request comment thread or threads (with full URLs)
    • Codelabels
  • Confirmation
    • Issue status: open / closed
    • Issue Labels: { duplicate, wontftix }
    • Issue labels: { ready, in progress, } TODO
      • https://waffle.io/ uses ready, in progress labels to build an interactive Kanban board with columns from github issue labels.

Use Case

Wikipedia: https://en.wikipedia.org/wiki/Use_case

A use case describes actions, actors, and goals.

  • UML defines a formal model for Use cases and use case diagrams.
    • Use case diagrams may involve stick figures as symbols for actors.
  • In practice, the use case is a more formal requirement model than the User Story.
    • In terms of process workflow, a Use Cases could be derived from zero or more User Stories.
    • There are many domain modeling tools for e.g. UML; each with various levels of support for round-trip between modeling tool and e.g. code that you add after transforming to which is sometimes referred to as stub code.

Requirements Traceability

Wikipedia: https://en.wikipedia.org/wiki/Requirements_traceability

  • URLs

    • issue numbers (GitHub, BitBucket, ):

      • ad-hoc (the numbers probably won’t be sequential)
      • issue #1: Mission, Project list
      • issue #2: Project
      • issue #3: Goal
      • issue #4: an Objective for goal #3
        • With a fixed, preallocated numbering system, this would be e.g. project:3.1; however, issue ticket numbers are sequential by order of creation
          • the numbers would then appear somewhat arbitrary
          • there would be no need to renumber things

    • #perma-link document URL fragments

      • #mission-statement

      • #project-<name> / #p-<name>

      • #goal-<name> / #g-<name>

      • #objective-<name> / #o-<name>

      • implementations:

        • sphinx restructuredtext (with Ctrl-F’able explicit links):

          .. _mission:

#########
Mission
#########

.. _project-name:

***************
Project: Name
***************


.. _goal-name:

Goal: Name
===============


.. _objective-name:

Objective: Name
----------------

* [ ] Task: Name

.. _task-name:

Task: Name
^^^^^^^^^^^^

        • markdown:

          #
Mission:

## Project: Name

## Goal: Name

### Objective: Name

* [ ] Task: Name

#### Task: Name

  • Codelabels:

    MISSION
GOAL
OBJECTIVE

IDEA: idea

STRY: user story -> TST, ENH, BUG, RLS ; -> CASE ; + REQ
CASE: use case   -> TST, ENH, BUG, RLS ; -> STRY ; + REQ
REQ: requirement -> TST                          ; + REQ

SPRINT: sprint == { REQ, CASE, STRY, TST, BUG, ENH, DOC, TST, RLS }

TASK

Checkboxes

Wikipedia: https://en.wikipedia.org/wiki/Checkbox

Checkboxes can be expressed in plaintext with square brackets surrounding a space character, a state character, or a completion character (e.g. lowercase x or uppercase X).

A Markdown list of items with checkboxes and Codelabels:

- [x] ENH: one **bold**
- [ ] ENH: two *italic*
  - [x] TST: two.one
  - [ ] DOC: two.two \* two
- [ ] RLS: ``three`` (also `three`)

A ReStructuredText list of items with checkboxes and Codelabels:

* [x] ENH: one **bold**
* [ ] ENH: two *italic*

  * [x] TST: two.one
  * [ ] DOC: two.two \* two

* [ ] RLS: ``three``

TODO

* [ ] Unchecked # github
* [x] Checked   # github
* [X] Checked   # github

- [X (YYYY-MM-DD HH:MM:SS)]
- [-]
- [o]
- [O]

- [[ ]]         # text
- [[x]]         # text
- [[o]]         # text
- \\[ ]         # text
- \\[-]         # text
- \\[o]         # text
- \\[x]         # text
- \\[X]         # text

Codelabels

Codelabels (code labels) are three-letter codes with which commit messages can be prefixed.

CODE Label          color name      background  text
---- -------------- --------------- ----------  -------
BLD  build          light green     #bfe5bf     #2a332a
BUG  bug            red             #fc2929     #ffffff  (github default)
CLN  cleanup        light yellow    #fef2c0     #333026
DOC  documentation  light blue      #c7def8     #282d33
ENH  enhancement    blue            #84b6eb     #1c2733  (github default)
ETC  config
PRF  performance    deep purple     #5319e7     #ffffff
REF  refactor       dark green      #009800     #ffffff
RLS  release        dark blue       #0052cc     #ffffff
SEC  security       orange          #eb6420     #ffffff
TST  test           light purple    #d4c5f9     #2b2833
UBY  usability      light pink      #f7c6c7     #332829

DAT  data
SCH  schema

REQ  requirement
ANN  announcement

# Workflow Labels   (e.g. for waffle.io kanban board columns)
ready               dark sea green  #006b75     #ffffff
in progress         yellow          #fbca04     #332900

# GitHub Labels
duplicate           darker gray     #cccccc     #333333  (github default)
help wanted         green           #159818     #ffffff  (github default)
invalid             light gray      #e6e6e6     #333333  (github default)
question            fuschia         #cc317c     #ffffff  (github default)
wontfix             white           #ffffff     #333333  (github default)

Note: All of these color codes (except for fuschia)
are drawn from the default GitHub palette.

Note: There are 23 labels listed here.

Note

For examples with color swatches in alphabetical order, see https://github.com/westurner/dotfiles/labels

Codelabel Syntax
BLD: Makefile: default -> test
BUG: setup.py: fix console_entrypoints
CLN: .gitignore: add "'pattern'
DOC: index.rst: add readme.rst to TOC
ENH: app/app.py: print 'Hello World' (closes #1)
PRF,REF: app/app.py: factor out of a loop
REF: app/app.py: extract into class and @staticmethods
RLS: setup.py,VERSION.txt,app/app.py: app v0.0.1
SEC: app/app.py: pass lists/tuples to sarge.run (#2)
TST: Extend tests for #1
UBY: app/app.py: update _('strings')

DAT: data/filename.csvw.jsonld: added, updated
SCH: data/context.jsonld: added, updated
  • COMMA,DELIMITED, SET: of prefix labels
  • THR - Three-characters (code labels)

Code labels are helpful for:

Note

These code labels are adapted and extended from a previous version of the pandas/CONTRIBUTING.md

Refactoring

Wikipedia: https://en.wikipedia.org/wiki/Code_refactoring

Continuous Delivery

Wikipedia: https://en.wikipedia.org/wiki/Continuous_delivery

Revision Control

Wikipedia: https://en.wikipedia.org/wiki/Revision_control
Docs: Tools > Version Control Systems

Revision control, or version control, is a change management strategy for a project repository.

  • There is a better way than emailing which version of what the attachment was named before the re: subject line changed.
    • folders
    • file versions
    • usernames, change logs, signatures
  • A Revision Control System (RCS) or Version Control System (VCS) is a software solution for handling change management with one or more project repositories.
  • Centralized Revision Control Systems (RCS, VCS):
    • CVS, SVN
  • Distributed Revision Control Systems (DVCS):
    • Git, Mercurial, Bazaar

Distributed Version Control

Wikipedia: https://en.wikipedia.org/wiki/Distributed_revision_control

Distributed Revision Control Systems (“DVCS”) are version control systems designed for backup redundancy and collaboration.

Bisection

Wikipedia: https://en.wikipedia.org/wiki/Bisection_(software_engineering)

Bisection is a method for determining which change causes a fault (or a specific test to change from passing to failing or vice-versa).

Many bisection algorithms take a start and end (“between here and here”) and do a binary search (“this half or that half”); checking out each revision and running a script that should return 0 for OK, or non-zero.

Code bisection with git:

Code bisection with mercurial:

Branching & Merging

Wikipedia: https://en.wikipedia.org/wiki/Branching_(revision_control)
Wikipedia: https://en.wikipedia.org/wiki/Merge_(revision_control)

Test Automation

Wikipedia: https://en.wikipedia.org/wiki/Test_automation

Continuous Integration

Wikipedia: https://en.wikipedia.org/wiki/Continuous_integration

Continuous Deployment

Wikipedia: https://en.wikipedia.org/wiki/Continuous_deployment
  • Configuration Management
  • Virtualization
  • #DevOps