├── LICENCE.md ├── resources ├── other │ ├── regexp.html.md │ ├── giving-and-receiving-feedback.html.md │ ├── documentation.html.md │ ├── handling-incidents.html.md │ ├── security.html.md │ ├── inspiration-and-general-resources.html.md │ └── code-reviews.html.md ├── datastores │ ├── sql.html.md │ └── elasticsearch.html.md ├── frameworks │ ├── nodejs.html.md │ └── rails.html.md ├── systems │ ├── reliability-engineering.html.md │ └── networking.html.md ├── delivery │ ├── designing-apis.html.md │ ├── user-story-template.html.md │ └── structuring-code.html.md ├── index.html.md ├── languages │ ├── puppet.html.md │ ├── java.html.md │ ├── python.html.md │ ├── ruby.html.md │ ├── css.html.md │ └── javascript.html.md └── tools │ ├── editors.html.md │ └── the-unix-shell.html.md ├── career-path ├── technical-skills │ ├── assessing-performance.html.md │ ├── selecting-technology.html.md │ ├── building-secure-services.html.md │ ├── designing-technical-features.html.md │ ├── diagnosing-and-debugging-issues.html.md │ ├── designing-and-testing-for-accessibility.html.md │ ├── systematic-approach-solving-problems.html.md │ ├── technical-debt-tradeoffs.html.md │ ├── designing-for-reliability.html.md │ ├── version-control.html.md │ └── using-appropriate-testing-to-ensure-software-quality.html.md ├── working-practices │ ├── working-independently.html.md │ ├── prioritising-your-time.html.md │ ├── working-as-a-multi-disciplinary-team.html.md │ ├── owning-your-development-plan.html.md │ ├── building-software-as-a-team.html.md │ ├── knowing-when-to-ask-for-help.html.md │ └── planning-and-estimating.html.md ├── leading-and-communicating │ ├── writing-and-speaking.html.md │ ├── awareness-of-wider-community.html.md │ ├── wider-context-of-work.html.md │ ├── pair-programming.html.md │ ├── sharing-knowledge-with-others.html.md │ └── leading-on-stories.html.md └── index.html.md ├── contributing ├── template.html.md └── index.html.md ├── README.md └── ways-of-learning ├── index.html.md └── running-petal.md /LICENCE.md: -------------------------------------------------------------------------------- 1 | # Licence 2 | 3 | The content of this repository is covered by the [Open Government Licence](http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/). 4 | -------------------------------------------------------------------------------- /resources/other/regexp.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | last_reviewed_on: 2018-11-16 3 | review_in: 1 year 4 | title: Regular Expressions 5 | --- 6 | # Regular Expressions 7 | 8 | * [Regex Crossword puzzles](https://regexcrossword.com) 9 | -------------------------------------------------------------------------------- /resources/datastores/sql.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 20 3 | last_reviewed_on: 2018-11-16 4 | review_in: 1 year 5 | --- 6 | 7 | # SQL 8 | 9 | - interactive sql exercises [https://pgexercises.com/questions/basic/selectall.html](https://nodeschool.io/) 10 | - [https://selectstarsql.com/](https://selectstarsql.com/) 11 | -------------------------------------------------------------------------------- /career-path/technical-skills/assessing-performance.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 90 3 | last_reviewed_on: 2018-11-16 4 | review_in: 1 year 5 | title: Assessing performance 6 | --- 7 | 8 | # Assessing performance 9 | 10 | ## Your role as developer/webops 11 | 12 | ### Junior level 13 | 14 | ### Mid level 15 | 16 | ### Senior level 17 | 18 | ## Related guides 19 | 20 | ## External resources 21 | -------------------------------------------------------------------------------- /career-path/technical-skills/selecting-technology.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 110 3 | last_reviewed_on: 2018-11-16 4 | review_in: 1 month 5 | title: Selecting technology 6 | --- 7 | 8 | # Selecting technology 9 | 10 | ## Your role as developer/webops 11 | 12 | ### Junior level 13 | 14 | ### Mid level 15 | 16 | ### Senior level 17 | 18 | ### Related guides 19 | 20 | ### External Resources 21 | -------------------------------------------------------------------------------- /career-path/working-practices/working-independently.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 50 3 | last_reviewed_on: 2018-11-16 4 | review_in: 1 month 5 | title: Working independently 6 | --- 7 | 8 | # Working independently 9 | 10 | ## Your role as developer/webops 11 | 12 | ### Junior level 13 | 14 | ### Mid level 15 | 16 | ### Senior level 17 | 18 | ### Related guides 19 | 20 | ### External Resources 21 | -------------------------------------------------------------------------------- /career-path/technical-skills/building-secure-services.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 80 3 | last_reviewed_on: 2018-11-16 4 | review_in: 1 year 5 | title: Building secure services 6 | --- 7 | 8 | # Building secure services 9 | 10 | ## Your role as developer/webops 11 | 12 | ### Junior level 13 | 14 | ### Mid level 15 | 16 | ### Senior level 17 | 18 | ### Related guides 19 | 20 | ### External Resources 21 | -------------------------------------------------------------------------------- /career-path/working-practices/prioritising-your-time.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 40 3 | last_reviewed_on: 2018-11-16 4 | review_in: 1 month 5 | title: Prioritising your time 6 | --- 7 | 8 | # Prioritising your time 9 | 10 | 11 | ## Your role as developer/webops 12 | 13 | ### Junior level 14 | 15 | ### Mid level 16 | 17 | ### Senior level 18 | 19 | ### Related guides 20 | 21 | ### External Resources 22 | -------------------------------------------------------------------------------- /career-path/technical-skills/designing-technical-features.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 60 3 | last_reviewed_on: 2018-11-16 4 | review_in: 1 year 5 | title: Designing technical features 6 | --- 7 | 8 | # Designing technical features 9 | 10 | ## Your role as developer/webops 11 | 12 | ### Junior level 13 | 14 | ### Mid level 15 | 16 | ### Senior level 17 | 18 | ### Related guides 19 | 20 | ### External resources 21 | -------------------------------------------------------------------------------- /career-path/technical-skills/diagnosing-and-debugging-issues.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 40 3 | last_reviewed_on: 2018-11-16 4 | review_in: 1 year 5 | title: Diagnosing and debugging issues 6 | --- 7 | 8 | # Diagnosing and debugging issues 9 | 10 | ## Your role as developer/webops 11 | 12 | ### Junior level 13 | 14 | ### Mid level 15 | 16 | ### Senior level 17 | 18 | ### Related guides 19 | 20 | ### External resources 21 | -------------------------------------------------------------------------------- /career-path/technical-skills/designing-and-testing-for-accessibility.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 70 3 | last_reviewed_on: 2018-11-16 4 | review_in: 1 month 5 | title: Designing and testing for accessibility 6 | --- 7 | 8 | # Designing and testing for accessibility 9 | 10 | ## Your role as developer/webops 11 | 12 | ### Junior level 13 | 14 | ### Mid level 15 | 16 | ### Senior level 17 | 18 | ### Related guides 19 | 20 | ### External resources 21 | -------------------------------------------------------------------------------- /career-path/working-practices/working-as-a-multi-disciplinary-team.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 60 3 | last_reviewed_on: 2018-11-16 4 | review_in: 1 month 5 | title: Working in a multi disciplinary team 6 | --- 7 | 8 | # Working in a multi disciplinary team 9 | 10 | 11 | ## Your role as developer/webops 12 | 13 | ### Junior level 14 | 15 | ### Mid level 16 | 17 | ### Senior level 18 | 19 | ### Related guides 20 | 21 | ### External Resources 22 | -------------------------------------------------------------------------------- /resources/other/giving-and-receiving-feedback.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | last_reviewed_on: 2018-11-16 3 | review_in: 1 year 4 | title: Giving and receiving feedback 5 | --- 6 | # Giving and receiving feedback 7 | 8 | It's important and helps you grow and learn. 9 | 10 | ## Feedback on code 11 | 12 | Opportunities for giving and receiving feedback can take place in a [pull request](https://gds-way.cloudapps.digital/manuals/code-review-guidelines.html). 13 | -------------------------------------------------------------------------------- /career-path/leading-and-communicating/writing-and-speaking.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 30 3 | last_reviewed_on: 2018-11-16 4 | review_in: 1 month 5 | title: Writing and speaking about your work externally 6 | --- 7 | 8 | # Writing and speaking about your work externally 9 | 10 | ## Your role as developer/webops 11 | 12 | ### Junior level 13 | 14 | ### Mid level 15 | 16 | ### Senior level 17 | 18 | ## Related guides 19 | 20 | ## External resources 21 | -------------------------------------------------------------------------------- /career-path/leading-and-communicating/awareness-of-wider-community.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 50 3 | last_reviewed_on: 2018-11-16 4 | review_in: 1 year 5 | title: Showing awareness of the wider tech community 6 | --- 7 | 8 | # Showing awareness of the wider tech community 9 | 10 | ## Your role as developer/webops 11 | 12 | ### Junior level 13 | 14 | ### Mid level 15 | 16 | ### Senior level 17 | 18 | ## Related guides 19 | 20 | ## External resources 21 | -------------------------------------------------------------------------------- /career-path/technical-skills/systematic-approach-solving-problems.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 20 3 | last_reviewed_on: 2018-11-16 4 | review_in: 1 year 5 | title: Using a systematic approach to solving problems 6 | --- 7 | 8 | # Using a systematic approach to solving problems 9 | 10 | ## Your role as developer/webops 11 | 12 | ### Junior level 13 | 14 | ### Mid level 15 | 16 | ### Senior level 17 | 18 | ## Related guides 19 | 20 | ## External resources 21 | -------------------------------------------------------------------------------- /resources/frameworks/nodejs.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 10 3 | last_reviewed_on: 2018-11-16 4 | review_in: 1 year 5 | title: Node JS 6 | --- 7 | 8 | # Node JS 9 | 10 | 11 | [Comprehensive getting started guide](https://gist.github.com/joepie91/95ed77b71790442b7e61) 12 | 13 | [https://nodeschool.io/](https://nodeschool.io/) 14 | 15 | [GOV.UK Pay Node.js Pluralsight channel](https://app.pluralsight.com/channels/details/83e0745a-dc2c-45f3-bf7c-2fc5601651e7?s=1) 16 | -------------------------------------------------------------------------------- /career-path/leading-and-communicating/wider-context-of-work.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 20 3 | last_reviewed_on: 2018-11-16 4 | review_in: 1 month 5 | title: Being aware and guided by the wider context of your work 6 | --- 7 | 8 | # Being aware and guided by the wider context of your work 9 | 10 | ## Your role as developer/webops 11 | 12 | ### Junior level 13 | 14 | ### Mid level 15 | 16 | ### Senior level 17 | 18 | ## Related guides 19 | 20 | ## External resources 21 | -------------------------------------------------------------------------------- /career-path/technical-skills/technical-debt-tradeoffs.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 30 3 | last_reviewed_on: 2018-11-16 4 | review_in: 1 year 5 | title: Understanding technical debt 6 | --- 7 | 8 | # Understanding technical debt 9 | 10 | ## Your role as developer/webops 11 | 12 | ### Junior level 13 | 14 | ### Mid level 15 | 16 | ### Senior level 17 | 18 | ### Related guides 19 | 20 | ### External resources 21 | 22 | - [http://martinfowler.com/bliki/DesignStaminaHypothesis.html](http://martinfowler.com/bliki/DesignStaminaHypothesis.html) 23 | -------------------------------------------------------------------------------- /resources/systems/reliability-engineering.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | last_reviewed_on: 2018-11-16 3 | review_in: 1 year 4 | title: Reliability engineering 5 | --- 6 | # Reliability engineering 7 | 8 | ## Additional resources 9 | - [Site reliability engineering](https://landing.google.com/sre/book/) - a book from Google 10 | - [Service manual: deploying software regularly](https://www.gov.uk/service-manual/technology/deploying-software-regularly) 11 | - [Service manual: Uptime and availability: keeping your service online](https://www.gov.uk/service-manual/technology/uptime-and-availability-keeping-your-service-online) 12 | -------------------------------------------------------------------------------- /resources/other/documentation.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | last_reviewed_on: 2018-11-16 3 | review_in: 1 year 4 | title: Documentation 5 | --- 6 | # Documentation 7 | 8 | ## Resources 9 | - You can ask a tech writer for help with technical writing 10 | - [We're agile, we don't do documentation!](https://www.youtube.com/watch?v=UvI3zlv5oUA) - a talk by Birgitta Boeckeler at The Lead Developer UK 2017 11 | - [GDS technical documentation template](https://github.com/alphagov/tech-docs-template) - use it to create documentation sites 12 | 13 | ## Techniques 14 | 15 | - [Documenting architecture decisions](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions) 16 | -------------------------------------------------------------------------------- /resources/delivery/designing-apis.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 20 3 | last_reviewed_on: 2018-11-16 4 | review_in: 1 year 5 | title: Designing APIs 6 | --- 7 | 8 | # Designing APIs 9 | 10 | * [How to build an API](https://apiary.io/how-to-build-api) - useful resource from apiary 11 | * [GDS API standards](https://www.gov.uk/guidance/gds-api-technical-and-data-standards) 12 | * [White house API standards](https://github.com/WhiteHouse/api-standards) 13 | * [A collection of guidelines](http://apistylebook.com/design/guidelines/) and [patterns](http://apistylebook.com/design/topics/) from various organisations 14 | * [5 features of a great API (video)](https://youtu.be/L9oR4U2nVhQ) 15 | * [Practical hypermedia APIs in ruby (video)](https://skillsmatter.com/skillscasts/10029-practical-hypermedia-apis-in-ruby) 16 | -------------------------------------------------------------------------------- /contributing/template.html.md: -------------------------------------------------------------------------------- 1 | # Competency template 2 | 3 | ``` 4 | # [Writing a competency statement] 5 | 6 | [A short summary of the skills, behaviours and/or knowledge you are writing about at the top, if not obvious from the title.] 7 | 8 | ### Your role as [developer/webops] 9 | 10 | Why is this competency important? 11 | 12 | How does it relate to your role and responsibilities? 13 | 14 | ### Junior level 15 | 16 | [What it looks like at junior level.] 17 | 18 | ### Mid level 19 | 20 | [What it looks like at mid level.] 21 | 22 | ### Senior level 23 | 24 | [What it looks like at senior level.] 25 | 26 | ### Related guides [optional] 27 | 28 | [Links to guides on topics related to this competency] 29 | 30 | ### External Resources [optional] 31 | 32 | [Links to external resources] 33 | 34 | ``` 35 | -------------------------------------------------------------------------------- /resources/delivery/user-story-template.html.md: -------------------------------------------------------------------------------- 1 | last_reviewed_on: 2018-11-16 2 | review_in: 1 year 3 | title: User story template 4 | 5 | # User story template 6 | ``` 7 | #### User need 8 | As a 9 | I want 10 | So that 11 | 12 | #### What 13 | Explanation of what this story is 14 | 15 | #### Why 16 | Explanation of why we're doing this work 17 | 18 | #### Measurement 19 | Is there a way of measuring the effect of this work? 20 | 21 | #### Who knows about it 22 | Name the people in the team (or others teams) that know about this work 23 | 24 | #### Impact for users or other teams 25 | Is there an impact for users that we need to communicate? Is there an impact for any other teams that we need to communicate? 26 | 27 | #### Related support tickets 28 | Link to related zendesk ticket if this is a support story. 29 | 30 | #### Applications involved 31 | List the name of the applications involved in this story 32 | 33 | ``` 34 | -------------------------------------------------------------------------------- /resources/delivery/structuring-code.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 30 3 | last_reviewed_on: 2018-11-16 4 | review_in: 1 year 5 | title: Stucturing code 6 | --- 7 | 8 | # Structuring code 9 | 10 | ## Resources 11 | 12 | ### Refactoring 13 | 14 | - Martin Fowler wrote the book on refactoring (see below). His website, [refactoring.org](https://refactoring.com/catalog/) identifies and names various patterns for refactoring code. 15 | - The [Mikado Method](http://www.methodsandtools.com/archive/mikado.php) is a strategy for changing complex code in small steps 16 | 17 | ## Principles and patterns 18 | 19 | - [Don't repeat yourself](http://wiki.c2.com/?DontRepeatYourself=) 20 | - [SOLID object oriented design](http://confreaks.tv/videos/goruco2009-solid-object-oriented-design) 21 | - [Keep it simple, stupid](http://people.apache.org/~fhanik/kiss.html) 22 | - [Strangler application](https://www.martinfowler.com/bliki/StranglerApplication.html) 23 | 24 | ## Books in the GDS library 25 | - [Clean code](https://gds-library.cloudapps.digital/books/17) 26 | - [Refactoring](https://gds-library.cloudapps.digital/books/298) 27 | -------------------------------------------------------------------------------- /resources/index.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Resources 3 | weight: 50 4 | --- 5 | 6 | # External resources 7 | 8 | This is a place to share learning resources with the wider tech community. 9 | 10 | A good resource list should provide a path for learning about the topic (for example, you should separate introductary and advanced materials). 11 | 12 | Here's a template you can use to create a new list: 13 | 14 | ``` 15 | #### [Topic] 16 | 17 | [A short summary of the topic] 18 | 19 | ##### Starting out 20 | 21 | In this section, write for someone who knows nothing about the topic. If talking about technology, give a simple runnable example. This section should introduce subtopics and terminology rather than going into depth. 22 | 23 | #### [Other sections] 24 | 25 | [Examples: important concepts, best practices, related technologies] 26 | 27 | #### Reference documentation 28 | 29 | [Official reference guides] 30 | 31 | #### Learning materials 32 | 33 | This can contain any kind of resource including blog posts, videos, books and tools. Draw attention to free materials, books in the GDS library, and internal training we run at GDS. 34 | ``` 35 | -------------------------------------------------------------------------------- /resources/languages/puppet.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 40 3 | title: Puppet 4 | last_reviewed_on: 2018-11-16 5 | review_in: 1 year 6 | --- 7 | 8 | # Puppet 9 | 10 | Puppet is a domain specific language that describes the intended state of 11 | computers. The name puppet is also used to refer to the software that runs on 12 | those computers and makes configuration changes. 13 | 14 | ## Starting out 15 | 16 | ### Which version? 17 | 18 | The language does vary between versions. Most, but not all, of the basic 19 | language from older versions, such as 2.x and 3.x, will work on newer versions. 20 | 21 | As a rule, start with the latest version, unless the team in which you work or 22 | a tutorial you are following uses an older version. 23 | 24 | ### Learning materials 25 | - [Introduction to Puppet](https://davidwinter.me/introduction-to-puppet/) 26 | - [Overview of Puppet's architecture](https://puppet.com/docs/puppet/5.5/architecture.html) 27 | - For a more thorough introduction to the Puppet ecosystem see [Puppet's learning roadmaps](https://learn.puppet.com/learning-roadmaps) 28 | - The [puppet cookbook](https://www.puppetcookbook.com/) has good examples of how to do specific things using puppet. 29 | - The GDS Library has [multiple](https://gds-library.cloudapps.digital/books/98) [books](https://gds-library.cloudapps.digital/books/4) on [puppet](https://gds-library.cloudapps.digital/books/94). 30 | -------------------------------------------------------------------------------- /resources/tools/editors.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | last_reviewed_on: 2018-11-16 3 | review_in: 1 year 4 | title: Using editors 5 | --- 6 | # Using editors 7 | 8 | Using editors effectively can greatly increase the speed at which we can try new ideas and approaches. 9 | 10 | Editor choice and configuration is often very personal, however you should be considerate of the needs of people who you pair with in your choice of editor/configuration. 11 | 12 | Broadly there are three classes of editor: 13 | 14 | - IDEs - IntelliJ, RubyMine (Eclipse?) 15 | - Plain text editor - Sublime Text, Atom 16 | - Vim and Emacs 17 | 18 | Examples of ways you can improve your workflow 19 | 20 | - Automatic linting to detect problems quicker 21 | - Autocompletion 22 | - Code generation 23 | - Quicker and safer refactoring 24 | - Shortcuts for common dev tasks (eg run the tests) 25 | - Quicker navigation between and within files in your projects 26 | - Using the debugger 27 | 28 | ## Resources 29 | 30 | - Vim tutor 31 | - IntelliJ - [https://github.com/tkurylek/intellij-idea-mouseless-kata](https://github.com/tkurylek/intellij-idea-mouseless-kata) 32 | - Sublime Text - [https://www.sublimetext.com/](https://www.sublimetext.com/) 33 | - Atom - [https://atom.io/](https://atom.io/) 34 | 35 | ## Meta 36 | 37 | Status: **early draft** 38 | 39 | Todo: 40 | - Say more about the different types of editors (IDEs vs Plaintext vs Vim vs Emacs) - what is an IDE, why do people use it, why do some people not use it 41 | - Say something about VIM+Tmux type setup 42 | -------------------------------------------------------------------------------- /contributing/index.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Contributing 3 | weight: 100 4 | --- 5 | # Contributing 6 | 7 | This is a community-driven project and we welcome all contributions. This project is developed under the [Alphagov Code of Conduct](https://github.com/alphagov/code-of-conduct) 8 | 9 | Here are a few ways you can help: 10 | 11 | 1. [Review open pull requests](https://github.com/alphagov/gds-tech-learning-pathway/pulls). You don't have to be an expert on the topic to make suggestions. 12 | 2. Improve the copy so it's [easier to understand](https://www.gov.uk/guidance/content-design/writing-for-gov-uk). 13 | 3. Write a resource list for a topic you're interested in 14 | 4. Write a competency statement following the [template](template.html.md). Speak to someone before starting this as we have a list of competencies and what we think should go in them. 15 | 4. Triage [issues](https://github.com/alphagov/gds-tech-learning-pathway/issues) and work out how they can be incorporated into the existing structure. This might be just adding a link to a resource list. 16 | 5. Raise an issue for something that is currently missing from the learning pathway. 17 | 18 | ## Guidelines for contributed content 19 | 20 | Since this guide is public, please avoid any personally identifiable information in any contributions 21 | 22 | If you're not sure about anything, email us at gds-tech-learning-path-discuss (at) digital.cabinet-office.gov.uk to ask. 23 | 24 | ## Awesome_bot 25 | 26 | [Awesome_bot](https://github.com/dkhamsing/awesome_bot) scans all markdown files for dead links, including relative links. If it finds any, the CircleCI build will fail. 27 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # GDS Technology Community - Learning Pathways 2 | 3 | This project exists to bring together the GDS Technology community's collective knowledge and resources to support the learning and development of technologists. 4 | 5 | ## Goals 6 | 7 | We want to: 8 | 9 | - create a set of curated guides, organised by topic, technology, constituency, level. There may be multiple cross-cutting routes into the resources. Our aim is to offer pathways which cater for the most important needs of technologists. 10 | - elaborate the current [technologists career pathways within GDS](https://docs.google.com/document/d/1_svjdchS8LIyKDF6-FAfVPSuvJmoIRgTQukuxl0XRfM/edit) in more detail, by creating a page for each competency statement in the career path. 11 | - prepare for adopting the [DDaT career pathways within GDS](https://www.gov.uk/government/collections/digital-data-and-technology-job-roles-in-government#technical:-software-developer-) by documenting our current career pathway in more detail. 12 | 13 | ## How to contribute 14 | 15 | See [CONTRIBUTING.md](contributing/index.html.md) 16 | 17 | ## Longer term goals 18 | 19 | We want to encourage learning collaboratively in the GDS technology community, and so we'll seek to provide ways for: 20 | 21 | - people to offer and request mentorship 22 | - people to share what they're wanting to learn so that they can join up with others wanting to learn the same things, or get support from others 23 | 24 | However, this repo should not contain any personal names or information because this repo is public. 25 | 26 | ## Licence 27 | 28 | [Open Government Licence](LICENCE.md). 29 | 30 | ## Code of conduct 31 | 32 | This project is developed under the [Alphagov Code of Conduct](https://github.com/alphagov/code-of-conduct) 33 | -------------------------------------------------------------------------------- /resources/other/handling-incidents.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | last_reviewed_on: 2018-11-16 3 | review_in: 1 year 4 | title: Handling incidents 5 | --- 6 | # Handling incidents 7 | 8 | There are two important aspects to responding to an incident 9 | 10 | 1. **Psychological factors** -- incidents are by definition unexpected events. This means there's likely to be stress, confusion, noise. You may have alerts, log data, support tickets or angry stakeholders to deal with. When you're stressed you're more likely to make bad decisions, and to rely on snap judgements or jump to conclusions. So the first important aspect of incident response is how you behave, communicate and respond in these circumstances. 11 | 2. **Analytical factors** -- having a calm state of mind and clear communication is not enough, you also need to be methodical in how you diagnose and understand the problem, and how you make decisions effectively about what interventions to take. 12 | 13 | ## Psychological factors (draft) 14 | 15 | Forming an incident team, incident command -- see eg. https://pay-team-manual.cloudapps.digital/manual/incident-response/incident-overview.html#form-an-incident-team 16 | 17 | ## Analysis (draft) 18 | 19 | - Debugging approach 20 | - no magical thinking -- there's always an explanation 21 | 22 | ## Responding to incidents 23 | - [What happens when things go wrong on GOV.UK](https://insidegovuk.blog.gov.uk/2015/11/18/what-happens-when-things-go-wrong-on-gov-uk/) 24 | 25 | ## Incident reviews 26 | - Here's a list of [post-mortems](https://github.com/danluu/post-mortems) from other companies 27 | - [Guide from Etsy on facilitating blameless incident reviews]( https://extfiles.etsy.com/DebriefingFacilitationGuide.pdf) ([blog post](https://codeascraft.com/2016/11/17/debriefing-facilitation-guide/)) 28 | -------------------------------------------------------------------------------- /career-path/technical-skills/designing-for-reliability.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 100 3 | last_reviewed_on: 2020-03-30 4 | review_in: 6 months 5 | title: Designing for reliability 6 | --- 7 | 8 | # Designing for reliability 9 | 10 | ## The developers role 11 | 12 | Writing code is a core part of software development, but our responsibility extends beyond that. 13 | 14 | As a developer you are responsible for the whole release process, from [code review](/resources/other/code-reviews.html.md) to 15 | deployment on a production system. You should also ensure that the products you are 16 | working on are easy to support and operate. 17 | 18 | ### Junior level 19 | 20 | Working with a more experienced developer, you should be able to produce code of a sufficient quality standard to ship to production. 21 | 22 | You should [use automated testing](/career-path/technical-skills/using-appropriate-testing-to-ensure-software-quality.html.md) to ensure your code works. 23 | 24 | ### Mid level 25 | 26 | At mid level, you should: 27 | 28 | - reliably produce production ready code without assistance 29 | - be able to operate software in production 30 | - review pull requests raised by other members of your team 31 | - anticipate ways that software components and infrastructure can fail 32 | 33 | If working on the frontend, you should understand how to use progresssive enhancement and why it's important. 34 | 35 | ### Senior level 36 | 37 | At senior level, you should 38 | 39 | - understand how systems scale and plan for real world usage 40 | - make sure your build process is repeatable across environments, so it is safe to deploy changes regularly 41 | - monitor your software so you know that it is working in production and can inspect what it's doing 42 | 43 | ## The reliability engineer role 44 | 45 | 46 | ## External resources 47 | - [Resources: Reliability engineering](/resources/systems/reliability-engineering.html.md) 48 | -------------------------------------------------------------------------------- /career-path/working-practices/owning-your-development-plan.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 70 3 | last_reviewed_on: 2020-03-30 4 | review_in: 6 months 5 | title: Owning your development plan 6 | --- 7 | 8 | # Owning your development plan 9 | 10 | Developers should take responsibility for their continued learning and 11 | development by forming a development plan. 12 | 13 | ## Your role as a developer 14 | 15 | Developers should identify areas they are interested in and areas where they 16 | have skill gaps and seek out suitable resources to help further their 17 | understanding. This might include books, courses, self-study, 18 | conferences, or mentoring. 19 | 20 | Your development plan should be reflected in your objective (for example under 21 | the heading "What are you doing for personal development?") and discussed with 22 | your line manager. 23 | 24 | ### Junior level 25 | 26 | You will probably have broad goals in your development plan as you become familiar 27 | with the large surface area of modern development and web/dev ops. 28 | 29 | As a junior you have 20% time where you can focus on things that will help your 30 | development such as tutorials, books and projects. 31 | 32 | You also have the opportunity to to work on a project that is non-delivery related 33 | but benefits GDS. A 20% project should have some specific learning outcomes and 34 | pairing with other juniors is encouraged to help you support and learn from 35 | each other. 36 | 37 | There is a [spreadsheet of suggested 20% time projects] 38 | (https://docs.google.com/spreadsheets/d/1Nrt4oZEMYZR_54SdKApzNrBDKgxafIiPpQSfb3taUDE/edit#gid=492186728). 39 | 40 | You should discuss the project with your line manager before starting on it. 41 | 42 | ### Mid level 43 | 44 | Your development plan may begin to focus more on higher level concepts, such as how to 45 | design maintainable and scalable solutions. You could focus on not only learning 46 | the intricacies of code, but also other skills that go into developing software like user research 47 | and writing good user stories. A mid level plan might also include some 48 | mentoring and presenting to help spread knowledge through the organisation. 49 | 50 | Specific technology learning might be project based. For example, if you are 51 | working on search you might delve into Elasticsearch. 52 | -------------------------------------------------------------------------------- /career-path/working-practices/building-software-as-a-team.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Building software as a team 3 | weight: 10 4 | last_reviewed_on: 2020-03-30 5 | review_in: 6 months 6 | --- 7 | 8 | # Building software as a team 9 | 10 | ## The developer's role 11 | Agile teams recognise that nothing has to be perfect first time, but if we 12 | release software regularly we can continuously improve products. 13 | 14 | Developers supporting the software should be able to quickly respond to change, and teams should not depend on the original authors of the code always being there (otherwise we could never take a holiday). 15 | 16 | ### Junior level 17 | 18 | You should: 19 | 20 | - be familiar with the language and tools your team uses. 21 | - follow [coding conventions/styleguides](https://gds-way.cloudapps.digital/manuals/programming-languages.html) for your language 22 | - understand that code is read more often that it is written 23 | - prefer to refactor and reuse code rather than duplicating it 24 | 25 | ### Mid level 26 | 27 | You should: 28 | 29 | - share knowledge of tools and techniques with your wider team 30 | - participate in [support operations](https://gds-way.cloudapps.digital/standards/user-support.html) in hours or out of hours (as part of an on-call rota) 31 | 32 | 33 | ### Senior level 34 | 35 | You should: 36 | 37 | - Be familiar with working practices such as TDD, continuous integration, continuous delivery and DevOps 38 | - Be able to quickly research and learn new programming tools and techniques 39 | - Support and coach more junior members of the team 40 | 41 | ### Programming language resources 42 | 43 | Depending on the technology you're working with you may find the following resource lists helpful: 44 | 45 | - [Python](/resources/languages/python.html.md) 46 | - [Ruby](/resources/languages/ruby.html.md) 47 | - [Rails](/resources/frameworks/rails.html.md) 48 | - [Java](/resources/languages/java.html.md) 49 | - [Node.js](/resources/frameworks/nodejs.html.md) 50 | 51 | ### Techniques 52 | 53 | - [Pair 54 | programming](/career-path/leading-and-communicating/pair-programming.html.md) 55 | - [Giving and receiving feedback](/resources/other/giving-and-receiving-feedback.html.md) 56 | - [Structuring code](/resources/delivery/structuring-code.html.md) 57 | - [Documenting work](/resources/other/documentation.html.md) 58 | -------------------------------------------------------------------------------- /resources/systems/networking.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | last_reviewed_on: 2018-11-16 3 | review_in: 1 year 4 | title: Networking 5 | --- 6 | # Networking 7 | 8 | - [Important Components](#important-components) 9 | - [Firewalls](#firewalls) 10 | - [Proxies](#proxies) 11 | - [How different protocols fit together](#how-different-protocols-fit-together) 12 | - [The OSI 7-layer-model](#the-osi-7-layer-model) 13 | - [The TCP/IP 4-layer model](#the-tcpip-4-layer-model) 14 | - [Tools](#tools) 15 | - [GNU Network Utilities (inetutils)](#gnu-network-utilities-inetutils) 16 | - [ping](#ping) 17 | - [traceroute](#traceroute) 18 | - [iproute2](#iproute2) 19 | - [ip](#ip) 20 | - [Domain Name System tools (bind)](#domain-name-system-tools-bind) 21 | - [dig](#dig-dns-lookup-utility) 22 | 23 | ## Important Components 24 | 25 | ### Firewalls 26 | 27 | In the context of computer networking, a firewall controls traffic 28 | passing through a point in the network, either by forwarding it on, or 29 | dropping it, normally based on applying some rules. The term comes 30 | from a physical wall used to prevent the spread of fire. 31 | 32 | ### Proxies 33 | 34 | A proxy is a service that acts as an intermediary in a connection 35 | across a network. 36 | 37 | ## How different protocols fit together 38 | 39 | ### The OSI 7-layer model 40 | 41 | [Description on Wikipedia](https://en.wikipedia.org/wiki/OSI_model#Description_of_OSI_layers) 42 | 43 | ### The TCP/IP 4-layer model 44 | 45 | [Description on Wikipedia](https://en.wikipedia.org/wiki/TCP/IP_model#Abstraction_layers) 46 | 47 | ## Tools 48 | 49 | ### GNU Network Utilities (inetutils) 50 | 51 | ### ping 52 | 53 | [Documentation](https://www.gnu.org/software/inetutils/manual/inetutils.html#ping-invocation) 54 | 55 | ### traceroute 56 | 57 | [Documentation](https://www.gnu.org/software/inetutils/manual/inetutils.html#traceroute-invocation) 58 | 59 | ### [iproute2](https://web.archive.org/web/20170704194650/https://wiki.linuxfoundation.org/networking/iproute2) 60 | 61 | Provides the `ip` command, that can be used to find out about network 62 | interfaces and many other things when using Linux. 63 | 64 | ### ip 65 | 66 | ## Domain Name System tools ([bind](https://www.isc.org/downloads/bind/)) 67 | 68 | ### dig (DNS Lookup Utility) 69 | 70 | dig can be used to perform DNS lookups for exploratory or diagnostic 71 | purposes. 72 | -------------------------------------------------------------------------------- /resources/other/security.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | last_reviewed_on: 2018-11-16 3 | review_in: 1 year 4 | title: Security 5 | --- 6 | # Security 7 | 8 | Keeping up to date with security risks and best practices are necessary in keeping applications secure. 9 | 10 | At GDS we regularly run security workshops, [this blog post](https://gdstechnology.blog.gov.uk/2016/08/09/our-web-security-workshop-for-gds-developers/) has more information. 11 | 12 | ## Resources 13 | 14 | ### [OWASP top 10](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project) 15 | 16 | Contains information about the ten most critical web application security risks, with suggested steps on how to prevent them. 17 | 18 | ### Capture the flag challenges 19 | These are safe and legal environments built to allow users to learn and practice "hacking" skills through a series of challenges. 20 | 21 | - [Stripe capture the flag](https://github.com/stripe-ctf/stripe-ctf-2.0/) - A global penetration testing game ran by Stripe in 2012, which illustrated different approaches in cracking a site. 22 | - [Google's Gruyere codelab](http://google-gruyere.appspot.com/) 23 | - [Hackthissite](https://www.hackthissite.org/) 24 | - [Microcorruption](https://microcorruption.com/about) 25 | - [alert(1) to win](https://alf.nu/alert1) - A really good challenge for understanding xss and injection attacks) 26 | 27 | ### [The cryptopals crypto challenges](http://cryptopals.com/) 28 | 29 | A set of 48 exercises which you can solve in any language to learn about cryptography. 30 | 31 | ### [Railsgoat](https://github.com/OWASP/railsgoat) 32 | 33 | We used this vulnerable rails app in some of our previous security workshops at GDS. 34 | 35 | 36 | 37 | ### Books 38 | 39 | - [The Tangled Web: A Guide to Securing Modern Web Applications](http://lcamtuf.coredump.cx/tangled/) - Good guide to browser security concerns. See also the earlier [Google Browser Security Handbook](https://code.google.com/archive/p/browsersec/) upon which it is built. 40 | - [Security Engineering: A guide to building dependable distributed systems](http://www.cl.cam.ac.uk/~rja14/book.html) 41 | - [Writing secure code](https://www.safaribooksonline.com/library/view/writing-secure-code/0735617228/) 42 | - [Agile Application Security: Enabling Security in a Continuous Delivery Pipeline](https://gds-library.cloudapps.digital/books/549) 43 | - [Web Application Security, A Beginner's Guide](https://gds-library.cloudapps.digital/books/380) 44 | - [Threat Modeling: Designing for Security](https://gds-library.cloudapps.digital/books/155) 45 | -------------------------------------------------------------------------------- /career-path/leading-and-communicating/pair-programming.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 60 3 | last_reviewed_on: 2020-03-30 4 | review_in: 6 months 5 | title: Pair programming 6 | --- 7 | 8 | # Pair programming 9 | 10 | ## The developers role 11 | 12 | Pair programming is an important practice for delivering valuable, high quality software. 13 | 14 | When it's done well, it has a number of benefits: 15 | 16 | - it helps to spread a knowledge of the code and software design around the team 17 | - it improves the flow of work by reducing work-in-progress. Stories flow faster through the team, with less thrashing. 18 | 19 | ### What is it? 20 | 21 | Pairing is a collaborative practice where two people bring their focus and 22 | attention to bear together on a problem or task. 23 | 24 | ### How do I learn/get good at it? 25 | 26 | Pairing is not easy. It takes practice and sensitivity. It's an intensely human activity which requires paying a kindly attention to yourself and your pairing partner to bring out the best in each of you. 27 | 28 | ### Junior level 29 | - Have a clear understanding of the story, be able to explain it to your pair 30 | - Discuss approaches with pair 31 | - Use techniques such as ping pong (one person writes the test the other implements) to ensure rotation of roles 32 | - Collaborate with pair to agree an order for tasks 33 | - Recognise when to take breaks 34 | 35 | ### Mid level 36 | - Take responsibility for ensuring your pair remains engaged, slowing down when needed 37 | - Give feedback to your pair on style 38 | - Recognise when to take time away from the computer to explain concepts and ideas. 39 | This might mean using a whiteboard or some paper and a pen. 40 | - Draw pair into discussion around design and approach 41 | 42 | ### Senior level 43 | - Effectively pair with developers of all levels. 44 | - Recognise the strengths and weaknesses of your pair, and how these relate to your own strengths and weaknesses. Use this knowledge to adapt behaviour appropriately 45 | 46 | ## Mob programming 47 | 48 | ## Additional resources 49 | 50 | - [Using mob programming to solve a problem](https://gds.blog.gov.uk/2016/09/01/using-mob-programming-to-solve-a-problem/) 51 | - [Our top 12 mob programming tips and thoughts](https://gdstechnology.blog.gov.uk/2016/09/08/our-top-12-mob-programming-tips-and-thoughts/) 52 | - [Experimenting with mob programming to rebuild the GOV.UK Verify frontend](https://identityassurance.blog.gov.uk/2016/02/26/experimenting-with-mob-programming-to-rebuild-the-gov-uk-verify-frontend/) 53 | - Pair programming anti-patterns [blog](https://sidstechcafe.com/pair-programming-antipatterns-xperience-792fe0112aa1), [video 7m48s](https://www.youtube.com/watch?v=McZ131y0OYU&feature=share) - from Thoughtworks 54 | -------------------------------------------------------------------------------- /career-path/leading-and-communicating/sharing-knowledge-with-others.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 40 3 | last_reviewed_on: 2020-03-30 4 | review_in: 6 months 5 | title: Sharing knowledge with others 6 | --- 7 | 8 | # Sharing knowledge with others 9 | This can include sharing outside of your job role, team or organisation, and collaborating to solve common problems. 10 | 11 | [Make things open, it makes things better](https://www.gov.uk/design-principles#tenth) 12 | 13 | > We should share what we’re doing whenever we can. With colleagues, with users, with the world. Share code, share designs, share ideas, share intentions, share failures. The more eyes there are on a service the better it gets — howlers are spotted, better alternatives are pointed out, the bar is raised. 14 | Much of what we’re doing is only possible because of open source code and the generosity of the web design community. We should pay that back. 15 | 16 | ## Your role as developer/webops 17 | You can share knowledge internally by 18 | 19 | - [Reviewing other developers' code](/resources/other/code-reviews.html.md) 20 | - Documenting software you work with 21 | - Demonstrating work at Show and Tell events and within your team 22 | - Speaking at a monthly Technospective 23 | - Helping to run a workshop or give a presentation 24 | - Sharing articles or talk videos 25 | - Collaborating with other developers to deliver stories 26 | 27 | Some ways you can share knowledge externally: 28 | 29 | - Write a blog post for one of the GDS blogs 30 | - Speak at a conference 31 | 32 | As a developer or webops at GDS you will [code in the open](https://gds-way.cloudapps.digital/standards/source-code.html#source-code), so you should understand how to handle sensitive information (like passwords) independently of the application source code. 33 | 34 | ### Junior level 35 | 36 | You can demonstrate work at Show and Tell events and within your team. 37 | 38 | You can also volunteer for the monthly Technospective to give a longer talk on a specific topic. 39 | 40 | ### Mid level 41 | 42 | [Working together with other developers](/career-path/leading-and-communicating/pair-programming.html.md) is a really good way to share knowledge, since you get to see other developer's workflow, environment and editor/IDE config, and general approaches to problem solving. 43 | 44 | You should also regularly review other developers' pull requests. It's a good idea to check other work-in-progress before picking up new stories, so that code review doesn't become a bottleneck for the team. See the [How to review code](https://gds-way.cloudapps.digital/manuals/code-review-guidelines.html) on the GDS way website for guidance about how to do code reviews well. 45 | 46 | More suggestions: 47 | 48 | - volunteer to mentor another developer 49 | - help a junior developer with a 20% project, or [contribute ideas for 20% projects](https://docs.google.com/a/digital.cabinet-office.gov.uk/forms/d/e/1FAIpQLSeG8FP4mkaM1XYoY4rghgP7cUCXzLWNB849voZLVDGaWOxLQg/viewform) 50 | - help organise a workshop or presentation 51 | 52 | ### Senior level 53 | -------------------------------------------------------------------------------- /resources/datastores/elasticsearch.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 10 3 | last_reviewed_on: 2018-12-19 4 | review_in: 6 months 5 | title: Elasticsearch 6 | --- 7 | 8 | # Elasticsearch 9 | 10 | - [Getting started](#getting-started) 11 | - [The ELK stack](#the-elk-stack) 12 | - [Operating an elasticsearch cluster](#operating-an-elasticsearch-cluster) 13 | - [Learning Resources](#learning-resources) 14 | - [Online courses](#online-courses) 15 | - [Training and conferences](#training-and-conferences) 16 | - [Book recommendations](#book-recommendations) 17 | - [Related books in the GDS library](#related-books-in-the-gds-library) 18 | 19 | ## Getting started 20 | 21 | - [Official reference](https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html) 22 | - [Elasticsearch: The Definitive guide](https://www.elastic.co/guide/en/elasticsearch/guide/current/getting-started.html) 23 | 24 | ## The ELK stack 25 | 26 | ELK stands for [Elasticsearch](https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html), [Logstash](https://www.elastic.co/guide/en/logstash/current/index.html), and [Kibana](https://www.elastic.co/guide/en/kibana/current/index.html). 27 | 28 | Teams at GDS use this stack for [logging](https://gds-way.cloudapps.digital/standards/logging.html#shared-elasticsearch-logstash-and-kibana-elk-stack). 29 | 30 | - [An introduction to the ELK stack (video)](https://www.elastic.co/webinars/introduction-elk-stack) 31 | - [Searching your data (Kibana)](https://www.elastic.co/guide/en/kibana/current/search.html) 32 | - [Lucene query parser syntax](http://lucene.apache.org/core/2_9_4/queryparsersyntax.html) 33 | 34 | ## Building search applications 35 | - [What every software engineer should know about search](https://medium.com/startup-grind/what-every-software-engineer-should-know-about-search-27d1df99f80d) 36 | - [Followup by Doug Turnbull](https://medium.com/@softwaredoug/this-is-a-fantastic-post-e9caae910334) 37 | - [Measuring search performance on GOV.UK](https://gdstechnology.blog.gov.uk/2014/12/22/monitoring-search-performance-on-gov-uk/) 38 | 39 | ## Operating an elasticsearch cluster 40 | 41 | - [Elasticsearch cluster health (GOV.UK publishing)](https://docs.publishing.service.gov.uk/manual/alerts/elasticsearch-cluster-health.html) 42 | 43 | ## Learning resources 44 | 45 | ### Online courses 46 | 47 | - [Udemy - Complete Elasticsearch masterclass with logstash and Kibana](https://www.udemy.com/complete-elasticsearch-masterclass-with-kibana-and-logstash/) 48 | 49 | ### Training and conferences 50 | - [Elastic training](https://training.elastic.co/) 51 | - [Taxonomy bootcamp](http://www.taxonomybootcamp.com/London/) 52 | 53 | ### Book recommendations 54 | - [List of books for search managers](http://intranetfocus.com/good-books-for-search-managers/) 55 | - [Relevant search (with applications for Solr and Elasticsearch)](https://www.manning.com/books/relevant-search) 56 | 57 | ### Related books in the GDS library 58 | - [Designing the Search Experience](https://gds-library.cloudapps.digital/books/79) 59 | - [When search meets web usability](https://gds-library.cloudapps.digital/books/44) 60 | -------------------------------------------------------------------------------- /career-path/leading-and-communicating/leading-on-stories.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 10 3 | last_reviewed_on: 2020-03-30 4 | review_in: 6 months 5 | title: Leading on delivering stories 6 | --- 7 | 8 | # Leading on delivering stories 9 | 10 | ## The developers role 11 | 12 | You should take responsibility for: 13 | 14 | - figuring out how to deliver a user story in the most appropriate way 15 | - considering and balancing short and long term impacts of implementation choices 16 | - ensuring that code produced is of the appropriate quality (which will be different for a prototype vs a live production service) 17 | - ensuring that your knowledge is shared amongst your team so that silos don't form 18 | 19 | ### Junior level 20 | 21 | At junior level, you will be given support to work on user stories. You will normally work in a pair with a more experienced developer. You may be asked to take the lead on well defined stories - [see an example](/resources/delivery/user-story-template.html.md). 22 | 23 | A well defined story will: 24 | 25 | - have clear acceptance criteria, so that you know when you're done 26 | - have a clear statement of which files, classes, tests, and microservices will need to change, and in what way 27 | 28 | ### Mid level 29 | 30 | At mid level, we expect you to: 31 | 32 | - lead on more complex stories 33 | - support juniors and new starters in your team through pairing and providing guidance on delivering stories 34 | - decide which stories to prioritise over others 35 | - identify blockers, and the steps taken to try and unblock them 36 | 37 | ### Senior level 38 | 39 | At senior level you will lead on larger pieces of work which may involve multiple stories or tasks. This doesn't mean you have to do everything yourself, but you should have end to end responsibility for delivering the work. 40 | 41 | This could involve: 42 | 43 | - working with the tech lead and the rest of the team to agree scope and identify risks to delivery early on 44 | - creating well defined stories for other developers to pick up or suggesting an approach to take 45 | - helping to resolve blockers 46 | - making sure code gets [code reviewed](/resources/other/code-reviews.html.md) quickly 47 | - doing a timeboxed investigation (spike) into a problem area 48 | 49 | ## As a tech lead (any level) 50 | 51 | If you are a tech lead, you will work closely with the product manager and delivery manager to make sure that work is ready for other developers to pick up; for example, by working with the team to break down stories into smaller tasks. 52 | 53 | You'll be responsible for ensuring that the development work is aligned with the team's goals, while 54 | maintaining technical standards. This may involve: 55 | 56 | - Working with PM/DM to get tech debt prioritised 57 | - Advising team members on technical implementation 58 | - Working with Tech Archs and other stakeholders (e.g. sec-ops & SRE) to make sure proposed solutions are appropriate 59 | 60 | As a tech lead, you shouldn't try to do everything yourself, even if it's easier. This is not sustainable in the long term and takes learning opportunities away from other developers on the team. 61 | 62 | The tech lead can also be a tie-breaker - if your team is having trouble making a decision, make the call. 63 | -------------------------------------------------------------------------------- /career-path/technical-skills/version-control.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 10 3 | last_reviewed_on: 2020-03-30 4 | review_in: 6 months 5 | title: Using version control 6 | --- 7 | 8 | # Using version control 9 | 10 | Version control facilitates collaboration amongst a team working on a shared code base. Each change to a code base includes a message explaining the reason for those changes. These messages provide useful context to future developers who may want to understand the reasoning behind different design decisions. 11 | 12 | Version control also allows for controlled testing and deployment of known software versions, which is an essential part of any reliable quality control process. Nowadays this will typically be in the form of a continuous integration/continuous deployment pipeline. 13 | 14 | ## Coding in the open 15 | 16 | At GDS we use Github to store our git repositories and review work in progress. 17 | Source code should be [open to the public and published under an open source license](https://gds.blog.gov.uk/2017/09/04/the-benefits-of-coding-in-the-open/). 18 | 19 | [The GDS Way](https://gds-tech-docs.cloudapps.digital/standards/source-code.html#source-code) explains how to manage source code repositories and use GitHub securely. 20 | 21 | ## What you should be able to do 22 | 23 | - Understand and follow your team’s branching and [code review](/resources/other/code-reviews.html.md) process 24 | - Understand the benefits of having a clear commit history 25 | - Write clear commit messages for your changes 26 | 27 | ## Starting out 28 | 29 | - Be able to clone a git repository 30 | - Be able to create a branch 31 | - Be able to make commits with clear commit messages 32 | - Be able to push changes 33 | - Open a pull request 34 | - [Understand what rebasing is](https://nathanleclaire.com/blog/2014/09/14/dont-be-scared-of-git-rebase/) 35 | - Understand when it is necessary to force push (and when NOT to :-)) 36 | - Understand the [git styleguide](https://github.com/alphagov/styleguides/blob/master/git.md) 37 | 38 | We’d expect a Junior developer to be able to do all of these things. 39 | 40 | ### Guides 41 | - [GitHub flow](https://help.github.com/articles/github-flow/) 42 | - [Git immersion](http://gitimmersion.com/index.html) 43 | - [Git for non-developers](http://anitacheng.com/git-for-non-developers) 44 | 45 | ## More advanced 46 | - [Rewrite commit history before submitting a pull request in order to make it clear](https://www.atlassian.com/git/tutorials/rewriting-history) 47 | - Understanding the trade-offs of long running feature branches 48 | - Knowing when to split things into multiple pull requests 49 | - Being skilled at structuring commits into a coherent narrative 50 | - [Understand git hooks and when to use them](https://www.atlassian.com/git/tutorials/git-hooks) 51 | 52 | ### Guides 53 | - [Git flight rules](https://github.com/k88hudson/git-flight-rules) - what to do if something goes wrong 54 | - [Pro Git](https://git-scm.com/book/en/v2) - free online book about git 55 | 56 | ## Preserving history 57 | Writing clear commit messages helps other developers (including your future self) understand why changes were made. 58 | 59 | See [styleguide: git](https://github.com/alphagov/styleguides/blob/master/git.md) for some good examples. 60 | -------------------------------------------------------------------------------- /career-path/working-practices/knowing-when-to-ask-for-help.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 20 3 | last_reviewed_on: 2020-03-30 4 | review_in: 6 months 5 | title: Knowing when to ask for help 6 | --- 7 | # Knowing when to ask for help 8 | 9 | Building software systems is complex. Nobody knows all the answers. Don't be afraid to ask! 10 | 11 | We work in collaborative multi-disciplinary teams so that we can combine our diverse skills and knowledge. Even very experienced people rely on input from others. There's no shame in asking if you're not sure about something, if you didn't understand or if you want a second opinion. 12 | 13 | It's usually better to ask for help than to struggle away on your own trying to figure something out. 14 | 15 | Asking for help can be hard, especially if you're new and perhaps experiencing [imposter syndrome](https://medium.com/learn-love-code/developers-how-to-overcome-imposter-syndrome-48edee803cf4). 16 | 17 | ### What is it? 18 | 19 | Knowing when and how to ask for help. Developing a [growth mindset](https://www.ted.com/talks/carol_dweck_the_power_of_believing_that_you_can_improve) that recognises that we learn from failure and feedback. 20 | 21 | ### How do I learn/get good at it? 22 | 23 | Practice! Ask questions! But also reflect upon how effective your question-asking has been. Perhaps you need to do some research first? Maybe it's better to put your question in writing and then talk it through? Are you a visual person, do diagrams help? Do you need to reproduce or isolate a problem so that you can show it to someone else? 24 | 25 | When asking questions, be sure to provide context about what you are trying to do, not just the problems you encountered when trying to solve it yourself (AKA [the X-Y problem](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem)). 26 | 27 | ### Junior level 28 | 29 | You'll usually be given [well defined tasks](/career-path/leading-and-communicating/leading-on-stories.html.md#junior-level) to work on, with support from a more experienced developer. Discuss the work with your colleague and try to understand what's involved. 30 | 31 | The person you're working with will give you guidance and you can ask questions as you go along. There's no such thing as a stupid question, so don't be afraid to ask! 32 | 33 | ### Mid level 34 | 35 | At a mid level, you will be working more independently, or taking a lead in pairing situations. You should start to develop a better sense of when to ask for input, perhaps from other disciplines such as operations, design. You might need to call a meeting with several people to get more structured input. You'll think about how to explain the problem to others in a way that they can input effectively. You'll think ahead of time about different options, and their pros- and cons- so that you can make the most effective use of other people's expertise. 36 | 37 | ### Senior level 38 | 39 | At senior level, you can build a culture of asking questions by setting a good example. 40 | 41 | For example, if you notice people using acronyms or jargon that not everyone knows about, ask them what it means! Often we use jargon without even realising it, and somebody pointing it out provides an opportunity to better introduce the technology or concept to people who might not be familiar with it. 42 | -------------------------------------------------------------------------------- /resources/languages/java.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 20 3 | last_reviewed_on: 2018-11-16 4 | review_in: 1 year 5 | title: Java 6 | --- 7 | # Java 8 | 9 | Java is a general purpose object oriented programming language. Java code is statically typed and compiles into Java bytecode, which runs on the Java Virtual Machine (JVM). This allows compiled Java programs to run on many different platforms. 10 | 11 | Other than Java, there are many other languages that can run on the JVM, such as Scala, Clojure, Kotlin, and Groovy. These allow you to take advantage of Java's huge library ecosystem without writing Java code. 12 | 13 | ## Java jargon 14 | - JVM = Java virtual machine 15 | - JRE = Java Runtime Environment. This is what you install to run Java programs. Includes a JVM and the standard library 16 | - JDK = Java development kit. This is what you install to build Java programs. Includes the compiler and other development tools, as well as the JRE. 17 | 18 | ## Release history 19 | > Note that the JDK follows a version string convention where JDK 1.8 corresponds to Java 8, JDK 1.9 corresponds to Java 9 etc. 20 | 21 | - 1996 - Java 1 22 | - 2006 - Java 6 23 | - 2011 - Java 7 24 | - 2014 - Java 8 25 | - 2017 - Java 9 26 | - 2018 - Java 10 27 | 28 | ## Starting out 29 | ### Hello world 30 | Save the following to `HelloWorld.java`. 31 | 32 | ```java 33 | public class HelloWorld { 34 | public static void main(String args[]){ 35 | System.out.println("Hello World"); 36 | } 37 | } 38 | ``` 39 | 40 | Compile with `javac HelloWorld.java`. This will create a `HelloWorld.class` file. 41 | 42 | Then run with `java HelloWorld`. 43 | 44 | ### Integrated development environments (IDEs) 45 | A good IDE for Java is Intellij Idea. Download it from [https://www.jetbrains.com/idea/download/](https://www.jetbrains.com/idea/download/) 46 | 47 | ### Packaging java programs 48 | Java classes can be packaged together in [.jar files](https://docs.oracle.com/javase/tutorial/deployment/jar/basicsindex.html) (Java ARchive). 49 | 50 | Common build tools are [Gradle](http://gradle.org/) and [Maven](http://books.sonatype.com/mvnex-book/reference/index.html). 51 | 52 | ## Newer language features 53 | * [Java 8 tutorial](http://winterbe.com/posts/2014/03/16/java-8-tutorial/) 54 | 55 | ## Reference documentation 56 | - [API documentation](https://docs.oracle.com/javase/10/docs/api/overview-summary.html) 57 | - [Essential classes](https://docs.oracle.com/javase/tutorial/essential/index.html) 58 | - [Core libraries](https://docs.oracle.com/javase/10/core/java-core-libraries1.htm#JSCOR-GUID-C6BE8117-F73E-4BE6-98AA-681A0CD4EEA9) 59 | 60 | ## Resources 61 | - [Java for small teams](https://ncrcoe.gitbooks.io/java-for-small-teams/content/) - a freely distributable guide to best practices 62 | - [Effective Java](https://gds-library.cloudapps.digital/books/573) - available in the GDS Library 63 | - [Java for complete beginners](https://courses.caveofprogramming.com/p/java-for-complete-beginners) - a free online course that assumes no prior knowledge 64 | - [Better Java](https://github.com/cxxr/better-java) - advice on code style and common libraries/tools 65 | 66 | ### Java community at GDS 67 | There is an informal Java community at GDS. 68 | 69 | - Slack channel: #java 70 | - Mailing list: [GDS Tech Java Community Members](https://groups.google.com/a/digital.cabinet-office.gov.uk/forum/#!forum/gds-tech-java-community-members) 71 | 72 | Java community meetings are held once a month, featuring presentations, demos and discussions. Join the mailing list to get an invitation. Suggest agenda topics in the Slack channel. Notes from previous meetings can be found in the mailing list archives. 73 | -------------------------------------------------------------------------------- /career-path/technical-skills/using-appropriate-testing-to-ensure-software-quality.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 50 3 | last_reviewed_on: 2020-03-30 4 | review_in: 1 year 5 | title: Using appropriate testing to ensure software quality 6 | --- 7 | 8 | # Using appropriate testing to ensure software quality 9 | 10 | It's impossible to build software without making mistakes. Testing lets us catch small problems early and fix them before they become big problems. 11 | 12 | ## Your role as developer 13 | 14 | As you write code, you should be thinking about how to test whether it works. You should ensure that code you work on is covered by automated tests, so that you can be alerted early if it stops working as intended. 15 | 16 | Testability is a part of designing software well. If something is hard to test at a unit level, then ask yourself if you can improve the software design by splitting the code into smaller cooperating objects with specific responsibilities. 17 | 18 | Don't forget about non-functional requirements like performance, accessibility, and security - there are tools to automate testing these things too. 19 | 20 | ### Junior level 21 | 22 | At junior level, you will normally work with another more experienced developer who will help you with test driven development (TDD). With guidance you will learn what tests to write and how to make them pass. 23 | 24 | You should know about the different types of tests, and familiarise yourself with the testing frameworks you write them in. 25 | 26 | You should understand what makes a "good test". 27 | 28 | A good test is generally defined to: 29 | - have a clear description, so that any developer can understand it 30 | - carry out one expectation 31 | - have a useful error message, so that the issue can be easily located 32 | 33 | ### Mid level 34 | 35 | At mid level, testing should be a core part of delivering a feature. 36 | 37 | - You should understand the common testing frameworks in your language. 38 | - Your tests should verify meaningful behaviour and not become fragile as implementation details change. 39 | 40 | You should be able to lead in a pairing session, guiding a less experienced developer on writing good tests and making them pass. 41 | 42 | You should refactor tests, to ensure that when new tests are added they are not duplicates of other current tests. 43 | 44 | You should understand different types of testing and when to use them, for example: 45 | - Unit testing 46 | - Integration testing 47 | - Functional testing 48 | - Performance/Load testing 49 | 50 | ### Senior level 51 | 52 | 53 | ## Resources 54 | ### Approaches 55 | - [Testing and Checking refined](http://www.satisfice.com/blog/archives/856) 56 | 57 | ### Writing good tests 58 | - [GeePaw Hill on TDD](http://geepawhill.org/five-underplayed-premises-of-tdd-2/) 59 | - [A quick puzzle to test your problem solving](https://www.nytimes.com/interactive/2015/07/03/upshot/a-quick-puzzle-to-test-your-problem-solving.html?mcubz=3) - this shows why it can be hard to write effective tests 60 | - [Testing microservices](http://martinfowler.com/articles/microservice-testing/) - infodeck from Thoughtworks which outlines the architectural principles of microservices and the various options and approaches 61 | - Kent Beck (the creator of TDD) - ["I get paid for code that works, not tests, so I test just enough to get the desired level of confidence"](http://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests/153565#153565) 62 | - [Rails Conf 2013 The Magic Tricks of Testing by Sandi Metz](https://www.youtube.com/watch?v=URSWYvyc42M) 63 | - [Service Design Manual: Testing code](https://www.gov.uk/service-manual/making-software/code-testing.html) 64 | -------------------------------------------------------------------------------- /ways-of-learning/index.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Ways to learn 3 | weight: 50 4 | last_reviewed_on: 2025-02-13 5 | review_in: 6 months 6 | --- 7 | 8 | # Ways to learn 9 | 10 | All civil servants are entitled to [5 days of learning and development each year](https://www.gov.uk/guidance/training-and-development-opportunities-in-the-the-civil-service). 11 | 12 | Junior developers can use 20% of their time for learning, for example, by working on a self-contained project. 13 | 14 | You can ask questions about learning and development in #ask-learning-and-devt on slack. 15 | 16 | ## Private study 17 | It's ok to ask your team for time to study something. 18 | 19 | Study materials could include books, videos, or guided tutorials. 20 | 21 | GDS has a [library](https://gds-library.cloudapps.digital) and subscriptions to [Pluralsight](https://www.pluralsight.com/) that you can use. 22 | 23 | If you know others with similar learning goals, consider organising a group to learn together, or presenting back what you've learned to other people. 24 | 25 | ## Supported learning 26 | 27 | You can learn while being supported by other software developers. 28 | 29 | Project Early Talent Assigned Learning (PETAL) is a GDS tech community initiative where you dedicate your 20% time to work on your learning goals with your own bespoke learning project. 30 | 31 | A PETAL semester is one day a week, for twelve weeks, and is open to GDS juniors and apprentices. A semester is run by one or two GDS software developers and has a group of other junior peers working on their own learning goals. 32 | 33 | Your goals can be anything that will help your technical development, and you will get help to decide a project that is achievable within the semester. 34 | 35 | There is some flexibility to how each semester runs, though typically: 36 | 37 | - days start with a short standup 38 | - days have a tech talk just for the group 39 | - participants have opportunities to chat and/or pair with software developers and semester peers on whatever topic will help their learning (like knowledge sharing, project planning, coding) 40 | - show and tell sessions every few weeks 41 | - a couple of retrospective sessions where we discuss the semester and how it can be improved 42 | 43 | See [#proj-early-talent-assigned-learning](https://gds.slack.com/archives/C05599LTS0J) for information on how to join the next semester. 44 | 45 | Interesting in running a PETAL semester? see the guidance for [Running PETAL](./running-petal.md). 46 | 47 | ## Formal training 48 | You can book training through the people development form. Talk to #ask-learning-and-devt on slack if you have any questions. 49 | 50 | Formal training can include: 51 | 52 | - External training courses 53 | - Conferences 54 | - Civil service learning 55 | 56 | ## Informal training 57 | Informal training can include: 58 | 59 | - [Internal workshops](https://gdstechnology.blog.gov.uk/2016/08/09/our-web-security-workshop-for-gds-developers/) 60 | - Group study/activities 61 | - User group meetups 62 | - Attending [technospectives](https://trello.com/b/0T7BR3gT/technospectives) or other presentations 63 | 64 | If you are interested in running a new workshop or group, first check if anyone has run anything similar before, as they may be able to share advice and materials. 65 | 66 | ## On the job learning 67 | 68 | Many skills are best developed through working on a project as part of a team. 69 | 70 | This can include: 71 | 72 | - building and supporting software 73 | - participating in [code reviews](/resources/other/code-reviews.html.md) 74 | - attending incident reviews 75 | - participating in show & tells 76 | - writing and speaking about your work externally 77 | -------------------------------------------------------------------------------- /resources/tools/the-unix-shell.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | last_reviewed_on: 2018-11-16 3 | review_in: 1 year 4 | title: The unix shell 5 | --- 6 | # The Unix Shell 7 | 8 | The unix shell (you might know it as "the command line", or "the terminal"), is one of the oldest programming environments around that remains in use today. The first shell was designed by [Ken Thompson](https://en.wikipedia.org/wiki/Ken_Thompson) for the Unix operating system, and shells have evolved considerably since: you are more likely to have come across one of either [bash](http://www.gnu.org/software/bash/) or [zsh](http://www.zsh.org/). 9 | 10 | Shell programming broadly falls into two categories: 11 | 12 | 1. Using powerful features of your shell to help you when interacting with files and programs at the command line. 13 | 14 | 2. Learning to use shell as a programming language. 15 | 16 | The shell and its associated command line utilities form a full-blown programming language, with an extraordinary expressiveness for certain tasks (namely, the processing of files and text, and the coordination of sets of running programs). 17 | 18 | If you treat the shell as a programming language, and apply the common sense and good practice you have learnt in other areas of programming, you will find it an invaluable addition to your toolbox. The converse is true: if you treat the shell as a misshapen hack, and write misshapen hacks of scripts, you won't enjoy shell programming, any more than you'd enjoy programming Ruby with the same outlook! 19 | 20 | ## Getting started with the shell 21 | 22 | The shell and its companion utilites (much functionality in shell programming comes from external utility functions like [cut(1)](http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html#top) and [sort(1)](http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html#top)) are frequently described as user-hostile, or at least opaque. This is a fair accusation, and typically derives either from legacy considerations (breaking backwards compatibility was a big deal in the Unix world) or from the [Unix philosophy](http://www.faqs.org/docs/artu/ch01s06.html)'s approach to splitting programs into small, reusable tools that "do one thing well." If you know where to look, however, you will find that most of the unix shell and utilities are well documented. 23 | 24 | In learning about the shell, your best friends should be Google and the Unix manual system. With the shell, even more so than in other programming languages, if you ever find yourself thinking "surely someone has had to do this before", the chances are they probably have. So Google, Google, Google, until you find out what the right words are to express your problem in shell. Once you know the name of the program or programs you should be using, read the manual page. To read a manual page for a command -- for example, sort: 25 | 26 | $ man sort 27 | 28 | Or to search for manual pages which contain the word "concatenate": 29 | 30 | $ man -k concatenate 31 | 32 | Now that you know the most important source of documentation for the shell, you may find the following guides and essays useful for getting started: 33 | 34 | - [A Brief Introduction to Unix](http://staff.washington.edu/corey/unix-intro+man.html) 35 | - [Pipes: A Brief Introduction](http://www.linfo.org/pipes.html) 36 | 37 | ## Reference guides and shell programming 38 | - [The Shell Hater's Handbook](https://shellhaters.org/) 39 | - [POSIX Shell language reference](http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html) 40 | - [Insufficiently known POSIX shell features](https://apenwarr.ca/log/?m=201102#28) 41 | - [Bashisms](http://mywiki.wooledge.org/Bashism) 42 | - [Advanced Bash-Scripting Guide](http://www.tldp.org/LDP/abs/html/abs-guide.html) 43 | -------------------------------------------------------------------------------- /resources/other/inspiration-and-general-resources.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | last_reviewed_on: 2018-11-16 3 | review_in: 1 year 4 | title: Inspiration for this project 5 | --- 6 | 7 | # Inspiration for this project 8 | 9 | This is a list of things that inspired the learning pathway project in GDS. 10 | 11 | ## Trail maps 12 | These inspired what we're calling "resource lists". They take a specific learning goal and draw out a map of how to get there. 13 | 14 | - [https://github.com/thoughtbot/trail-map](https://github.com/thoughtbot/trail-map) 15 | - [https://github.com/yangchenyun/trail-map](https://github.com/yangchenyun/trail-map) 16 | - [http://railsbridgetriangle.com/resources/](http://railsbridgetriangle.com/resources/) 17 | - I think that Thoughtbot maybe commercialised their learning offering into [https://thoughtbot.com/upcase](https://thoughtbot.com/upcase) 18 | - [http://portal.netobjectives.com/pages/roles/developer-role/](http://portal.netobjectives.com/pages/roles/developer-role/) 19 | 20 | ## Onboarding materials 21 | These are materials created by companies to help out new starters. 22 | 23 | - [https://twitter.github.io/scala_school/](https://twitter.github.io/scala_school/) - Twitter's pathway for learning scala from the ground up 24 | - [https://www.google.com/about/careers/students/guide-to-technical-development.html](https://www.google.com/about/careers/students/guide-to-technical-development.html) - Google's guide for getting hired as a comp-sci graduate 25 | 26 | ## Explorable career paths 27 | These are some ways companies have made their career paths transparent. 28 | 29 | - [https://levels.patreon.com/](https://levels.patreon.com/) - Patreon's Engineering Levels 30 | - [Monzo's progression framework](https://monzo.com/blog/2018/06/25/monzos-transparent-engineering-progression-framework/) 31 | 32 | ## Advice 33 | Advice for people starting a technical role. 34 | 35 | - [http://tommyp.org/junior-developer](http://tommyp.org/junior-developer) 36 | 37 | ## Lists of lists 38 | Curated lists of learning materials. 39 | 40 | - [https://github.com/sindresorhus/awesome](https://github.com/sindresorhus/awesome) a curated list of lists grouped into frontend, backend, languages etc. 41 | 42 | ## "Things everyone should know" 43 | Lists of topics that may be relevant to technologists, and resources for learning for more about them. 44 | 45 | - [http://matt.might.net/articles/what-cs-majors-should-know/](http://matt.might.net/articles/what-cs-majors-should-know/) - One of many "everyone should know know this" lists. Not all of it is relevant, but covers technical subjects people might be interested in learning. 46 | - [https://github.com/mtdvio/every-programmer-should-know](https://github.com/mtdvio/every-programmer-should-know) 47 | 48 | 49 | ## Some other possible sources of inspiration 50 | 51 | - [http://tommyp.org/junior-developer](http://tommyp.org/junior-developer) 52 | - [https://github.com/thoughtbot/trail-map](https://github.com/thoughtbot/trail-map) 53 | - [https://github.com/yangchenyun/trail-map](https://github.com/yangchenyun/trail-map) 54 | - [http://railsbridgetriangle.com/resources/](http://railsbridgetriangle.com/resources/) 55 | - I think that Thoughtbot maybe commercialised their learning offering into [https://thoughtbot.com/upcase](https://thoughtbot.com/upcase) 56 | - [https://github.com/sindresorhus/awesome](https://github.com/sindresorhus/awesome) a curated list of lists grouped into frontend, backend, languages etc. 57 | - [https://twitter.github.io/scala_school/](https://twitter.github.io/scala_school/) - Twitter's pathway for learning scala from the ground up 58 | - [https://www.google.com/about/careers/students/guide-to-technical-development.html](https://www.google.com/about/careers/students/guide-to-technical-development.html) - Google's guide for getting hired as a comp-sci graduate 59 | - [http://matt.might.net/articles/what-cs-majors-should-know/](http://matt.might.net/articles/what-cs-majors-should-know/) - One of many "everyone should know know this" lists. Not all of it is relevant, but covers technical subjects people might be interested in learning. 60 | - [https://levels.patreon.com/](https://levels.patreon.com/) - Patreon's Engineering Levels 61 | -------------------------------------------------------------------------------- /career-path/index.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Career path competencies 3 | weight: 40 4 | --- 5 | 6 | # The technologist's career path at GDS 7 | 8 | The information in this section expands on the [technologists career path](https://docs.google.com/document/d/1_svjdchS8LIyKDF6-FAfVPSuvJmoIRgTQukuxl0XRfM/edit) at GDS, which applies to the [Software Engineering community](https://sites.google.com/a/digital.cabinet-office.gov.uk/gds/communities-of-practice/software-engineering-1). 9 | 10 | More generally, the civil service is adopting the [Digital, Data and Technology Profession Capability Framework](https://www.gov.uk/government/collections/digital-data-and-technology-profession-capability-framework), which outlines the various roles and responsibilities of technologists working in government. That framework covers a wider range of digital skills beyond just software engineering, and the structure of this website will change to match that. 11 | 12 | ## Competencies 13 | 14 | Competencies are specific skills, behaviours, and knowledge that help you perform your role. 15 | 16 | The list below elaborates on the kinds of competencies mentioned in the career path. The page on each one should define what we expect at junior, mid and senior level. 17 | 18 | These competencies do not generally distinguish between developers, web operations engineers and site reliability engineers - this may change. 19 | 20 | ### Working practices 21 | 22 | - [Building software as a team](working-practices/building-software-as-a-team.html.md) 23 | - [Knowing when to ask for help](working-practices/knowing-when-to-ask-for-help.html.md) 24 | - [Planning and estimating](working-practices/planning-and-estimating.html.md) 25 | - [Prioritising your time](working-practices/prioritising-your-time.html.md) 26 | - [Working independently](working-practices/working-independently.html.md) 27 | - [Working as a multi-disciplinary team](working-practices/working-as-a-multi-disciplinary-team.html.md) 28 | - [Owning your development plan](working-practices/owning-your-development-plan.html.md) 29 | 30 | 31 | ### Technical skills 32 | 33 | - [Version control](technical-skills/version-control.html.md) 34 | - [Using a sytematic approach to solve problems](technical-skills/systematic-approach-solving-problems.html.md) 35 | - [Technical debt tradeoffs](technical-skills/technical-debt-tradeoffs.html.md) 36 | - [Diagnosing and debugging issues](technical-skills/diagnosing-and-debugging-issues.html.md) 37 | - [Using appropriate testing to ensure software quality](technical-skills/using-appropriate-testing-to-ensure-software-quality.html.md) 38 | - [Designing technical features](technical-skills/designing-technical-features.html.md) 39 | - [Designing and testing for accessibility](technical-skills/designing-and-testing-for-accessibility.html.md) 40 | - [Building secure services](technical-skills/building-secure-services.html.md) 41 | - [Assessing performance](technical-skills/assessing-performance.html.md) 42 | - [Designing for reliability](technical-skills/designing-for-reliability.html.md) 43 | - [Selecting technology](technical-skills/selecting-technology.html.md) 44 | 45 | 46 | ### Leading and communicating 47 | - [Leading on stories](leading-and-communicating/leading-on-stories.html.md) 48 | - [Wider context](leading-and-communicating/wider-context-of-work.html.md) 49 | - [Writing and speaking](leading-and-communicating/writing-and-speaking.html.md) 50 | - [Sharing knowledge with others](leading-and-communicating/sharing-knowledge-with-others.html.md) 51 | - [Awareness of wider community](leading-and-communicating/awareness-of-wider-community.html.md) 52 | - Comunicating assumptions and getting clarification up front to minimise rework 53 | - [Pair programming](leading-and-communicating/pair-programming.html.md) 54 | 55 | ### Adding a competency to this page 56 | ``` 57 | ## [Writing a competency statement] 58 | 59 | [A short summary of the skills, behaviours and/or knowledge you are writing about at the top, if not obvious from the title.] 60 | 61 | ### Your role as [developer/webops] 62 | 63 | Why is this competency important? 64 | 65 | How does it relate to your role and responsibilities? 66 | 67 | ### Junior level 68 | 69 | [What it looks like at junior level.] 70 | 71 | ### Mid level 72 | 73 | [What it looks like at mid level.] 74 | 75 | ### Senior level 76 | 77 | [What it looks like at senior level.] 78 | 79 | ### Related guides [optional] 80 | 81 | [Links to guides on topics related to this competency] 82 | 83 | ### External resources [optional] 84 | 85 | [Links to External resources] 86 | ``` 87 | -------------------------------------------------------------------------------- /resources/frameworks/rails.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 20 3 | last_reviewed_on: 2018-11-16 4 | review_in: 1 year 5 | title: Rails 6 | --- 7 | 8 | # Rails 9 | 10 | ## Introduction 11 | Rails, or Ruby on Rails, is a server side web app framework written in Ruby. It 12 | is designed to make programming web applications easier by making assumptions 13 | about what every developer needs to get started. Like Ruby, Rails is designed 14 | with 'programmer happiness' in mind and prioritises readability, ease and 15 | enjoyment of use. 16 | 17 | Rails is an MVC ([Model-view-controller](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller)) 18 | framework and famously favours [Convention over configuration](https://en.wikipedia.org/wiki/Convention_over_configuration) 19 | in an attempt to aid productivity and lower the barrier to entry. An example of 20 | this is the way in which a model in Rails maps to a table in a database and to a 21 | Ruby file, it is only if one deviates from this convention, that the developer 22 | needs to write code regarding these names. 23 | 24 | Ruby on Rails is separated into various packages including: 25 | - [ActiveRecord](https://guides.rubyonrails.org/active_record_basics.html) 26 | - [Active Resource](https://api.rubyonrails.org/v3.2/classes/ActiveResource/Base.html) 27 | - [Action Pack](https://github.com/rails/rails/tree/master/actionpack) 28 | - [Active Support](https://guides.rubyonrails.org/active_support_core_extensions.html) 29 | - [Action Mailer](https://guides.rubyonrails.org/action_mailer_basics.html) 30 | 31 | Rails is sometimes criticised for issues with scalability due to being written in 32 | the relatively slow performing Ruby. It should be noted, however, that many high 33 | profile, high traffic web apps are currently running on Ruby on Rails including 34 | Airbnb, Github and GOV.UK! 35 | 36 | ## Starting out 37 | 38 | ### Which version? 39 | 40 | When working with an existing rails project, the rails version will be specified 41 | in the gemfile and all you will need to do is navigate to the application in your 42 | terminal and run `bundle install` and voila, all dependencies will be installed. 43 | 44 | If you are starting a project afresh then rails offers wonderful [documentation](https://guides.rubyonrails.org/getting_started.html) 45 | to help you begin 46 | 47 | ### Working with Rails Projects 48 | 49 | As noted above, the dependencies are listed in a 'Gemfile'. 50 | 51 | A Rails application can be run with `bundle exec rails --server`. It is common 52 | practice to define how to get started with a Rails application through a README 53 | file in the root of the project. 54 | 55 | Tasks in a Rails project will typically be run using [Rake][rake] which, by 56 | convention, will usually run the tests of an application if it is not provided 57 | any arguments. 58 | 59 | ### Rails Test Frameworks 60 | 61 | See [Ruby test frameworks](/resources/languages/ruby.html.md) 62 | 63 | ### Code style 64 | 65 | You can find the GDS programming language style guides [here](https://gds-way.cloudapps.digital/manuals/programming-languages.html#programming-language-style-guides) 66 | 67 | ### Additional Tools 68 | 69 | - [Pry-byebug](https://github.com/deivid-rodriguez/pry-byebug) 70 | A step by step debugging tool 71 | - [Factory bot](https://github.com/thoughtbot/factory_bot_rails) 72 | A library for setting up Ruby objects as test data 73 | - [GOVUK-lint](https://github.com/alphagov/govuk-lint) 74 | A linter which complies with GOV.UK ruby styleguide. 75 | - [GOVUK_app_config](https://github.com/alphagov/govuk_app_config) 76 | A library which includes the basics of a GOV.UK application including error 77 | reporting, a Unicorn web server, logging and a stasd client. 78 | - [GDS-api-adapters](https://github.com/alphagov/gds-api-adapters) 79 | A set of API adapters to make working with GDS APIs easier. 80 | 81 | 82 | ### Reference documentation 83 | https://guides.rubyonrails.org/ 84 | 85 | 86 | ### Learning materials 87 | - [Michael Hartl's RoR Tutorial](https://www.railstutorial.org/) 88 | Arguably the most famous beginners guide to Rails available. 89 | - [Railscasts](https://www.youtube.com/user/RailscastsReloaded) 90 | Ryan Bates' YouTube channel which contains webcasts on just about everything 91 | Rails, an excellent resource for the visual learner, although some of the videos 92 | are a little dated. 93 | - [Thoughtbot blog](https://robots.thoughtbot.com/) 94 | Thoughtbot, the people behind factory bot and many other high profile ruby gems, 95 | have a great, regularly updated blog often covering rails or ruby specific issues 96 | as well as general thoughts on software development. 97 | -------------------------------------------------------------------------------- /resources/languages/python.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 50 3 | title: Python 4 | last_reviewed_on: 2018-11-16 5 | review_in: 1 year 6 | --- 7 | 8 | # Python 9 | 10 | Python is a general-purpose programming language. 11 | 12 | It has a large standard library ("batteries included") and 3rd party libraries are distributed through the [Python Package Index (PyPi)](https://pypi.python.org/pypi). 13 | 14 | ## Starting out 15 | 16 | ### Which version? 17 | Python 3 introduced a number of backwards incompatible changes, which can be confusing. When learning the language, make sure that the resources you use cover the same version you are using (2.7 or 3.x). 18 | 19 | ### Working with Python Projects 20 | 21 | `pip` is python's package manager (similar to `gem` in ruby-land and `npm` for node.js). The convention is to list dependencies in a `requirements.txt` file. 22 | 23 | By default libraries will be installed for the system python, which may require superuser access. 24 | 25 | Instead, you can use `virtualenv`, which provides an isolated python environment for your project. 26 | 27 | ``` 28 | $ virtualenv env # Create a virtualenv directory, 'env' 29 | $ source env/bin/activate # Activate the virtualenv 30 | (env)$ pip install -r requirements.txt # Install project dependencies 31 | ``` 32 | 33 | ### Python Test Frameworks 34 | 35 | Python comes with a built in test framework, [unittest](https://docs.python.org/3.5/library/unittest.html). 36 | 37 | [Pytest](http://doc.pytest.org/en/latest/) and [Nose](http://nose.readthedocs.io/en/latest/) are popular alternatives. 38 | 39 | ### Additional Tools 40 | 41 | - [PyCharm](https://www.jetbrains.com/pycharm/) is a python-focused IDE from Jetbrains 42 | - [Virtualenvwrapper](https://virtualenvwrapper.readthedocs.io/en/latest/) is an easier way of working with virtualenvs 43 | - [Visual Studio Code](https://code.visualstudio.com/) for a fast lightweight IDE, python plugins available 44 | 45 | ### Reference documentation 46 | * [Python 2 Reference](http://docs.python.org/2/) 47 | * [Python 3 Reference](http://docs.python.org/3/) 48 | 49 | ### Learning materials 50 | 51 | - [The State of Python (2 vs 3)](http://docs.python-guide.org/en/latest/starting/which-python/#the-state-of-python-2-vs-3) 52 | - [Properly Installing Python](http://docs.python-guide.org/en/latest/starting/installation/) 53 | - [Python Koans](https://github.com/gregmalcolm/python_koans) teaches Python in bitesize chunks using TDD 54 | - [Learn Python The Hard Way](http://learnpythonthehardway.org/) (for people new to programming) 55 | - [Python Programming FAQ](https://docs.python.org/3/faq/programming.html) 56 | - [Writing Great Python Code](http://docs.python-guide.org/en/latest/#writing-great-python-code) 57 | - [Beyond PEP 8 -- Best practices for beautiful intelligible code (PyCon 2015)](https://www.youtube.com/watch?v=wf-BqAjZb8M) 58 | - [Learning Python on the move in bitesized chunks via mobile apps](https://www.sololearn.com/Course/Python/) 59 | - [Plural Sight video tutorials (requires subscription)](https://www.pluralsight.com/browse/software-development/python) 60 | 61 | ## Writing idiomatic Python 62 | ### The Zen of Python 63 | 64 | $ python 65 | Python 2.7.3 (default, Feb 18 2013, 13:30:57) 66 | [GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.24)] on darwin 67 | Type "help", "copyright", "credits" or "license" for more information. 68 | >>> import this 69 | The Zen of Python, by Tim Peters 70 | 71 | Beautiful is better than ugly. 72 | Explicit is better than implicit. 73 | Simple is better than complex. 74 | Complex is better than complicated. 75 | Flat is better than nested. 76 | Sparse is better than dense. 77 | Readability counts. 78 | Special cases aren't special enough to break the rules. 79 | Although practicality beats purity. 80 | Errors should never pass silently. 81 | Unless explicitly silenced. 82 | In the face of ambiguity, refuse the temptation to guess. 83 | There should be one-- and preferably only one --obvious way to do it. 84 | Although that way may not be obvious at first unless you're Dutch. 85 | Now is better than never. 86 | Although never is often better than *right* now. 87 | If the implementation is hard to explain, it's a bad idea. 88 | If the implementation is easy to explain, it may be a good idea. 89 | Namespaces are one honking great idea -- let's do more of those! 90 | 91 | ### Code style 92 | 93 | The authoritative style guide for python is [PEP8](http://pep8.org/). 94 | 95 | You can automatically detect style violations with a tool such as [Flake8](http://flake8.pycqa.org/en/latest/) or [Pylint](https://www.pylint.org/). 96 | -------------------------------------------------------------------------------- /ways-of-learning/running-petal.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Running PETAL 3 | weight: 50 4 | last_reviewed_on: 2025-02-13 5 | review_in: 6 months 6 | --- 7 | 8 | # Running PETAL 9 | 10 | Project Early Talent Assigned Learning (PETAL) is usually led by one or two GDS software developers as a 12-week semester, for one day per week. 11 | 12 | Your aim is to help participants achieve their own learning goals. Consider tailoring your approach with the needs of your participants. 13 | 14 | Below are some recommendations. 15 | 16 | ## Preparing for the semester 17 | 18 | - Pick your PETAL day. This tends to be a Friday, though any working day could work 19 | - Figure out your semester code (e.g. `2025-1`, where `1` indicates the first semester of 2025) 20 | - Figure out the start and end date of your semester 21 | - Start a private Google Group for semester participants. You'll want this fairly locked down as it's really just for managing calendar events 22 | - Create Google Calendar events for each semester day 23 | - Invite the new semester Google Group, so when participants are added to this group they will automatically be invited to the calendar events 24 | - One morning slot from 10am to 1pm, then an afternoon from 2pm to 5pm. This allows participants (and yourself) an easy way block out the time and warn others off of double booking 25 | - A standup slot at 9.45am to 10am 26 | - You may also want to consider scheduling some retrospectives and demos 27 | - Create a private Slack channel for the group (something like #petal-semester-2025-1) 28 | - Create a Google Drive folder for managing the semester, share this folder with anyone helping run the semester 29 | - Create a Google Form for participants to fill in to sign up 30 | - Put this in the new Google Drive folder 31 | - Turn on email notifications (Responses tab > three dot menu > "Get email notifications for new responses") 32 | - Consider the following questions: 33 | - What do you like to be called? 34 | - What is your Slack handle? 35 | - What program are you in? 36 | - What team are you in? 37 | - What is your [GDaD role](https://ddat-capability-framework.service.gov.uk/) (previously DDaT)? 38 | - Who is your line manager? 39 | - Who is your delivery manager? 40 | - What do you want to learn? 41 | - Do you have any project ideas? 42 | - How would you like to be supported during the semester? 43 | - Is there anything we could do to increase the value you get out of the semester? 44 | - Is there anything you would like to ask? 45 | - Start looking for tech talk speakers and scheduling them into the group calendar 46 | 47 | 48 | ## Enrolling participants 49 | 50 | - Post a comment in [#proj-early-talent-assigned-learning](https://gds.slack.com/archives/C05599LTS0J) introducing the new semester, yourselves and pointing anyone who wants to sign up to the Google Form you created 51 | - Consider sharing this comment in [#network-line-managers](https://gds.slack.com/archives/CADAL0813) 52 | - Create a list of potential participants (students on placement, apprentices and juniors in GDS) 53 | - Directly message each on Slack with a brief intro and pointing to your first comment in the PETAL channel 54 | - Follow up if you hear nothing back 55 | - Schedule an onboarding call for each participant 56 | - On the call, work together to come up with a learning plan based on their form inputs and what you learn in the call. This may end up needing a couple meetings to narrow down options 57 | - Look to help them appropriately scope the project for the time available in order to achieve their goals 58 | - You may start seeing opportunities to pair some participants up 59 | - Also ask them if their line manager is OK with their PETAL commitment 60 | - After the call invite them to the Google Group and Slack channel 61 | - A week before the semester starts, check in with all participants. Check the project and goals still work for them 62 | 63 | ## Each day of the semester 64 | 65 | - As standups, particpants can detail whay they are going to be getting up to today and if they know they would like some support 66 | - During the day, check in with each participant 67 | - Consider keep a register for group calls (standups, talks etc) 68 | - Every two to three weeks check each participant is doing well on their project, it's direction and assess if they need further support they have not asked for yet 69 | - Generally it tends to be quieter in the morning and busier in the afternoon 70 | 71 | ## Finding the next lead 72 | 73 | - During the semester, start looking for the next software developer(s) that want to run the next semester 74 | - Ideally they would start planning the next semester a few weeks before the end of your semester 75 | - Some of your participants may continue into the next semester -------------------------------------------------------------------------------- /career-path/working-practices/planning-and-estimating.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 30 3 | last_reviewed_on: 2020-03-30 4 | review_in: 6 months 5 | title: Planning and estimating 6 | --- 7 | 8 | # Planning and estimating 9 | 10 | ## The developer's role 11 | 12 | Estimating and measuring the development effort and cost of building and maintaining software is essential for developers. These skills are useful in informing decisions and guiding delivery. 13 | 14 | Estimating tasks feeds in to the work at various levels. Day to day, estimating on individual stories helps us manage scope through a sprint. Estimating larger ongoing pieces of work over several sprints helps us in our [quarterly planning cycles][quarterly-planning]. Estimating over quarters feeds in to our larger yearly roadmaps. 15 | 16 | There are many ways to estimate tasks or stories, for example, we can estimate how long it would take for a single developer to do the work, or we could estimate how difficult we think the work is. Each has advantages and disadvantages and it should be up to each team to decide how best to estimate work. 17 | 18 | Because estimating how long it will take to build a piece of software is [notoriously][dan-north] [difficult][quora], we can use abstract measures such as effort required or complexity of a piece of work. Estimation should be a team sport and we often use [planning poker][planning-poker] to size or estimate stories. 19 | 20 | Some abstract estimation methods are: 21 | 22 | * Fibonacci numbers. Fibonacci numbers are 0, 1, 2, 3, 5, 8.... Assigning a Fibonacci number to a story allows teams to consider the complexity of a taks. As the numbers become higher, they increase in "distance" from the previous number which reflects the fact that larger or more complex tasks often have greater uncertainty. 23 | 24 | * T-shirt sizing. This is a method of estimating the complexity of a task in relation to other tasks using T-shirt sizes; so tasks would be estimated as "small", "medium" or "large". 25 | 26 | * Range or best and worst case. Using either Fibonacci or T-shirt sizing (or other abstract measure), you assign a range or best and worst case to a story. 27 | 28 | Sometimes there are just too many unknowns to a piece of work and it's impossible to make even a best guess at the complexity or effort involved. It's often a good idea, when faced with this, to put aside some time for a spike to investigate the problem a little more. A spike is usually a timeboxed investigation in to a problem, the outputs of which should be to come back to planning with a better idea of the effort involved in actually implementing the work. 29 | 30 | However your team chooses to estimate stories, it is important to remember that estimates are just that. They are best guesses given your current understanding of the domain and problem. They are not hard and fast commitments. As you work through a story and a project, your estimate of the complexity, effort or time to complete it will probably change. 31 | 32 | [quarterly-planning]: https://gds.blog.gov.uk/2017/08/14/quarterly-missions-a-new-way-of-working/ 33 | [dan-north]: https://dannorth.net/2009/07/01/the-perils-of-estimation/ 34 | [quora]: https://www.quora.com/Engineering-Management/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3/answer/Michael-Wolfe?srid=24b&share=1 35 | [planning-poker]: http://en.wikipedia.org/wiki/Planning_poker 36 | 37 | ### Junior level 38 | 39 | You can estimate how long it will take to to develop some simple and well defined functionality in code bases with which you are familiar. How accurate your estimations are in retrospect will probably vary a fair amount as you gain experience. Given a todo list application, a well defined piece of functionality might be "add a new DateTime field to the todo_lists table and default it to the time the row was inserted". 40 | 41 | ### Mid level 42 | 43 | You understand the trade offs between various implementations of a solution within a project. 44 | 45 | You estimate the complexity of various solutions to a story within a project. 46 | 47 | You actively feed in to planning sessions and estimate complexity in terms of effort or time for stories in a sprint. 48 | 49 | You understand and can identify technical challenges that might block a story up front. 50 | 51 | You understand and can identify when stories rely on input from outside the team (e.g. user testing) and estimate appropriately. 52 | 53 | You understand and can estimate complexity in code bases that you are less familiar with. 54 | 55 | You can identify when there is not enough information to estimate a story successfully. 56 | 57 | ### Senior level 58 | 59 | You understand the trade offs between various implementations for epics that touch multiple projects or code bases. 60 | 61 | You understand that often trade-offs introduce technical debt and you record and prioritise technical debt in an appropriate format for your team and programme. 62 | 63 | You have an awareness of work happening in other teams and use that awareness to feed in to your team's plans as well as communicate with the other team. For example you might be aware that another team is planning to use a feature your team is developing. As a senior developer you would mention that in planning and talk with the seniors and tech leads in the other team to keep them informed on your planned work and progress. 64 | 65 | You actively help Delivery and Product managers in planning (sprint and longer term) by explaining the technical challenges and complexity in ways that non-technical audiences understand. 66 | 67 | You keep in mind other commitments that members might have when planning and estimating work (e.g. you keep in mind any support rotas and holiday schedules, training days and community commitments). 68 | 69 | You suggest ways to reduce/change the scope of stories and epics when it becomes clear that they have been scoped in a way that makes it hard to deliver. 70 | 71 | You help Delivery and Product manager modulate the amount and complexity of work being planned so that all developers on your team has work they feel comfortable picking up. For example if you team has a mix of junior and mid level developers, you help the Delivery and Product managers to identify some simpler well defined work for juniors as well as more loosely defined pieces for the mid level developers. 72 | -------------------------------------------------------------------------------- /resources/other/code-reviews.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | last_reviewed_on: 2018-12-03 3 | review_in: 1 month 4 | title: Conducting effective code reviews 5 | --- 6 | # Conducting effective code reviews 7 | 8 | ## What is a code review, and why do it? 9 | 10 | A code review is a quality assurance activity in which at least one developer 11 | (as well as the original author of the code) reviews code in order to spot 12 | mistakes and improve code quality. 13 | 14 | There are many reasons to carry out code reviews and it has nothing to do with 15 | the competency of the original author! These include: 16 | 17 | - Finding defects - 18 | _Spotting bugs before they go into production!_ 19 | - Improving code quality - 20 | _A second (or third!) opinion on the readability and efficiency of the code 21 | often from people with different backgrounds, specialities and experience 22 | levels to the original author._ 23 | - Sharing knowledge - 24 | _Helps familiarise the whole team with changes going into their codebase, often 25 | in areas in which they themselves are not currently working, which may well 26 | help the team's efficiency and speed up future development._ 27 | 28 | ## How to prepare a pull request for code review 29 | 30 | Properly prepared pull requests (PRs) lead to quicker and more efficient code 31 | reviews. 32 | 33 | [How to raise a good pull request](http://www.annashipman.co.uk/jfdi/good-pull-requests.html) is a good explanation of how to do this. 34 | 35 | 36 | 37 | 38 | Different teams have different expectations about exactly what goes into a pull request (for example this [pull request styleguide](https://github.com/alphagov/styleguides/blob/master/pull-requests.md) for GOV.UK). But in general, you should: 39 | 40 | - Keep the PR as small as possible. Often many small PRs are easier to review than one large one. 41 | - Explain any unusual decisions or key points - this saves the reviewer from needing to ask for clarification on your 42 | thought process. 43 | - Include screenshots, GIFs or links where necessary ([example](https://github.com/alphagov/frontend/pull/784)). 44 | This can help to illustrate the end result of the code, highlight changes 45 | made or explain your design choices. 46 | 47 | ## How to receive code review feedback 48 | 49 | - Ask questions if you are not sure. 50 | - Remind yourself that feedback about code is not personal. 51 | - Assume the best intention from the reviewer's comments. 52 | - Push back if you disagree with comments. May help to explain why the code 53 | exists. ("It's like that because of these reasons. Would it be more clear if 54 | I rename this class/file/method/variable?") 55 | - Seek to understand the reviewer's perspective. 56 | - Try to respond to every comment. 57 | 58 | ## How to give an effective code review 59 | 60 | Above all, be kind and empathetic. Make an effort to ensure that the contributor does not feel like they're being attacked or their competency questioned through your feedback. Remember that people don't always understand your intentions via text, so be explicit and seek to understand the author's intent. 61 | 62 | For some tips on how to do this well, see: 63 | 64 | - [Social aspects of code review](https://mtlynch.io/human-code-reviews-1/) 65 | - [Phrasing review comments positively](https://codeahoy.com/2016/04/03/effective-code-reviews/) 66 | 67 | [How to review code](https://gds-way.cloudapps.digital/manuals/code-review-guidelines.html) in the GDS Way contains more detail about what you should consider when reviewing code at GDS. 68 | 69 | ## Tips for streamlining code reviews 70 | Consider running through a checklist before asking for a review or when reviewing somebody else's code. See [checklists for code authors and reviewers](https://engineeringblog.yelp.com/2017/11/code-review-guidelines.html) for some examples. 71 | 72 | If you are using github, you can set up a [pull request template](https://help.github.com/articles/creating-a-pull-request-template-for-your-repository/) to prompt team members to provide enough information when they raise a pull request. 73 | 74 | You can also make code reviews run more smoothly by adopting [common coding conventions](https://gds-way.cloudapps.digital/manuals/programming-languages.html), and [using automated tools](https://gdstechnology.blog.gov.uk/2016/09/30/easing-the-process-of-pull-request-reviews/) to flag minor problems that don't need to be discussed. 75 | 76 | You don't need to have an in depth discussion about every code review comment. Some teams label comments as blocking or non-blocking to give the author a chance to only respond to what is absolutely necessary. 77 | 78 | It's usually helpful to include a link to the story in the PR, to provide more context about why you are making the change. If you use trello, you can use the [github trello poster](https://github.com/emmabeynon/github-trello-poster) tool to automatically update the card with a checklist of all PRs that link to it. 79 | 80 | Some teams automatically deploy PR branches to heroku, so that reviewers can test the branch more easily. This works well for applications that don't need access to protected services or data, for example [GOV.UK frontend](https://github.com/alphagov/govuk-frontend/pull/1075). 81 | 82 | To make sure pull requests are reviewed quickly, you can request reviews from specific people through github, or you can use the [Seal bot](https://github.com/binaryberry/seal) to regularly post a list of pull requests that need reviews to your team's slack channel. 83 | 84 | ## Further reading 85 | - [The art of giving and receiving code reviews](http://www.alexandra-hill.com/2018/06/25/the-art-of-giving-and-receiving-code-reviews/) 86 | - [How to conduct effective code reviews](https://blog.digitalocean.com/how-to-conduct-effective-code-reviews/) 87 | - [The Art of Code Review](https://skillsmatter.com/skillscasts/8085-the-art-of-code-review) (video, 23 minutes) 88 | - [Mozilla Science Lab: Reviewing a contribution](https://mozillascience.github.io/codeReview/review.html) 89 | - [Thoughtbot code review guide](https://github.com/thoughtbot/guides/tree/master/code-review) 90 | - [rOpenSci onboarding guide for reviewers](https://ropensci.github.io/dev_guide/onboarding-guide-for-reviewers.html) 91 | - [10 principles of a good code review](https://dev.to/codemouse92/10-principles-of-a-good-code-review-2eg) 92 | - [Code review tips](https://rubygarage.org/blog/code-review-tips) -------------------------------------------------------------------------------- /resources/languages/ruby.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 60 3 | title: Ruby 4 | last_reviewed_on: 2018-11-16 5 | review_in: 1 year 6 | --- 7 | 8 | # Ruby 9 | 10 | Ruby is an [object oriented][oop-wiki] programming language where a core 11 | concept is providing a good developer experience. It aims to do this by 12 | providing a wide range of features, good readability and following 13 | the [Principle of Least Astonishment][pola-wiki]. 14 | 15 | It is an [interpreted language][interpreted-wiki], and thus does not need a 16 | compilation step. It's known for its flexibility in both syntax and the 17 | language itself. This can allow developers to write readable, 18 | [declarative][declarative-wiki] code. These factors tend to make Ruby a 19 | somewhat slow performing language [compared to others][ruby-go-comparison] - 20 | however Rubyists argue that [Ruby is fast enough][ruby-fast-enough]. 21 | 22 | Ruby came to popularity with the rise in popularity of the 23 | [Ruby on Rails](/resources/frameworks/rails.html.md) web framework. Other popular Ruby projects are 24 | [Sinatra](http://www.sinatrarb.com/), [Jekyll](https://jekyllrb.com/), 25 | [Puppet](https://puppet.com/), [Capistrano](http://capistranorb.com/) and 26 | [SASS](http://sass-lang.com/). 27 | 28 | Ruby is a widely used language within the Government Digital Service, with many 29 | projects using Ruby on Rails and a number using Sinatra. 30 | 31 | ## Starting out 32 | 33 | ### Which version? 34 | 35 | The main and reference implementation of Ruby is known as [MRI 36 | (Matz's Ruby Interpreter)][mri-wiki] and is the focus of this document. 37 | 38 | At the time of writing, using the current stable version of Ruby 2 is a great 39 | choice to work with the language. 40 | 41 | Typically a Ruby developer may be working with a number of projects that may 42 | use different versions of Ruby thus most developers will use a tool such as 43 | [rbenv](http://rbenv.org) or [rvm](https://rvm.io/) to allow them to run 44 | multiple versions of Ruby on their machine. 45 | 46 | It is unusual to need to use a Ruby version before 2.0 and there is little 47 | support for Ruby versions below 1.9. 48 | 49 | #### Setting up on macOS 50 | 51 | macOS ships with a version of Ruby pre-installed, you can run a Ruby script 52 | with: `$ /usr/bin/ruby script.rb` or enter the [REPL][repl] with 53 | `$ /usr/bin/irb` where you can execute Ruby code: 54 | 55 | ``` 56 | 2.2.3 :001 > puts "Hello World" 57 | Hello World 58 | => nil 59 | ``` 60 | 61 | #### Setting up rbenv with [Homebrew](http://brew.sh/) 62 | 63 | rbenv makes it easy to use newer versions of Ruby than the pre-installed 64 | version on MacOS and allows different versions of Ruby for different projects. 65 | 66 | [Homebrew](http://brew.sh/) is a very commonly used package manager for macOS 67 | that will build and install software. 68 | 69 | 1. Install rbenv: 70 | 71 | $ brew install rbenv 72 | 73 | 2. Install [ruby-build](https://github.com/rbenv/ruby-build), which is a rbenv 74 | plugin to add the ability to build ruby versions: 75 | 76 | $ brew install ruby-build 77 | 78 | 3. Update your `~/.bash_profile`: 79 | 80 | $ echo 'eval "$(rbenv init -)"' >> ~/.bash_profile 81 | 82 | If you use [zsh][zsh], update `~/.zshrc` instead. 83 | 84 | 4. Update your current shell environment: 85 | 86 | $ source ~/.bash_profile 87 | 88 | 5. Install your chosen version of Ruby: 89 | 90 | $ rbenv install 2.3.1 91 | 92 | 6. Specify that as the version you'd like to use for this directory/project: 93 | 94 | $ rbenv local 2.3.1 95 | 96 | And if all has gone to plan running `$ ruby -v` should output the version you 97 | installed. eg: 98 | 99 | ``` 100 | ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-darwin14] 101 | ``` 102 | 103 | ### Working with Ruby Projects 104 | 105 | Ruby projects regularly require dependencies, the de-facto method these are 106 | defined and distributed is through [Rubygems](https://rubygems.org/) and 107 | [Bundler](http://bundler.io/). An applications dependencies are installed by 108 | running `bundle install` from the root directory of an application. 109 | 110 | Typically the dependencies of the project provide executable files to run 111 | aspects of a project. Eg a Rails application can be run with 112 | `bundle exec rails --server`. It is common practice to define how to run a Ruby 113 | application through a README file in the root of the project. 114 | 115 | Tasks in a Ruby project will typically be run using [Rake][rake] which, by 116 | convention, will usually run the tests of an application if it is not provided 117 | any arguments. 118 | 119 | ### Ruby Test Frameworks 120 | 121 | Testing is a popular topic among Rubyists with different opinions and 122 | approaches. Concepts such as [Test-Driven Development (TDD)][tdd-wiki] and 123 | [Behaviour-Driven Development (BDD)][bdd-wiki] are popular, as are [simpler 124 | approaches][dhh-testing]. 125 | 126 | One of the most widely used tools for testing in Ruby is [RSpec][rspec]. RSpec 127 | employs a natural language approach to describing tests and their expected 128 | outcome. Well constructed RSpec tests can be very readable in both their source 129 | code and in the output of running the tests. 130 | 131 | [Minitest][minitest] is a testing framework which is installed as part of Ruby 132 | and is considered a successor to [Test::Unit][test-unit] - the other 133 | (and original) test framework that was installed with Ruby. Minitest has an 134 | emphasis on fast and simple testing, although it provides a number of 135 | libraries that can make it very feature rich. 136 | 137 | Another commonly used tool for testing in Ruby is [Cucumber][cucumber], which 138 | enables tests to be written and/or understand by non technical people. It is 139 | argued that Cucumber is not a testing tool as such and more a 140 | [collaboration tool][cucumber-collaboration] in that it enables those that 141 | define software a means to specify it’s requirements, and those that deliver 142 | software to demonstrate the software meets those requirements. 143 | 144 | A popular tool for testing web applications in Ruby is [Capybara][capybara], 145 | which can be used in conjunction with most Ruby testing frameworks. Capybara 146 | provides the means to specify a users actions on a web application and will 147 | interface with browser software to action them. 148 | 149 | ### Additional Tools 150 | 151 | - [Rubocop](http://rubocop.readthedocs.io/en/latest/) 152 | - [pry-byebug](https://github.com/deivid-rodriguez/pry-byebug) 153 | 154 | ### Reference documentation 155 | 156 | - [Ruby documentation](https://www.ruby-lang.org/en/documentation/) 157 | - [Ruby core and standard library APIs](https://ruby-doc.org/) 158 | 159 | ### Learning materials 160 | 161 | - [Regular expression tester](http://rubular.com/) 162 | - [Poignant Guide to Ruby](http://poignant.guide/) 163 | 164 | ### Code style 165 | 166 | - [GDS Style Guide](https://gds-way.cloudapps.digital/manuals/programming-languages/ruby.html) 167 | - [Community Style Guide](https://github.com/bbatsov/ruby-style-guide) 168 | - [Github Style Guide](https://github.com/styleguide/ruby) 169 | - [Better specs](http://betterspecs.org/) 170 | 171 | ### Additional resources 172 | [oop-wiki]: https://en.wikipedia.org/wiki/Object-oriented_programming 173 | [pola-wiki]: https://en.wikipedia.org/wiki/Principle_of_least_astonishment 174 | [interpreted-wiki]: https://en.wikipedia.org/wiki/Interpreted_language 175 | [declarative-wiki]: https://en.wikipedia.org/wiki/Declarative_programming 176 | [ruby-go-comparison]: https://web.archive.org/web/20171112101316/http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=yarv&lang2=go 177 | [ruby-fast-enough]: https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-years-afff4a54abc7#.ibnrrqrki 178 | [mri-wiki]: https://en.wikipedia.org/wiki/Ruby_MRI 179 | [tdd-wiki]: https://en.wikipedia.org/wiki/Test-driven_development 180 | [bdd-wiki]: https://en.wikipedia.org/wiki/Behavior-driven_development 181 | [dhh-testing]: http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html 182 | [rspec]: http://rspec.info/ 183 | [minitest]: http://docs.seattlerb.org/minitest/ 184 | [test-unit]: http://test-unit.github.io/ 185 | [cucumber]: https://cucumber.io 186 | [cucumber-collaboration]: https://cucumber.io/blog/2014/03/03/the-worlds-most-misunderstood-collaboration-tool 187 | [capybara]: http://teamcapybara.github.io/capybara/ 188 | [rake]: https://github.com/ruby/rake 189 | [repl]: https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop 190 | [zsh]: http://www.zsh.org/ 191 | -------------------------------------------------------------------------------- /resources/languages/css.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 10 3 | last_reviewed_on: 2018-11-16 4 | review_in: 1 year 5 | title: CSS 6 | --- 7 | 8 | # CSS 9 | 10 | Cascading Style Sheets (CSS) is a style sheet language used to describe 11 | the presentation of a document written in HTML. CSS is one of the three 12 | key technologies behind the World Wide Web, HTML and JavaScript being 13 | the other two. 14 | 15 | CSS allows a developer to separate a pages presentation layer away from 16 | the content of the page (marked up using HTML) and page interaction (applied 17 | using JavaScript). With CSS you can control the look and feel of a single page, 18 | or a whole website from a single file. Some of the properties you can control 19 | include `font`, `color`, `background-color`, and an elements `margin` and padding. 20 | 21 | It is even possible to customise the layout of a page / website depending on 22 | what device the page is viewed on. For example if a user is viewing on a mobile 23 | device then they will recieve a specifically optimised view for smaller screens. 24 | This feature is extremely important when it comes to accessibility where a user may 25 | access a page via a screenreader or Braille-based tactile devices. Being able to 26 | serve a high-contrast CSS version of your website is vital for users with low-vision. 27 | 28 | The word "cascading" comes from the fact that more than one set of rules can apply to a 29 | single element. Which rule takes priority is well defined and predictable. 30 | 31 | ## Brief history 32 | - Oct 1994 - First proposed by Håkon Wium Lie while working at CERN. 33 | - Dec 1996 - W3C CSS Recommendation 1 (CSS1) was released. 34 | - Nov 1997 - W3C CSS Recommendation 2 (CSS2) was created. 35 | - May 1998 - W3C CSS Recommendation 2 (CSS2) was released, tackling issues that had not been addressed with CSS level 1. 36 | - Jun 1999 - W3C CSS Recommendation 3 (CSS3) first drafts started. 37 | - Feb 2004 - W3C CSS Recommendation 2.1 became a Candidate Recommendation (CR), created to fix errors in CSS 2, remove poorly supported or not fully interoperable features. 38 | - Jun 2005 - W3C CSS Recommendation 2.1 reverted back to Working Draft (WD) for further review. 39 | - Jul 2007 - W3C CSS Recommendation 2.1 returned to Candidate Recommendation (CR) status. 40 | - Jun 2011 - W3C CSS Recommendation 2.1 receives full Recommendation status from the W3C. 41 | - Jun 2011 - W3C CSS Recommendation 3 (CSS3) doesn't actually exist. CSS functionality is split down into separate modules with each moving independently towards standardisation at their own pace. CSS4 will never exist for the same reason. The CSS Working Group sometimes publishes "Snapshots" which gives an overview of completed modules and drafts. 42 | - Sept 2011 - Selectors Level 3 becomes a formal W3C recommendation. 43 | - Jun 2012 - Media Query module becomes a formal W3C recommendation. 44 | 45 | For more information of the status of CSS3 modules see [here](https://en.wikipedia.org/wiki/Cascading_Style_Sheets#CSS_3). 46 | 47 | ## Starting out 48 | CSS is a simple language to start using but one that is difficult to master. This is mainly due to the fact that 49 | different (non-compliant) browsers interpret the same CSS slightly differently. This has improved dramatically 50 | since the introduction of ['evergreen' browsers](https://www.techopedia.com/definition/31094/evergreen-browser), but it is still worth considering and testing your pages on 51 | older browsers. 52 | 53 | To start first you will need to create a simple HTML page and include a style tag. This will render the content in the 54 | browser and allow you to 'style' the content as you see fit. 55 | 56 | ```html 57 | 58 | 59 | 60 | 61 | 62 | 63 | Simple CSS page 64 | 65 | 104 | 105 | 106 | 107 | 108 | 109 |

