Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add additional essays published after the book #30

Open
wants to merge 14 commits into
base: master
Choose a base branch
from
Open

Add additional essays published after the book #30

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
14 commits
Select commit Hold shift + click to select a range
f33fe4a
Formatting for thing 78
ollyjshaw Oct 18, 2018
1bde32a
Merge pull request #18 from ollyjshaw/ollyjshaw-patch-1
Semigradsky Oct 19, 2018
6f92692
Update README.md
fureigh Jun 7, 2019
8a774bf
Merge pull request #19 from fureigh/patch-1
Semigradsky Jun 10, 2019
6fa571d
use an ordered list instead of an unordered list
fmeyertoens Sep 26, 2019
01b2e7f
Merge pull request #20 from fmeyertoens/patch-1
Semigradsky Sep 27, 2019
4616033
typo
mdeff Jul 15, 2020
8ed97dd
Merge pull request #22 from mdeff/patch-1
Semigradsky Jul 15, 2020
79addd7
missing parenthesis
mdeff Jul 15, 2020
56c863c
Merge pull request #26 from mdeff/patch-5
Semigradsky Jul 17, 2020
54e522b
Fixed blockquotes problem.
SergeyMormul Sep 5, 2020
444640d
Merge pull request #28 from SergeyMormul/patch-1
Semigradsky Sep 5, 2020
1b6e502
Add additional 68 extended essays
shirishp Oct 10, 2020
b1a1550
Prepend 0 to extended directories less than 10 to make sure they are …
shirishp Oct 10, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .gitignore
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,3 +12,4 @@ _book
# other
.DS_Store

.idea/
4 changes: 2 additions & 2 deletions en/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,6 @@

