Donne Martin/system-design-primer: Learn how to design large-scale systems. Prep for the system design interview.

GitHub - donnemartin/system-design-primer: Learn how to design large-scale systems. Prep for the system design interview.: "Motivation

Learn how to design large scale systems.

Prep for the system design interview.
Learn how to design large scale systems

 Learning how to design scalable systems will help you become a better engineer.

System design is a broad topic.

There is a vast amount of resources scattered throughout the web on system design principles.

This repo is an organized collection of resources to help you learn how to build systems at scale."

'via Blog this'

Anti-If: The missing patterns

Anti-If: The missing patterns: "If statements usually make your code more complicated. But we don’t want to outright ban them. I’ve seen some pretty heinous code created with the goal of removing all traces of if statements. We want to avoid falling into that trap.

For each pattern we’ll read about I’m going to give you a tolerance value for when to use it.

A single if statement which isn’t duplicated anywhere else is probably fine. It’s when you have duplicated if statements that you want your spider sense to be tingling.

At the outside of your code base, where you talk to the dangerous outside world, you are going to want to validate incoming responses and change your beahaviour accordingly. But inside our own codebases, where we behind those trusted gatekeepers, I think we have a great opportunity to use simple, richer and more powerful alternatives."



'via Blog this'

Don't Get Obsessed With Design Patterns - Simple Programmer

Don't Get Obsessed With Design Patterns - Simple Programmer:



"The cost of adding a design pattern

There are many different design patterns, but most of them have something in common: when you apply them, you need to lay out some structure. In other words, you need to add classes and/or interfaces to the code.

In the first example, this structure consists of an abstract class extended by two children classes. What’s more, in order for the old code to use these new classes, you also need to make some updates not directly related to the design pattern itself.

The moral of the story is: if you’re thinking about applying a design pattern, consider the cost of doing so and the potential benefit. Doing it only for the sake of doing it will make your code more complex than it needs to be."



'via Blog this'

How To Code Like The Top Programmers At NASA — 10 Critical Rules

How To Code Like The Top Programmers At NASA — 10 Critical Rules: "NASA’s 10 rules for writing mission-critical code:

•  Restrict all code to very simple control flow constructs – do not use goto statements, setjmp or longjmp constructs, and direct or indirect recursion. 

• All loops must have a fixed upper-bound. It must be trivially possible for a checking tool to prove statically that a preset upper-bound on the number of iterations of a loop cannot be exceeded. If the loop-bound cannot be proven statically, the rule is considered violated.

• Do not use dynamic memory allocation after initialization. 

• No function should be longer than what can be printed on a single sheet of paper in a standard reference format with one line per statement and one line per declaration. Typically, this means no more than about 60 lines of code per function. 

• The assertion density of the code should average to a minimum of two assertions per function. Assertions are used to check for anomalous conditions that should never happen in real-life executions. Assertions must always be side-effect free and should be defined as Boolean tests. When an assertion fails, an explicit recovery action must be taken, e.g., by returning an error condition to the caller of the function that executes the failing assertion. Any assertion for which a static checking tool can prove that it can never fail or never hold violates this rule (I.e., it is not possible to satisfy the rule by adding unhelpful “assert(true)” statements). 

• Data objects must be declared at the smallest possible level of scope. 

• The return value of non-void functions must be checked by each calling function, and the validity of parameters must be checked inside each function. 

• The use of the preprocessor must be limited to the inclusion of header files and simple macro definitions. Token pasting, variable argument lists (ellipses), and recursive macro calls are not allowed. All macros must expand into complete syntactic units. The use of conditional compilation directives is often also dubious, but cannot always be avoided. This means that there should rarely be justification for more than one or two conditional compilation directives even in large software development efforts, beyond the standard boilerplate that avoids multiple inclusion of the same header file. Each such use should be flagged by a tool-based checker and justified in the code. 

• The use of pointers should be restricted. Specifically, no more than one level of dereferencing is allowed. Pointer dereference operations may not be hidden in macro definitions or inside typedef declarations. Function pointers are not permitted.
  All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting. 

• All code must compile with these setting without any warnings. All code must be checked daily with at least one, but preferably more than one, state-of-the-art static source code analyzer and should pass the analyses with zero warnings."

'via Blog this'

Git & Scrum: Workflows that work - O'Reilly Media

Workflows that work - O'Reilly Media:


I love working with teams of people to hash out a plan of action—the more sticky notes and whiteboards the better. Throughout the process, there may be a bit of arguing, and some compromises made, but eventually you get to a point where people can agree on a basic process. Everyone gets back to their desks, clear about the direction they need to go in and suddenly, one by one, people start asking, "But how do I start?" The more cues you can give your team to get working, the more they can focus on the hard bits. Version control should never be the hard part.

By the end of this chapter, you will be able to create step-by-step documentation covering:

• Basic workflow
• 
  
• 
  
• Integration branches
• 
  
• 
  
• Release schedules
• 
  
• 
  
• Post-launch hotfixes

This chapter is essentially a set of abstracted case studies on how I have effectively used Git while working in teams. You will notice my strong preference for Agile methodologies, in particular Scrum, in this chapter.

Good Design: What to look for in a Code Reviews

Trisha Gee: What to look for in a Code Reviews

Apple and the little i

Article on how Apple got the little i....

This was a key moment for Apple, when its love of Simplicity won the day and set it on a course it follows to this very day. Steve was unrelenting in his desire to give this great product a great name. He appreciated the power of words. In this case, he appreciated the power of a single letter. And that little letter “i” became one of the most important parts of the Apple brand.

http://www.fastcodesign.com/1669924/steve-jobs-almost-named-the-imac-the-macman-until-this-guy-stopped-him