This is a page title

110 |

This is a paragraph tag

111 | 116 |

This paragraph tag is styled to be more prominant on the page.

117 |
118 |

Sub header on the page

119 |

Sub-section copy is here in a paragrapgh tag. I can link to this sub-header directly like so.

120 |
121 | 122 | 123 | ``` 124 | 125 | The example above shows the primary ways to target an element on a page for styling and these are called selectors. You can select an element using the following methods: 126 | 127 | - use a tag (e.g. body, h1, p) 128 | - use a class (e.g. .bold-message) 129 | - use an ID (e.g. #sub-section-header) 130 | 131 | The key to working with CSS is understanding that properties cascade. So a single element can be 132 | affected by multiple CSS selectors. Which property wins in this battle is well defined in browsers and is called CSS specificity. 133 | 134 | A selector's specificity is calculated as follows. Note this is a simplified version. See the [CSS specifications](https://www.w3.org/TR/selectors-3/#specificity) 135 | for much more detail: 136 | 137 | - count the number of ID selectors in the selector (a) 138 | - count the number of class selectors (b) 139 | - count the number of type selectors (c) 140 | 141 | The selector with the largest overall score wins. If two selectors have the same score then the latter 142 | selector will overwrite the first. 143 | 144 | 145 | ### CSS specificity examples 146 | Here you will find some examples of CSS specificity with the corresponding scores: 147 | 148 | ```css 149 | body {background: red;} /* id(a)=0, class(b)=0, type(c)=1, specificity=1 */ 150 | p.bold-message {font-size: 20px;} /* id(a)=0, class(b)=1, type(c)=1, specificity=11 */ 151 | div p {color: white;} /* id(a)=0, class(b)=0, type(c)=2, specificity=2 */ 152 | #sub-section-header {text-decoration: underline;} /* id(a)=1, class(b)=0, type(c)=0, specificity=100 */ 153 | body div.section-class h2#sub-section-header {color: pink;} /* id(a)=1, class(b)=1, type(c)=3, specificity=113 */ 154 | ``` 155 | 156 | And when two selectors have an identical score: 157 | 158 | ```css 159 | /* 160 | both selectors below have the same score so the last rule overwrites the first 161 | and the paragraph will be coloured red. 162 | */ 163 | .section-class p {color: blue;} /* id(a)=0, class(b)=1, type(c)=1, specificity=11 */ 164 | p.sub-section-para {color: red;} /* id(a)=0, class(b)=1, type(c)=1, specificity=11 */ 165 | ``` 166 | 167 | 168 | ## Reference documentation 169 | - [MDN CSS Reference guide](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference) 170 | - [Codrops Css reference](https://tympanus.net/codrops/css_reference/) 171 | - [CSSReference](https://cssreference.io/) 172 | 173 | 174 | ## Learning materials 175 | - [HTMLDog CSS Beginners course](http://www.htmldog.com/guides/css/) 176 | - [Learn CSS Layout](http://book.mixu.net/css/) 177 | - [Introduction to CSS Screencast series](https://scrimba.com/g/gintrotocss) 178 | - [Layout Land YouTube Series](https://www.youtube.com/channel/UC7TizprGknbDalbHplROtag) 179 | - [The complete guide to Flexbox](https://css-tricks.com/snippets/css/a-guide-to-flexbox/) 180 | - [The complete guide to CSS Grid](https://css-tricks.com/snippets/css/complete-guide-grid/) 181 | - [Grid by example](https://gridbyexample.com/) 182 | - [CSS positioning types](https://scotch.io/bar-talk/5-things-you-might-not-know-about-the-css-positioning-types) 183 | - [CSS Guidelines](https://cssguidelin.es/) 184 | - [An Introduction to the BEM Methodology](https://webdesign.tutsplus.com/articles/an-introduction-to-the-bem-methodology--cms-19403) 185 | 186 | 187 | ## Books 188 | - [The new CSS Layout](https://abookapart.com/products/the-new-css-layout) [ebook, print] 189 | - [Handcrafted CSS](https://www.amazon.co.uk/Handcrafted-CSS-Bulletproof-Design-Voices/dp/0321643380) [ebook, print] 190 | - [CSS: The Definitive Guide, Fourth Edition](https://meyerweb.com/eric/books/css-tdg/) 191 | 192 | 193 | ## Code style 194 | - [CSSLint](https://github.com/CSSLint/csslint) 195 | - [SCSSLint](https://github.com/brigade/scss-lint) 196 | 197 | 198 | ## Additional Tools 199 | - [Sass: Syntactically Awesome StyleSheets](https://sass-lang.com/) 200 | - [Less: Leaner Style Sheets](http://lesscss.org/) 201 | - [Can I Use](https://caniuse.com/) 202 | -------------------------------------------------------------------------------- /resources/languages/javascript.html.md: -------------------------------------------------------------------------------- 1 | --- 2 | weight: 30 3 | last_reviewed_on: 2018-11-16 4 | review_in: 1 year 5 | title: Javascript 6 | --- 7 | # JavaScript 8 | 9 | JavaScript (JS) is a high-level, interpreted programming language. It 10 | is one of the three core technologies that are used on the World Wide Web, 11 | alongside HTML and CSS. All major web browser have a dedicated JavaScript engine 12 | that is used to execute it. "JavaScript" is not to be confused with "Java". 13 | Both are trademarks or registered trademarks of Oracle, but they have 14 | very different syntax, semantics, and uses. 15 | 16 | Although mainly embedded in web browsers, many non-browser environments also 17 | use the language. These include [node.js](https://nodejs.org/en/) and 18 | [Apache CouchDB](https://couchdb.apache.org/). 19 | 20 | JavaScript is used in the browser to program how a web page behaves on the 21 | occurrence of a particular event. These events can be triggered by the users 22 | or programmatically through other means. It is important to remember 23 | that JavaScript can fail to load in the browser and there are [many different reasons](https://www.gov.uk/service-manual/technology/using-progressive-enhancement#dont-assume-users-turn-off-javascript) 24 | why this can happen, so make sure the website content can still be viewed 25 | with JavaScript disabled. This consideration is an important 26 | part of the [progressive enhancement](https://www.gov.uk/service-manual/technology/using-progressive-enhancement) 27 | technique that we follow at GDS. 28 | 29 | 30 | ## Brief history 31 | - May 1995 - Brendan Eich creates the first version of JavaScript (called Mocha) and includes it in Netscape Communicator (prototype). 32 | - Aug 1996 - Microsoft creates its own version called JScript and includes it in Internet Explorer 3.0. 33 | - Sep 1996 - Netscape releases Netscape Navigator 2.0 and renames Mocha to JavaScript. 34 | - Nov 1996 - TC-39 committee formed to standardise JavaScript. This standard is known as ECMA-262. 35 | - Jun 1997 - [Version 1](http://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%201st%20edition,%20June%201997.pdf) of the ECMAScript standard is released (ES1). 36 | - Aug 1998 - [Version 2](https://www-archive.mozilla.org/js/language/E262-2.pdf) of the ECMAScript standard is released (ES2). 37 | - Dec 1999 - [Version 3](http://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%203rd%20edition,%20December%201999.pdf) of the ECMAScript standard is released (ES3), bringing a large number of language changes with it including `XMLHttpRequest`. Ajax was born. 38 | - Dec 1999 - Work on the next standard, ES4 was started but was eventually abandoned after 8 years due to political differences concerning language complexity. 39 | - Dec 2009 - Version 3.1 of the standard is released, which is later renamed to version 5 (ES5) 40 | - Jun 2011 - Version 5.1 of the ECMAScript standard is released with small clarifications but no new features. 41 | - Jun 2015 - Version 6 of the ECMAScript standard (ES6) which includes a whole host of new language features including classes, modules, Python-style generators, arrow functions, binary data, typed arrays, collections (maps, sets and weak maps), and promises. ECMAScript 6 is later renamed to ECMAScript 2015 to follow the year of release and this sets the new naming convention for the future. 42 | - Jun 2016 - Version 7 of the ECMAScript standard is released (ES2016). New features include the exponentiation operator (`**`), `Array.prototype.includes.` 43 | - Jun 2017 - Version 8 of the ECMAScript standard is released (ES2017). Includes async/await, which works using generators and promises. 44 | - Jun 2018 - Version 9 of the ECMAScript standard is in draft (ES2018). It will eventually include rest/spread properties, asynchronous iteration, Promise.prototype.finally() and additions to RegExp. 45 | 46 | 47 | ## Starting out 48 | It is incredibly simple to start working with JavaScript as it's interpreter is bundled with every 49 | web browser. In Chrome or Firefox simply press CMD + ALT + i (CTRL + ALT + i on Windows) to bring up 50 | the developer tools console. In the console window you can type any JavaScript you want the browser 51 | to execute. For example: 52 | 53 | ```javascript 54 | 100 + 33 55 | // output: 133 56 | 57 | alert('Hello world!'); 58 | // an alert box will pop up in the browser 59 | ``` 60 | 61 | To have JavaScript execute in a page on page load you will need to include it inside a script tag 62 | in your HTML page. A very simple boilerplate for this can be found below: 63 | 64 | ```html 65 | 66 | 67 | 68 | 69 | 70 | 71 | JavaScript Boilerplata 72 | 73 | 74 |

