├── .gitignore ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── LICENSE └── README.md /.gitignore: -------------------------------------------------------------------------------- 1 | *.swp 2 | *.swo 3 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Contributor Covenant Code of Conduct 2 | 3 | ## Our Pledge 4 | 5 | In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. 6 | 7 | ## Our Standards 8 | 9 | Examples of behavior that contributes to creating a positive environment include: 10 | 11 | * Using welcoming and inclusive language 12 | * Being respectful of differing viewpoints and experiences 13 | * Gracefully accepting constructive criticism 14 | * Focusing on what is best for the community 15 | * Showing empathy towards other community members 16 | 17 | Examples of unacceptable behavior by participants include: 18 | 19 | * The use of sexualized language or imagery and unwelcome sexual attention or advances 20 | * Trolling, insulting/derogatory comments, and personal or political attacks 21 | * Public or private harassment 22 | * Publishing others' private information, such as a physical or electronic address, without explicit permission 23 | * Other conduct which could reasonably be considered inappropriate in a professional setting 24 | 25 | ## Our Responsibilities 26 | 27 | Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. 28 | 29 | Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. 30 | 31 | ## Scope 32 | 33 | This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. 34 | 35 | ## Enforcement 36 | 37 | Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at rafaeltravel88@gmail.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. 38 | 39 | Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. 40 | 41 | ## Attribution 42 | 43 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version] 44 | 45 | [homepage]: http://contributor-covenant.org 46 | [version]: http://contributor-covenant.org/version/1/4/ 47 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | ## Guidelines 2 | 3 | 1. It is ok to replace a link of an existing subject to another more detailed or didactic one; 4 | 2. Try to be organized. Follow the same layout as the existing one, or you can suggest a better one; 5 | 3. You can create another resource topic, but be sure that it is about software development; 6 | 4. Try to avoid a new resource which requires a knowledge of a specific programming language to understand the concept; 7 | 5. All the content must be in English or must have an English subtitle; 8 | 6. Feel free to share and contribute. 9 | 10 | ## Submitting 11 | 12 | 1. Fork this repository; 13 | 2. Create your feature branch (git checkout -b my-contrib); 14 | 3. Commit your changes (git commit -am 'Add some link'); 15 | 4. Push to the branch (git push origin my-contrib); 16 | 5. Create new Pull Request 17 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2017 Rafael Soares dos Santos 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Contents 2 | - [Summary](#summary) 3 | - [Online Resources](#online-resources) 4 | - [Architectural Patterns](#architectural-patterns) 5 | - [Database](#database) 6 | - [Logging](#logging) 7 | - [Object-Oriented Design](#object-oriented-design) 8 | - [Refactoring](#refactoring) 9 | - [Revision Control](#revision-control) 10 | - [Service-Oriented Architecture](#service-oriented-architecture) 11 | - [Others](#others) 12 | 13 | ## Summary 14 | 15 | This is a curated list of the most didactic and/or deeply detailed must-read resources about software development. 16 | 17 | ## Online Resources 18 | 19 | ### Architectural Patterns 20 | 21 | _Is a general, reusable solution to a commonly occurring problem in software 22 | architecture within a given context. Architectural patterns are similar to software 23 | design pattern but have a broader scope._ 24 | 25 | - Articles / Papers 26 | - [Command Query Responsibility Segregation (CQRS) by Martin Fowler](https://martinfowler.com/bliki/CQRS.html) 27 | - [Event Sourcing](https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing) 28 | - [Getting Started With DDD When Surrounded By Legacy Systems by Eric Evans]( 29 | http://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) 30 | - [Hexagonal Architecture by Alistair Cockburn](http://alistair.cockburn.us/Hexagonal+architecture) 31 | - [The Clean Architecture by Robert C. Martin]( 32 | https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html) 33 | - [The Onion Architecture by Jeffrey Palermo](http://jeffreypalermo.com/blog/the-onion-architecture-part-1/) 34 | 35 | - Books 36 | - [Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans]( 37 | https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215) 38 | 39 | - Videos 40 | - [Architecture the Lost Years by Robert C. Martin](https://www.youtube.com/watch?v=WpkDN78P884) _(The Clean Architecture)_ 41 | - [DDD & Microservices: At Last, Some Boundaries! by Eric Evans](https://www.youtube.com/watch?v=yPvef9R3k-M) 42 | - [What is programming MVC? by J. Alexander Curtis](https://www.youtube.com/watch?v=1IsL6g2ixak) 43 | 44 | ### Database 45 | 46 | _A database is an organized collection of data. It is the collection of schemas, tables, 47 | queries, reports, views, and other objects._ 48 | 49 | - Books 50 | - [SQL Indexing and Tuning by Markus Winand](http://use-the-index-luke.com/) (**_Free web-edition_**) 51 | 52 | ### Logging 53 | 54 | _In computing, a logfile is a file that records either events that occur in an operating system 55 | or other software runs, or messages between different users of a communication software. 56 | Logging is the act of keeping a log._ 57 | 58 | - Articles / Papers 59 | - [Logging levels: the wrong abstraction, by Daniel Lebrero](https://labs.ig.com/logging-level-wrong-abstraction) 60 | - [Tracing Request IDs by Brandur](https://brandur.org/request-ids) 61 | - [The Log: What every software engineer should know about real-time data's unifying abstraction by Jay Kreps]( 62 | https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying) 63 | 64 | ### Object-Oriented Design 65 | 66 | _Object-Oriented Design is the process of planning a system of interacting 67 | objects for the purpose of solving a software problem._ 68 | 69 | - Articles / Papers 70 | - [Applying Design by Contract, by Bertrand Meyer](http://se.ethz.ch/~meyer/publications/computer/contract.pdf) 71 | - [Command Query Separation (CQS) by Firat Atagun](http://www.firatatagun.com/blog/2016/05/28/command-query-seperation-cqs/) 72 | - [Dealing with Properties by Martin Fowler](https://martinfowler.com/apsupp/properties.pdf) 73 | - [GRASP](https://en.wikipedia.org/wiki/GRASP_(object-oriented_design%29 ) 74 | - [Keep It DRY, Shy, and Tell the Other Guy by Andy Hunt and Dave Thomas](http://media.pragprog.com/articles/may_04_oo1.pdf) 75 | - [Tell, Don't Ask](https://pragprog.com/articles/tell-dont-ask) ([Examples](https://robots.thoughtbot.com/tell-dont-ask)) 76 | - [The Law of Demeter Is Not A Dot Counting Exercise by Phil Haack](http://haacked.com/archive/2009/07/14/law-of-demeter-dot-counting.aspx/) 77 | - [SRP: The Single Responsibility Principle]( 78 | https://drive.google.com/file/d/0ByOwmqah_nuGNHEtcU5OekdDMkk/view) 79 | - [The Open-Closed Principle]( 80 | https://drive.google.com/file/d/0BwhCYaYDn8EgN2M5MTkwM2EtNWFkZC00ZTI3LWFjZTUtNTFhZGZiYmUzODc1/view) 81 | - [The Liskov Substitution Principle]( 82 | https://drive.google.com/file/d/0BwhCYaYDn8EgNzAzZjA5ZmItNjU3NS00MzQ5LTkwYjMtMDJhNDU5ZTM0MTlh/view) 83 | - [The Interface Segregation Principle]( 84 | https://drive.google.com/file/d/0BwhCYaYDn8EgOTViYjJhYzMtMzYxMC00MzFjLWJjMzYtOGJiMDc5N2JkYmJi/view) 85 | - [The Dependency Inversion Principle]( 86 | https://drive.google.com/file/d/0BwhCYaYDn8EgMjdlMWIzNGUtZTQ0NC00ZjQ5LTkwYzQtZjRhMDRlNTQ3ZGMz/view) 87 | 88 | - Books 89 | - [Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development by Craig Larman]( 90 | https://www.amazon.com.br/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0131489062) 91 | 92 | - Videos 93 | - [Nothing is Something by Sandi Metz](https://www.youtube.com/watch?v=9lv2lBq6x4A) 94 | - [SOLID Object-Oriented Design by Sandi Metz](https://www.youtube.com/watch?v=v-2yFMzxqwU) 95 | 96 | ### Refactoring 97 | 98 | _Code refactoring is the process of restructuring existing computer code—changing the factoring—without 99 | changing its external behavior. Refactoring improves nonfunctional attributes of the software._ 100 | 101 | - Articles / Papers 102 | - [Code Smells by Jeff Atwood](https://blog.codinghorror.com/code-smells/) 103 | - [Dont Repeat Yourself (DRY) by Andrew Hunt](http://wiki.c2.com/?DontRepeatYourself) 104 | - [On the Criteria To Be Used in Decomposing Systems into Modules by David Parnas]( 105 | https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf) _(Decomposing)_ 106 | - [Towards a Principle-based Classification of Structural Design Smells by Ganesh Samarthyam, Tushar Sharma and Girish Suryanarayana]( 107 | http://www.jot.fm/issues/issue_2013_06/article1.pdf) _(Design Smells)_ 108 | 109 | - Books 110 | - [Refactoring for Software Design Smells: Managing Technical Debtby Ganesh Samarthyam, Tushar Sharma and Girish Suryanarayana]( 111 | https://www.amazon.com/gp/product/0128013974/ref=as_li_tl) 112 | - [Refactoring: Improving the Design of Existing Code by Martin Fowler, Kent Beck, John Brant, William Opdyke and Don Roberts]( 113 | https://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672) 114 | 115 | - Videos 116 | - [Get a Whiff of This by Sandi Metz](https://www.youtube.com/watch?v=PJjHfa5yxlU) _(Code Smells)_ 117 | - [All the Little Things by Sandi Metz](https://www.youtube.com/watch?v=8bZh5LMaSmE) _(Small Objects)_ 118 | 119 | ### Revision Control 120 | 121 | _Revision control is any kind of practice that tracks and provides control over changes to source code._ 122 | 123 | - Articles / Papers 124 | - [Gitflow - A successful Git branching model by Vincent Driessen](http://nvie.com/posts/a-successful-git-branching-model/) 125 | - [GitLab Flow](https://docs.gitlab.com/ee/workflow/gitlab_flow.html) 126 | - [GitHub Flow by Scott Chacon](http://scottchacon.com/2011/08/31/github-flow.html) 127 | - [Git Style Guide by Agis Anastasopoulos](https://github.com/agis/git-style-guide) 128 | 129 | - Books 130 | - [Pro Git by Scott Chacon and Ben Straub](https://git-scm.com/book/en/v2) 131 | 132 | ### Service-Oriented Architecture 133 | 134 | _A service-oriented architecture (SOA) is a style of software design where services are provided 135 | to the other components by application components, through a communication protocol over a network. 136 | The basic principles of service-oriented architecture are independent of vendors, products and technologies._ 137 | 138 | - Articles / Papers 139 | - [SEDA: An Architecture for Well-Conditioned, Scalable Internet Services by Matt Welsh, David Culler and Eric Brewer]( 140 | http://www.sosp.org/2001/papers/welsh.pdf) 141 | - [Twelve-factor App Methodology by Adam Wiggins](https://12factor.net/) 142 | 143 | ### Others 144 | 145 | _Last but not least._ 146 | 147 | - Articles / Papers 148 | - [Learn Regex by Zeeshan Ahmed](https://github.com/zeeshanu/learn-regex) 149 | - [Semantic Versioning Specification (SemVer) by Tom Preston-Werner](http://semver.org/) 150 | - [The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) by Joel Spolsky]( 151 | https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/) 152 | - [Time by Emil Mikulic](https://unix4lyfe.org/time/) 153 | - [The Infinite Hows (or, the Dangers Of The Five Whys) by John Allspaw]( 154 | https://www.kitchensoap.com/2014/11/14/the-infinite-hows-or-the-dangers-of-the-five-whys/) _(Post-hoc/Postmortems)_ 155 | - [What every web developer must know about URL encoding by Stéphane Épardaud]( 156 | https://www.talisman.org/~erlkonig/misc/lunatech%5Ewhat-every-webdev-must-know-about-url-encoding/) 157 | - [What Every Programmer Should Know About Memory by Ulrich Drepper](https://www.akkadia.org/drepper/cpumemory.pdf) 158 | - [What Every Programmer Should Know About SEO by Kate Matsudaira](http://katemats.com/what-every-programmer-should-know-about-seo/) 159 | - [What's the Difference Between Continuous Integration, Continuous Deployment and Continuous Delivery? by Marko Anastasov]( 160 | https://semaphoreci.com/blog/2017/07/27/what-is-the-difference-between-continuous-integration-continuous-deployment-and-continuous-delivery.html) 161 | - [What technical details should a programmer of a web application consider before making the site public?]( 162 | https://softwareengineering.stackexchange.com/questions/46716/what-technical-details-should-a-programmer-of-a-web-application-consider-before) 163 | --------------------------------------------------------------------------------