This is a [GitBook](https://www.gitbook.io) version of the ['97 Things Every Programmer Should Know' project](http://programmer.97things.oreilly.com/wiki/index.php/97_Things_Every_Programmer_Should_Know).

All content is licensed under the [Creative Commons Attribution Non Commercial Share Alike 3.0 license](http://creativecommons.org/licenses/by-nc-sa/3.0/). Print versions of the book are available on [Amazon.com](http://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484).
All content is licensed under the [Creative Commons Attribution-NonCommercial-ShareAlike 3.0 license](http://creativecommons.org/licenses/by-nc-sa/3.0/). Print versions of the book are available on [Amazon.com](http://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484).

If you find any mistakes or have any suggestions, you can [create issue](https://github.com/97-things/97-things-every-programmer-should-know/issues) or [pull request](https://github.com/97-things/97-things-every-programmer-should-know/pulls) to [repository](https://github.com/97-things/97-things-every-programmer-should-know).
If you find any mistakes or have any suggestions, you can [create an issue](https://github.com/97-things/97-things-every-programmer-should-know/issues) or [file a pull request](https://github.com/97-things/97-things-every-programmer-should-know/pulls) to the [repository](https://github.com/97-things/97-things-every-programmer-should-know).
194 changes: 97 additions & 97 deletions en/SUMMARY.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,100 +1,100 @@
# Summary

* [Introduction](README.md)
* [Act with Prudence](thing_01/README.md)
* [Apply Functional Programming Principles](thing_02/README.md)
* [Ask "What Would the User Do?" (You Are not the User)](thing_03/README.md)
* [Automate Your Coding Standard](thing_04/README.md)
* [Beauty Is in Simplicity](thing_05/README.md)
* [Before You Refactor](thing_06/README.md)
* [Beware the Share](thing_07/README.md)
* [The Boy Scout Rule](thing_08/README.md)
* [Check Your Code First before Looking to Blame Others](thing_09/README.md)
* [Choose Your Tools with Care](thing_10/README.md)
* [Code in the Language of the Domain](thing_11/README.md)
* [Code Is Design](thing_12/README.md)
* [Code Layout Matters](thing_13/README.md)
* [Code Reviews](thing_14/README.md)
* [Coding with Reason](thing_15/README.md)
* [A Comment on Comments](thing_16/README.md)
* [Comment Only What the Code Cannot Say](thing_17/README.md)
* [Continuous Learning](thing_18/README.md)
* [Convenience Is not an -ility](thing_19/README.md)
* [Deploy Early and Often](thing_20/README.md)
* [Distinguish Business Exceptions from Technical](thing_21/README.md)
* [Do Lots of Deliberate Practice](thing_22/README.md)
* [Domain-Specific Languages](thing_23/README.md)
* [Don't Be Afraid to Break Things](thing_24/README.md)
* [Don't Be Cute with Your Test Data](thing_25/README.md)
* [Don't Ignore that Error!](thing_26/README.md)
* [Don't Just Learn the Language, Understand its Culture](thing_27/README.md)
* [Don't Nail Your Program into the Upright Position](thing_28/README.md)
* [Don't Rely on "Magic Happens Here"](thing_29/README.md)
* [Don't Repeat Yourself](thing_30/README.md)
* [Don't Touch that Code!](thing_31/README.md)
* [Encapsulate Behavior, not Just State](thing_32/README.md)
* [Floating-point Numbers Aren't Real](thing_33/README.md)
* [Fulfill Your Ambitions with Open Source](thing_34/README.md)
* [The Golden Rule of API Design](thing_35/README.md)
* [The Guru Myth](thing_36/README.md)
* [Hard Work Does not Pay Off](thing_37/README.md)
* [How to Use a Bug Tracker](thing_38/README.md)
* [Improve Code by Removing It](thing_39/README.md)
* [Install Me](thing_40/README.md)
* [Inter-Process Communication Affects Application Response Time](thing_41/README.md)
* [Keep the Build Clean](thing_42/README.md)
* [Know How to Use Command-line Tools](thing_43/README.md)
* [Know Well More than Two Programming Languages](thing_44/README.md)
* [Know Your IDE](thing_45/README.md)
* [Know Your Limits](thing_46/README.md)
* [Know Your Next Commit](thing_47/README.md)
* [Large Interconnected Data Belongs to a Database](thing_48/README.md)
* [Learn Foreign Languages](thing_49/README.md)
* [Learn to Estimate](thing_50/README.md)
* [Learn to Say "Hello, World"](thing_51/README.md)
* [Let Your Project Speak for Itself](thing_52/README.md)
* [The Linker Is not a Magical Program](thing_53/README.md)
* [The Longevity of Interim Solutions](thing_54/README.md)
* [Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly](thing_55/README.md)
* [Make the Invisible More Visible](thing_56/README.md)
* [Message Passing Leads to Better Scalability in Parallel Systems](thing_57/README.md)
* [A Message to the Future](thing_58/README.md)
* [Missing Opportunities for Polymorphism](thing_59/README.md)
* [News of the Weird: Testers Are Your Friends](thing_60/README.md)
* [One Binary](thing_61/README.md)
* [Only the Code Tells the Truth](thing_62/README.md)
* [Own (and Refactor) the Build](thing_63/README.md)
* [Pair Program and Feel the Flow](thing_64/README.md)
* [Prefer Domain-Specific Types to Primitive Types](thing_65/README.md)
* [Prevent Errors](thing_66/README.md)
* [The Professional Programmer](thing_67/README.md)
* [Put Everything Under Version Control](thing_68/README.md)
* [Put the Mouse Down and Step Away from the Keyboard](thing_69/README.md)
* [Read Code](thing_70/README.md)
* [Read the Humanities](thing_71/README.md)
* [Reinvent the Wheel Often](thing_72/README.md)
* [Resist the Temptation of the Singleton Pattern](thing_73/README.md)
* [The Road to Performance Is Littered with Dirty Code Bombs](thing_74/README.md)
* [Simplicity Comes from Reduction](thing_75/README.md)
* [The Single Responsibility Principle](thing_76/README.md)
* [Start from Yes](thing_77/README.md)
* [Step Back and Automate, Automate, Automate](thing_78/README.md)
* [Take Advantage of Code Analysis Tools](thing_79/README.md)
* [Test for Required Behavior, not Incidental Behavior](thing_80/README.md)
* [Test Precisely and Concretely](thing_81/README.md)
* [Test While You Sleep (and over Weekends)](thing_82/README.md)
* [Testing Is the Engineering Rigor of Software Development](thing_83/README.md)
* [Thinking in States](thing_84/README.md)
* [Two Heads Are Often Better than One](thing_85/README.md)
* [Two Wrongs Can Make a Right (and Are Difficult to Fix)](thing_86/README.md)
* [Ubuntu Coding for Your Friends](thing_87/README.md)
* [The Unix Tools Are Your Friends](thing_88/README.md)
* [Use the Right Algorithm and Data Structure](thing_89/README.md)
* [Verbose Logging Will Disturb Your Sleep](thing_90/README.md)
* [WET Dilutes Performance Bottlenecks](thing_91/README.md)
* [When Programmers and Testers Collaborate](thing_92/README.md)
* [Write Code as If You Had to Support It for the Rest of Your Life](thing_93/README.md)
* [Write Small Functions Using Examples](thing_94/README.md)
* [Write Tests for People](thing_95/README.md)
* [You Gotta Care about the Code](thing_96/README.md)
* [Your Customers Do not Mean What They Say](thing_97/README.md)
1. [Act with Prudence](thing_01/README.md)
1. [Apply Functional Programming Principles](thing_02/README.md)
1. [Ask "What Would the User Do?" (You Are not the User)](thing_03/README.md)
1. [Automate Your Coding Standard](thing_04/README.md)
1. [Beauty Is in Simplicity](thing_05/README.md)
1. [Before You Refactor](thing_06/README.md)
1. [Beware the Share](thing_07/README.md)
1. [The Boy Scout Rule](thing_08/README.md)
1. [Check Your Code First before Looking to Blame Others](thing_09/README.md)
1. [Choose Your Tools with Care](thing_10/README.md)
1. [Code in the Language of the Domain](thing_11/README.md)
1. [Code Is Design](thing_12/README.md)
1. [Code Layout Matters](thing_13/README.md)
1. [Code Reviews](thing_14/README.md)
1. [Coding with Reason](thing_15/README.md)
1. [A Comment on Comments](thing_16/README.md)
1. [Comment Only What the Code Cannot Say](thing_17/README.md)
1. [Continuous Learning](thing_18/README.md)
1. [Convenience Is not an -ility](thing_19/README.md)
1. [Deploy Early and Often](thing_20/README.md)
1. [Distinguish Business Exceptions from Technical](thing_21/README.md)
1. [Do Lots of Deliberate Practice](thing_22/README.md)
1. [Domain-Specific Languages](thing_23/README.md)
1. [Don't Be Afraid to Break Things](thing_24/README.md)
1. [Don't Be Cute with Your Test Data](thing_25/README.md)
1. [Don't Ignore that Error!](thing_26/README.md)
1. [Don't Just Learn the Language, Understand its Culture](thing_27/README.md)
1. [Don't Nail Your Program into the Upright Position](thing_28/README.md)
1. [Don't Rely on "Magic Happens Here"](thing_29/README.md)
1. [Don't Repeat Yourself](thing_30/README.md)
1. [Don't Touch that Code!](thing_31/README.md)
1. [Encapsulate Behavior, not Just State](thing_32/README.md)
1. [Floating-point Numbers Aren't Real](thing_33/README.md)
1. [Fulfill Your Ambitions with Open Source](thing_34/README.md)
1. [The Golden Rule of API Design](thing_35/README.md)
1. [The Guru Myth](thing_36/README.md)
1. [Hard Work Does not Pay Off](thing_37/README.md)
1. [How to Use a Bug Tracker](thing_38/README.md)
1. [Improve Code by Removing It](thing_39/README.md)
1. [Install Me](thing_40/README.md)
1. [Inter-Process Communication Affects Application Response Time](thing_41/README.md)
1. [Keep the Build Clean](thing_42/README.md)
1. [Know How to Use Command-line Tools](thing_43/README.md)
1. [Know Well More than Two Programming Languages](thing_44/README.md)
1. [Know Your IDE](thing_45/README.md)
1. [Know Your Limits](thing_46/README.md)
1. [Know Your Next Commit](thing_47/README.md)
1. [Large Interconnected Data Belongs to a Database](thing_48/README.md)
1. [Learn Foreign Languages](thing_49/README.md)
1. [Learn to Estimate](thing_50/README.md)
1. [Learn to Say "Hello, World"](thing_51/README.md)
1. [Let Your Project Speak for Itself](thing_52/README.md)
1. [The Linker Is not a Magical Program](thing_53/README.md)
1. [The Longevity of Interim Solutions](thing_54/README.md)
1. [Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly](thing_55/README.md)
1. [Make the Invisible More Visible](thing_56/README.md)
1. [Message Passing Leads to Better Scalability in Parallel Systems](thing_57/README.md)
1. [A Message to the Future](thing_58/README.md)
1. [Missing Opportunities for Polymorphism](thing_59/README.md)
1. [News of the Weird: Testers Are Your Friends](thing_60/README.md)
1. [One Binary](thing_61/README.md)
1. [Only the Code Tells the Truth](thing_62/README.md)
1. [Own (and Refactor) the Build](thing_63/README.md)
1. [Pair Program and Feel the Flow](thing_64/README.md)
1. [Prefer Domain-Specific Types to Primitive Types](thing_65/README.md)
1. [Prevent Errors](thing_66/README.md)
1. [The Professional Programmer](thing_67/README.md)
1. [Put Everything Under Version Control](thing_68/README.md)
1. [Put the Mouse Down and Step Away from the Keyboard](thing_69/README.md)
1. [Read Code](thing_70/README.md)
1. [Read the Humanities](thing_71/README.md)
1. [Reinvent the Wheel Often](thing_72/README.md)
1. [Resist the Temptation of the Singleton Pattern](thing_73/README.md)
1. [The Road to Performance Is Littered with Dirty Code Bombs](thing_74/README.md)
1. [Simplicity Comes from Reduction](thing_75/README.md)
1. [The Single Responsibility Principle](thing_76/README.md)
1. [Start from Yes](thing_77/README.md)
1. [Step Back and Automate, Automate, Automate](thing_78/README.md)
1. [Take Advantage of Code Analysis Tools](thing_79/README.md)
1. [Test for Required Behavior, not Incidental Behavior](thing_80/README.md)
1. [Test Precisely and Concretely](thing_81/README.md)
1. [Test While You Sleep (and over Weekends)](thing_82/README.md)
1. [Testing Is the Engineering Rigor of Software Development](thing_83/README.md)
1. [Thinking in States](thing_84/README.md)
1. [Two Heads Are Often Better than One](thing_85/README.md)
1. [Two Wrongs Can Make a Right (and Are Difficult to Fix)](thing_86/README.md)
1. [Ubuntu Coding for Your Friends](thing_87/README.md)
1. [The Unix Tools Are Your Friends](thing_88/README.md)
1. [Use the Right Algorithm and Data Structure](thing_89/README.md)
1. [Verbose Logging Will Disturb Your Sleep](thing_90/README.md)
1. [WET Dilutes Performance Bottlenecks](thing_91/README.md)
1. [When Programmers and Testers Collaborate](thing_92/README.md)
1. [Write Code as If You Had to Support It for the Rest of Your Life](thing_93/README.md)
1. [Write Small Functions Using Examples](thing_94/README.md)
1. [Write Tests for People](thing_95/README.md)
1. [You Gotta Care about the Code](thing_96/README.md)
1. [Your Customers Do not Mean What They Say](thing_97/README.md)
40 changes: 40 additions & 0 deletions en/extended_01/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
# Abstract Data Types

We can view the concept of _type_ in many ways. Perhaps the easiest is that type provides a guarantee of operations on data, so that the expression `42 + "life"` is meaningless. Be warned, though, that the safety net is not always 100% secure. From a compiler's perspective, a type also supplies important optimization clues, so that data can be best aligned in memory to reduce waste, and improve efficiency of machine instructions.

Types offer more than just safety nets and optimization clues. A type is also an abstraction. When you think about the concept of type in terms of abstraction, then think about the operations that are "allowable" for an object, which then constitute its abstract data type. Think about these two types:

```ruby
class Customer
def totalAmountOwing ...
def receivePayment ...
end

class Supplier
def totalAmountOwing ...
def makePayment ...
end
```

Remember that `class` is just a programming convenience to indicate an abstraction. Now consider when the following is executed.

```ruby
y = x.totalAmountOwing
```

`x` is just a variable that references some data, an object. What is the type of that object? We don't know if it is `Customer` or `Supplier` since both types allow the operation `totalAmountOwing`. Consider when the following is executed.

```ruby
y = x.totalAmountOwing
x.makePayment
```

Now, if successful, `x` definitely references an object of type `Supplier` since only the `Supplier` type supports operations of `totalAmountOwing` and `makePayment`. Viewing types as interoperable behaviors opens the door to polymorphism. If a type is about the valid set of operations for an object, then a program should not break if we substitute one object for another, so long as the substituted object is a subtype of the first object. In other words, honor the semantics of the behaviors and not just syntactical hierarchies. Abstract data types are organized around behaviors, not around the construction of the data.

The manner in which we determine the type influences our code. The interplay of language features and its compiler has led to static typing being misconstrued as a strictly compile-time exercise. Rather, think about static typing as the fixed constraints on the object imposed by the reference. It's an important distinction: The concrete type of the object can change while still conforming to the abstract data type.

We can also determine the type of an object dynamically, based on whether the object allows a particular operation or not. We can invoke the operation directly, so it is rejected at runtime if it is not supported, or the presence of the operation can be checked before with a query.

An abstraction and its set of allowable operations gives us modularity. This modularity gives us an opportunity to design with interfaces. As programmers, we can use these interfaces to reveal our intentions. When we design abstract data types to illustrate our intentions, then type becomes a natural form of documentation, that never goes stale. Understanding types helps us to write better code, so that others can understand our thinking at that point in time.

By [Aslam Khan](http://programmer.97things.oreilly.com/wiki/index.php/Aslam_Khan)
21 changes: 21 additions & 0 deletions en/extended_02/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
# Acknowledge (and Learn from) Failures

As a programmer you won't get everything right all of the time, and you won't always deliver what you said you would on time. Maybe you underestimated. Maybe you misunderstood requirements. Maybe that framework was not the right choice. Maybe you made a guess when you should have collected data. If you try something new, the odds are you'll fail from time to time. Without trying, you can't learn. And without learning, you can't be effective.

It's important to be honest with yourself and stakeholders, and take failure as an opportunity to improve. The sooner everyone knows the true state of things, the sooner you and your colleagues can take corrective action and help the customers get the software that they really wanted. This idea of frequent feedback and adjustment is at the heart of agile methods. It's also useful to apply in your own professional practice, regardless of your team's development approach.

Acknowledging that something isn't working takes courage. Many organizations encourage people to spin things in the most positive light rather than being honest. This is counterproductive. Telling people what they want to hear just defers the inevitable realization that they won't get what they expected. It also takes from them the opportunity to react to the information.

For example, maybe a feature is only worth implementing if it costs what the original estimate said, therefore changing scope would be to the customer's benefit. Acknowledging that it won't be done on time would give the stakeholder the power to make that decision. Failing to acknowledge the failure is itself a failure, and would put this power with the development team — which is the wrong place.

Most people would rather have something meet their expectations than get everything they asked for. Stakeholders may feel a sense of betrayal when given bad news. You can temper this by providing alternatives, but only if you believe that they are realistic.

Not being honest about your failures denies you a chance to learn and reflect on how you could have done better. There is an opportunity to improve your estimation or technical skills.

You can apply this idea not just to major things like daily stand-up meetings and iteration reviews, but also to small things like looking over some code you wrote yesterday and realizing that it was not as good as you thought, or admitting that you don't know the answer when someone asks you a question.

Allowing people to acknowledge failure takes an organization that doesn't punish failure and individuals who are willing to admit and learn from mistakes. While you can't always control your organization, you can change the way that you think about your work, and how you work with your colleagues.

Failures are inevitable. Acknowledging and learning from them provides value. Denying failure means that you wasted your time.

By [Steve Berczuk](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Berczuk)
Loading