This is a simple boilerplate page

75 | 76 | 77 | 84 | 85 | 86 | 87 | 88 | 89 | ``` 90 | 91 | The above example gives you an idea of how to execute JavaScript code int he browser. For more 92 | information on JavaScript usage refer to the resources listed below. When starting out with 93 | browser based JavaScript it is recommended you learn about how events work and the Document 94 | Object Model (DOM) as these two topics are key to adding JavaScript interaction to a webpage. 95 | 96 | 97 | ## Simple examples 98 | Below you will find a few simple examples of the JavaScript language syntax: 99 | 100 | ```javascript 101 | /** 102 | Variables and data types 103 | */ 104 | var myNumber = 10; 105 | var myBoolean = true; 106 | var myString = "Hello world"; 107 | var myArray = [1,2,3,4,5] 108 | var myObject = { 109 | key: "value" 110 | } 111 | ``` 112 | 113 | ```javascript 114 | /** 115 | Operators 116 | */ 117 | 118 | // addition 119 | 2 + 2; // number 120 | "Firstname " + "Lastname"; // string 121 | 122 | // subtraction, multiplication, division 123 | 6 - 4; 124 | 3 * 10; 125 | 25 / 5; 126 | 127 | // assignment 128 | var myVariable = 3; 129 | 130 | // equality 131 | myVariable === 4; // returns boolean (false) 132 | 133 | // not equal to 134 | myVariable !== 20; // returns boolean (true) 135 | ``` 136 | 137 | ```javascript 138 | /** 139 | Conditionals 140 | */ 141 | var name = "John Smith"; 142 | if(name === "John Smith"){ 143 | alert("Pleased to meet you John Smith!"); 144 | } else { 145 | alert("Hello stranger, nice to meet you!"); 146 | } 147 | ``` 148 | 149 | ```javascript 150 | /** 151 | Functions 152 | */ 153 | function foo(param1, param2){ 154 | var output = param1 + param2; 155 | 156 | return output; 157 | } 158 | 159 | foo("hello ", "world"); // "hello world" 160 | foo(2, 4); // 6 161 | ``` 162 | 163 | ```Javascript 164 | /** 165 | Loops 166 | */ 167 | for(var i=0;i<=10;i++){ 168 | console.log(i); 169 | } 170 | // 0 1 2 3 4 5 6 7 8 9 10 171 | var j = 0; 172 | 173 | while(j<3){ 174 | console.log('String'); 175 | 176 | j++; 177 | } 178 | // String String String 179 | ``` 180 | 181 | 182 | ### Reference documentation 183 | - [MDN web docs - JavaScript](https://developer.mozilla.org/bm/docs/Web/JavaScript) 184 | - [DevDocs](http://devdocs.io/javascript) 185 | - [Modern JavaScript Cheatsheet](https://github.com/mbeaudru/modern-js-cheatsheet) 186 | - [Simplified JavaScript Jargon](http://jargon.js.org/) 187 | 188 | 189 | ### Learning materials 190 | - [Stack Overflow questions tagged JavaScript](https://stackoverflow.com/questions/tagged/javascript) 191 | - [Frontend Masters](https://frontendmasters.com/) 192 | - [Udemy Understand JavaScript](https://www.udemy.com/understand-javascript/learn/v4/overview) 193 | - [Udacity JavaScript Basics](https://www.udacity.com/course/javascript-basics--ud804) 194 | - [ES6.io](https://es6.io/) 195 | - [CodeAcademy](https://www.codecademy.com/learn/javascript) 196 | - [Code School](https://www.codeschool.com/learn/javascript) 197 | 198 | 199 | ### Books 200 | - [Eloquent JavaScript - second edition](http://eloquentjavascript.net/) [online, ebook] 201 | - [Speaking JavaScript](http://speakingjs.com/es5/) [online, ebook, print] 202 | - [Exploring ES6](http://exploringjs.com/es6/) [online, ebook, print] 203 | - [You Don’t Know JS](https://github.com/getify/You-Dont-Know-JS) [online, ebook, print] 204 | - [JavaScript Design Patterns](https://addyosmani.com/resources/essentialjsdesignpatterns/book/) [online, ebook, print] 205 | - [Effective JavaScript](http://www.informit.com/store/effective-javascript-68-specific-ways-to-harness-the-9780321812186) [print] 206 | - [JavaScript Allongé, the "Six" Edition](https://leanpub.com/javascriptallongesix/read) [online, ebook, print] 207 | - [Object-orientated JavaScript](https://www.amazon.co.uk/Object-oriented-JavaScript-Second-Stoyan-Stefanov/dp/1849693129/ref=dp_ob_title_bk) [print] 208 | - [High Performance JavaScript](http://shop.oreilly.com/product/9780596802806.do) [print] 209 | - [JavaScript Patterns](http://shop.oreilly.com/product/9780596806767.do) [print] 210 | - [ES6 for Humans](https://github.com/metagrover/ES6-for-humans) [print, online, ebook] 211 | - [JavaScript: The Good Parts](http://shop.oreilly.com/product/9780596517748.do) 212 | - [DOM Enlightenment](http://domenlightenment.com/) 213 | 214 | 215 | ### Code style 216 | - [JSHint](http://jshint.com/) 217 | - [JSLint](https://www.jslint.com/) 218 | - [ESLint](https://eslint.org/) 219 | 220 | 221 | ### Additional Tools 222 | - [Gulp](https://gulpjs.com/) 223 | - [Grunt](https://gruntjs.com/) 224 | - [Webpack](https://webpack.js.org/) 225 | - [Browserify](http://browserify.org/) 226 | --------------------------------------------------------------------------------