Software Engineering at Google. Lessons Learned from Programming Over Time
![Język publikacji: angielski Język publikacji: angielski](https://static01.helion.com.pl/global/flagi/1.png)
- Autorzy:
- Titus Winters, Tom Manshreck, Hyrum Wright
![Software Engineering at Google. Lessons Learned from Programming Over Time Titus Winters, Tom Manshreck, Hyrum Wright - okładka ebooka](https://static01.helion.com.pl/global/okladki/326x466/e_1g4y.png)
![Software Engineering at Google. Lessons Learned from Programming Over Time Titus Winters, Tom Manshreck, Hyrum Wright - tył okładki ebooka](https://static01.helion.com.pl/global/okladki-tyl/326x466/e_1g4y.png)
- Ocena:
- Bądź pierwszym, który oceni tę książkę
- Stron:
- 602
- Dostępne formaty:
-
ePubMobi
Opis ebooka: Software Engineering at Google. Lessons Learned from Programming Over Time
Today, software engineers need to know not only how to program effectively but also how to develop proper engineering practices to make their codebase sustainable and healthy. This book emphasizes this difference between programming and software engineering.
How can software engineers manage a living codebase that evolves and responds to changing requirements and demands over the length of its life? Based on their experience at Google, software engineers Titus Winters and Hyrum Wright, along with technical writer Tom Manshreck, present a candid and insightful look at how some of the world’s leading practitioners construct and maintain software. This book covers Google’s unique engineering culture, processes, and tools and how these aspects contribute to the effectiveness of an engineering organization.
You’ll explore three fundamental principles that software organizations should keep in mind when designing, architecting, writing, and maintaining code:
- How time affects the sustainability of software and how to make your code resilient over time
- How scale affects the viability of software practices within an engineering organization
- What trade-offs a typical engineer needs to make when evaluating design and development decisions
Wybrane bestsellery
-
To nie jest podręcznik dla programistów. Celem autorów jest zaprezentowanie jedynej w swoim rodzaju perspektywy firmy Google, od lat rozwijającej trwały ekosystem oprogramowania, co pozwoliło zebrać pożyteczne wnioski dotyczące skali działalności i czasu jej trwania. W książce zwrócono uwagę na t...
Inżynieria oprogramowania według Google. Czego warto się nauczyć o tworzeniu oprogramowania Inżynieria oprogramowania według Google. Czego warto się nauczyć o tworzeniu oprogramowania
(77.40 zł najniższa cena z 30 dni)77.40 zł
129.00 zł(-40%) -
Język modelowania UML i będące jego częścią diagramy UML odgrywają ważną rolę w inżynierii oprogramowania. Stanowią komunikacyjny pomost podczas pracy zespołowej i w kontaktach zarówno z menedżerami, jak i klientami biznesowymi, niekoniecznie zorientowanymi w procesach projektowych i deweloperski...
UML. Kurs video. Projektowanie diagramów i modelowanie systemów w teorii i praktyce UML. Kurs video. Projektowanie diagramów i modelowanie systemów w teorii i praktyce
(58.04 zł najniższa cena z 30 dni)83.85 zł
129.00 zł(-35%) -
Głębokie sieci neuronowe mają niesamowity potencjał. Osiągnięcia ostatnich lat nadały procesom uczenia głębokiego zupełnie nową jakość. Obecnie nawet programiści niezaznajomieni z tą technologią mogą korzystać z prostych i niezwykle skutecznych narzędzi, pozwalających na sprawne implementowanie p...
Uczenie maszynowe z użyciem Scikit-Learn, Keras i TensorFlow. Wydanie III Uczenie maszynowe z użyciem Scikit-Learn, Keras i TensorFlow. Wydanie III
(107.40 zł najniższa cena z 30 dni)107.40 zł
179.00 zł(-40%) -
Dave Thomas i Andy Hunt napisali pierwsze wydanie tej wpływowej książki w 1999 roku, aby pomóc swoim klientom tworzyć lepsze oprogramowanie i na nowo odnaleźć radość z kodowania. Nauki płynące z tamtego wydania pomogły wielu pokoleniom programistów zbadać istotę rozwoju oprogramowania, niezależni...
Pragmatyczny programista. Od czeladnika do mistrza. Wydanie II Pragmatyczny programista. Od czeladnika do mistrza. Wydanie II
(46.20 zł najniższa cena z 30 dni)46.20 zł
77.00 zł(-40%) -
O tym, ile problemów sprawia niedbale napisany kod, wie każdy programista. Nie wszyscy jednak wiedzą, jak napisać ten świetny, „czysty” kod i czym właściwie powinien się on charakteryzować. Co więcej – jak odróżnić dobry kod od złego? Odpowiedź na te pytania oraz sposoby tworzen...(47.40 zł najniższa cena z 30 dni)
47.40 zł
79.00 zł(-40%) -
This book will help you understand key security principles and how they are implemented with Spring Security. You’ll also gain an in-depth understanding of Spring Security's new features applied to servlet and reactive Spring applications.
Spring Security. Effectively secure your web apps, RESTful services, cloud apps, and microservice architectures - Fourth Edition Spring Security. Effectively secure your web apps, RESTful services, cloud apps, and microservice architectures - Fourth Edition
-
Are you ready to be a part of the AI revolution? This book guides you through the concepts and steps you'll need to quickly add the latest and best AI models and features to your applications with real-world examples using Microsoft Semantic Kernel.
Building AI Applications with Microsoft Semantic Kernel. Easily integrate generative AI capabilities and copilot experiences into your applications Building AI Applications with Microsoft Semantic Kernel. Easily integrate generative AI capabilities and copilot experiences into your applications
O autorach ebooka
Titus Winters jest starszym inżynierem oprogramowania w Google. Kieruje pracami zespołu odpowiedzialnego za bazę kodu C++ firmy Google.
Tom Manshreck jest członkiem zespołu zajmującego się bibliotekami języka C++ w Google. Odpowiada za tworzenie dokumentacji technicznej.
Hyrum Wright jest inżynierem oprogramowania w Google. Kieruje grupą, która tworzy narzędzia do zautomatyzowanego wprowadzania zmian.
Kup polskie wydanie:
Inżynieria oprogramowania według Google. Czego warto się nauczyć o tworzeniu oprogramowania
- Autor:
- Titus Winters, Tom Manshreck, Hyrum Wright
64,50 zł
129,00 zł
(64.50 zł najniższa cena z 30 dni)
Ebooka "Software Engineering at Google. Lessons Learned from Programming Over Time" przeczytasz na:
-
czytnikach Inkbook, Kindle, Pocketbook, Onyx Boox i innych
-
systemach Windows, MacOS i innych
-
systemach Windows, Android, iOS, HarmonyOS
-
na dowolnych urządzeniach i aplikacjach obsługujących formaty: PDF, EPub, Mobi
Masz pytania? Zajrzyj do zakładki Pomoc »
Audiobooka "Software Engineering at Google. Lessons Learned from Programming Over Time" posłuchasz:
-
w aplikacji Ebookpoint na Android, iOS, HarmonyOs
-
na systemach Windows, MacOS i innych
-
na dowolnych urządzeniach i aplikacjach obsługujących format MP3 (pliki spakowane w ZIP)
Masz pytania? Zajrzyj do zakładki Pomoc »
Kurs Video "Software Engineering at Google. Lessons Learned from Programming Over Time" zobaczysz:
-
w aplikacjach Ebookpoint i Videopoint na Android, iOS, HarmonyOs
-
na systemach Windows, MacOS i innych z dostępem do najnowszej wersji Twojej przeglądarki internetowej
Szczegóły ebooka
- ISBN Ebooka:
- 978-14-920-8274-3, 9781492082743
- Data wydania ebooka:
-
2020-02-28
Data wydania ebooka często jest dniem wprowadzenia tytułu do sprzedaży i może nie być równoznaczna z datą wydania książki papierowej. Dodatkowe informacje możesz znaleźć w darmowym fragmencie. Jeśli masz wątpliwości skontaktuj się z nami sklep@ebookpoint.pl.
- Język publikacji:
- angielski
- Rozmiar pliku ePub:
- 5.7MB
- Rozmiar pliku Mobi:
- 15.7MB
Spis treści ebooka
- Foreword
- Preface
- Programming Over Time
- Googles Perspective
- What This Book Isnt
- Parting Remarks
- Conventions Used in This Book
- OReilly Online Learning
- How to Contact Us
- Acknowledgments
- I. Thesis
- 1. What Is Software Engineering?
- Time and Change
- Hyrums Law
- Example: Hash Ordering
- Why Not Just Aim for Nothing Changes?
- Time and Change
- Scale and Efficiency
- Policies That Dont Scale
- Policies That Scale Well
- Example: Compiler Upgrade
- Shifting Left
- Trade-offs and Costs
- Example: Markers
- Inputs to Decision Making
- Example: Distributed Builds
- Example: Deciding Between Time and Scale
- Revisiting Decisions, Making Mistakes
- Software Engineering Versus Programming
- Conclusion
- TL;DRs
- II. Culture
- 2. How to Work Well on Teams
- Help Me Hide My Code
- The Genius Myth
- Hiding Considered Harmful
- Early Detection
- The Bus Factor
- Pace of Progress
- In Short, Dont Hide
- Its All About the Team
- The Three Pillars of Social Interaction
- Why Do These Pillars Matter?
- Humility, Respect, and Trust in Practice
- Lose the ego
- Learn to give and take criticism
- Fail fast and iterate
- Blameless Post-Mortem Culture
- Learn patience
- Be open to influence
- Being Googley
- Conclusion
- TL;DRs
- 3. Knowledge Sharing
- Challenges to Learning
- Philosophy
- Setting the Stage: Psychological Safety
- Mentorship
- Psychological Safety in Large Groups
- Growing Your Knowledge
- Ask Questions
- Understand Context
- Scaling Your Questions: Ask the Community
- Group Chats
- Mailing Lists
- YAQS: Question-and-Answer Platform
- Scaling Your Knowledge: You Always Have Something to Teach
- Office Hours
- Tech Talks and Classes
- Documentation
- Updating documentation
- Creating documentation
- Promoting documentation
- Code
- Scaling Your Organizations Knowledge
- Cultivating a Knowledge-Sharing Culture
- Respect
- Incentives and recognition
- Cultivating a Knowledge-Sharing Culture
- Establishing Canonical Sources of Information
- Developer guides
- go/ links
- Codelabs
- Static analysis
- Staying in the Loop
- Newsletters
- Communities
- Readability: Standardized Mentorship Through Code Review
- What Is the Readability Process?
- Why Have This Process?
- Conclusion
- TL;DRs
- 4. Engineering for Equity
- Bias Is the Default
- Understanding the Need for Diversity
- Building Multicultural Capacity
- Making Diversity Actionable
- Reject Singular Approaches
- Challenge Established Processes
- Values Versus Outcomes
- Stay Curious, Push Forward
- Conclusion
- TL;DRs
- 5. How to Lead a Team
- Managers and Tech Leads (and Both)
- The Engineering Manager
- The Tech Lead
- The Tech Lead Manager
- Managers and Tech Leads (and Both)
- Moving from an Individual Contributor Role to a Leadership Role
- The Only Thing to Fear IsWell, Everything
- Servant Leadership
- The Engineering Manager
- Manager Is a Four-Letter Word
- Todays Engineering Manager
- Antipatterns
- Antipattern: Hire Pushovers
- Antipattern: Ignore Low Performers
- Antipattern: Ignore Human Issues
- Antipattern: Be Everyones Friend
- Antipattern: Compromise the Hiring Bar
- Antipattern: Treat Your Team Like Children
- Positive Patterns
- Lose the Ego
- Be a Zen Master
- Be a Catalyst
- Remove Roadblocks
- Be a Teacher and a Mentor
- Set Clear Goals
- Be Honest
- Track Happiness
- The Unexpected Question
- Other Tips and Tricks
- People Are Like Plants
- Intrinsic Versus Extrinsic Motivation
- Conclusion
- TL;DRs
- 6. Leading at Scale
- Always Be Deciding
- The Parable of the Airplane
- Identify the Blinders
- Identify the Key Trade-Offs
- Decide, Then Iterate
- Always Be Deciding
- Always Be Leaving
- Your Mission: Build a Self-Driving Team
- Dividing the Problem Space
- Example: Subdividing the latency problem of Google Search
- Delegating subproblems to leaders
- Adjusting and iterating
- Take care in anchoring a teams identity
- Always Be Scaling
- The Cycle of Success
- Important Versus Urgent
- Learn to Drop Balls
- Protecting Your Energy
- Conclusion
- TL;DRs
- 7. Measuring Engineering Productivity
- Why Should We Measure Engineering Productivity?
- Triage: Is It Even Worth Measuring?
- Selecting Meaningful Metrics with Goals and Signals
- Goals
- Signals
- Metrics
- Using Data to Validate Metrics
- Taking Action and Tracking Results
- Conclusion
- TL;DRs
- III. Processes
- 8. Style Guides and Rules
- Why Have Rules?
- Creating the Rules
- Guiding Principles
- Rules must pull their weight
- Optimize for the reader
- Be consistent
- Advantages of consistency
- Setting the standard
- Avoid error-prone and surprising constructs
- Concede to practicalities
- Guiding Principles
- The Style Guide
- Avoiding danger
- Enforcing best practices
- Building in consistency
- And for everything else...
- Changing the Rules
- The Process
- The Style Arbiters
- Exceptions
- Guidance
- Applying the Rules
- Error Checkers
- Code Formatters
- Conclusion
- TL;DRs
- 9. Code Review
- Code Review Flow
- How Code Review Works at Google
- Code Review Benefits
- Code Correctness
- Comprehension of Code
- Code Consistency
- Psychological and Cultural Benefits
- Knowledge Sharing
- Code Review Best Practices
- Be Polite and Professional
- Write Small Changes
- Write Good Change Descriptions
- Keep Reviewers to a Minimum
- Automate Where Possible
- Types of Code Reviews
- Greenfield Code Reviews
- Behavioral Changes, Improvements, and Optimizations
- Bug Fixes and Rollbacks
- Refactorings and Large-Scale Changes
- Conclusion
- TL;DRs
- 10. Documentation
- What Qualifies as Documentation?
- Why Is Documentation Needed?
- Documentation Is Like Code
- Know Your Audience
- Types of Audiences
- Documentation Types
- Reference Documentation
- File comments
- Class comments
- Function comments
- Reference Documentation
- Design Docs
- Tutorials
- Example: A bad tutorial
- Example: A bad tutorial made better
- Conceptual Documentation
- Landing Pages
- Documentation Reviews
- Documentation Philosophy
- WHO, WHAT, WHEN, WHERE, and WHY
- The Beginning, Middle, and End
- The Parameters of Good Documentation
- Deprecating Documents
- When Do You Need Technical Writers?
- Conclusion
- TL;DRs
- 11. Testing Overview
- Why Do We Write Tests?
- The Story of Google Web Server
- Testing at the Speed of Modern Development
- Write, Run, React
- Benefits of Testing Code
- Why Do We Write Tests?
- Designing a Test Suite
- Test Size
- Small tests
- Medium tests
- Large tests
- Properties common to all test sizes
- Test sizes in practice
- Test Size
- Test Scope
- The Beyoncé Rule
- A Note on Code Coverage
- Testing at Google Scale
- The Pitfalls of a Large Test Suite
- History of Testing at Google
- Orientation Classes
- Test Certified
- Testing on the Toilet
- Testing Culture Today
- The Limits of Automated Testing
- Conclusion
- TL;DRs
- 12. Unit Testing
- The Importance of Maintainability
- Preventing Brittle Tests
- Strive for Unchanging Tests
- Test via Public APIs
- Test State, Not Interactions
- Writing Clear Tests
- Make Your Tests Complete and Concise
- Test Behaviors, Not Methods
- Structure tests to emphasize behaviors
- Name tests after the behavior being tested
- Dont Put Logic in Tests
- Write Clear Failure Messages
- Tests and Code Sharing: DAMP, Not DRY
- Shared Values
- Shared Setup
- Shared Helpers and Validation
- Defining Test Infrastructure
- Conclusion
- TL;DRs
- 13. Test Doubles
- The Impact of Test Doubles on Software Development
- Test Doubles at Google
- Basic Concepts
- An Example Test Double
- Seams
- Mocking Frameworks
- Techniques for Using Test Doubles
- Faking
- Stubbing
- Interaction Testing
- Real Implementations
- Prefer Realism Over Isolation
- How to Decide When to Use a Real Implementation
- Execution time
- Determinism
- Dependency construction
- Faking
- Why Are Fakes Important?
- When Should Fakes Be Written?
- The Fidelity of Fakes
- Fakes Should Be Tested
- What to Do If a Fake Is Not Available
- Stubbing
- The Dangers of Overusing Stubbing
- Tests become unclear
- Tests become brittle
- Tests become less effective
- An example of overusing stubbing
- The Dangers of Overusing Stubbing
- When Is Stubbing Appropriate?
- Interaction Testing
- Prefer State Testing Over Interaction Testing
- When Is Interaction Testing Appropriate?
- Best Practices for Interaction Testing
- Prefer to perform interaction testing only for state-changing functions
- Avoid overspecification
- Conclusion
- TL;DRs
- 14. Larger Testing
- What Are Larger Tests?
- Fidelity
- Common Gaps in Unit Tests
- Unfaithful doubles
- Configuration issues
- Issues that arise under load
- Unanticipated behaviors, inputs, and side effects
- Emergent behaviors and the vacuum effect
- Why Not Have Larger Tests?
- What Are Larger Tests?
- Larger Tests at Google
- Larger Tests and Time
- Larger Tests at Google Scale
- Structure of a Large Test
- The System Under Test
- The benefits of hermetic SUTs
- Reducing the size of your SUT at problem boundaries
- Record/replay proxies
- The System Under Test
- Test Data
- Verification
- Types of Larger Tests
- Functional Testing of One or More Interacting Binaries
- Browser and Device Testing
- Performance, Load, and Stress testing
- Deployment Configuration Testing
- Exploratory Testing
- Limitations
- Bug bashes
- A/B Diff Regression Testing
- Limitations
- UAT
- Probers and Canary Analysis
- Limitations
- Disaster Recovery and Chaos Engineering
- Limitations
- User Evaluation
- Large Tests and the Developer Workflow
- Authoring Large Tests
- Running Large Tests
- Speeding up tests
- Driving out flakiness
- Making tests understandable
- Owning Large Tests
- Conclusion
- TL;DRs
- 15. Deprecation
- Why Deprecate?
- Why Is Deprecation So Hard?
- Deprecation During Design
- Types of Deprecation
- Advisory Deprecation
- Compulsory Deprecation
- Deprecation Warnings
- Managing the Deprecation Process
- Process Owners
- Milestones
- Deprecation Tooling
- Discovery
- Migration
- Preventing backsliding
- Conclusion
- TL;DRs
- IV. Tools
- 16. Version Control and Branch Management
- What Is Version Control?
- Why Is Version Control Important?
- Centralized VCS Versus Distributed VCS
- Centralized VCS
- Distributed VCS
- Source of Truth
- Scenario: no clear source of truth
- What Is Version Control?
- Version Control Versus Dependency Management
- Branch Management
- Work in Progress Is Akin to a Branch
- Dev Branches
- How did we become addicted to dev branches?
- Release Branches
- Version Control at Google
- One Version
- Scenario: Multiple Available Versions
- The One-Version Rule
- (Nearly) No Long-Lived Branches
- What About Release Branches?
- Monorepos
- Future of Version Control
- Conclusion
- TL;DRs
- 17. Code Search
- The Code Search UI
- How Do Googlers Use Code Search?
- Where?
- What?
- How?
- Why?
- Who and When?
- Why a Separate Web Tool?
- Scale
- Zero Setup Global Code View
- Specialization
- Integration with Other Developer Tools
- API Exposure
- Impact of Scale on Design
- Search Query Latency
- Index Latency
- Googles Implementation
- Search Index
- Ranking
- Query independent signals
- Query dependent signals
- Retrieval
- Result diversity
- Selected Trade-Offs
- Completeness: Repository at Head
- Completeness: All Versus Most-Relevant Results
- Completeness: Head Versus Branches Versus All History Versus Workspaces
- Expressiveness: Token Versus Substring Versus Regex
- Conclusion
- TL;DRs
- 18. Build Systems and Build Philosophy
- Purpose of a Build System
- What Happens Without a Build System?
- But All I Need Is a Compiler!
- Shell Scripts to the Rescue?
- Modern Build Systems
- Its All About Dependencies
- Task-Based Build Systems
- The dark side of task-based build systems
- Difficulty of parallelizing build steps
- Difficulty performing incremental builds
- Difficulty maintaining and debugging scripts
- The dark side of task-based build systems
- Artifact-Based Build Systems
- A functional perspective
- Getting concrete with Bazel
- A functional perspective
- Other nifty Bazel tricks
- Tools as dependencies
- Extending the build system
- Isolating the environment
- Making external dependencies deterministic
- Distributed Builds
- Remote caching
- Remote execution
- Distributed builds at Google
- Time, Scale, Trade-Offs
- Dealing with Modules and Dependencies
- Using Fine-Grained Modules and the 1:1:1 Rule
- Minimizing Module Visibility
- Managing Dependencies
- Internal dependencies
- External dependencies
- Automatic versus manual dependency management
- The One-Version Rule
- Transitive external dependencies
- Caching build results using external dependencies
- Security and reliability of external dependencies
- Conclusion
- TL;DRs
- 19. Critique: Googles Code Review Tool
- Code Review Tooling Principles
- Code Review Flow
- Notifications
- Stage 1: Create a Change
- Diffing
- Analysis Results
- Tight Tool Integration
- Stage 2: Request Review
- Stages 3 and 4: Understanding and Commenting on a Change
- Commenting
- Understanding the State of a Change
- Whose turn feature
- Dashboard and search system
- Stage 5: Change Approvals (Scoring a Change)
- Stage 6: Commiting a Change
- After Commit: Tracking History
- Conclusion
- TL;DRs
- 20. Static Analysis
- Characteristics of Effective Static Analysis
- Scalability
- Usability
- Characteristics of Effective Static Analysis
- Key Lessons in Making Static Analysis Work
- Focus on Developer Happiness
- Make Static Analysis a Part of the Core Developer Workflow
- Empower Users to Contribute
- Tricorder: Googles Static Analysis Platform
- Integrated Tools
- Integrated Feedback Channels
- Suggested Fixes
- Per-Project Customization
- Presubmits
- Compiler Integration
- Analysis While Editing and Browsing Code
- Conclusion
- TL;DRs
- 21. Dependency Management
- Why Is Dependency Management So Difficult?
- Conflicting Requirements and Diamond Dependencies
- Why Is Dependency Management So Difficult?
- Importing Dependencies
- Compatibility Promises
- C++
- Go
- Abseil
- Boost
- Compatibility Promises
- Considerations When Importing
- How Google Handles Importing Dependendencies
- Dependency Management, In Theory
- Nothing Changes (aka The Static Dependency Model)
- Semantic Versioning
- Bundled Distribution Models
- Live at Head
- The Limitations of SemVer
- SemVer Might Overconstrain
- SemVer Might Overpromise
- Motivations
- Minimum Version Selection
- So, Does SemVer Work?
- Dependency Management with Infinite Resources
- Exporting Dependencies
- Example: open sourcing gflags
- Exporting Dependencies
- Conclusion
- TL;DRs
- 22. Large-Scale Changes
- What Is a Large-Scale Change?
- Who Deals with LSCs?
- Barriers to Atomic Changes
- Technical Limitations
- Merge Conflicts
- No Haunted Graveyards
- Heterogeneity
- Testing
- Code Review
- LSC Infrastructure
- Policies and Culture
- Codebase Insight
- Change Management
- Testing
- Language Support
- The LSC Process
- Authorization
- Change Creation
- Sharding and Submitting
- Testing
- Mailing reviewers
- Reviewing
- Submitting
- Cleanup
- Conclusion
- TL;DRs
- 23. Continuous Integration
- CI Concepts
- Fast Feedback Loops
- Accessible and actionable feedback
- Fast Feedback Loops
- Automation
- Continuous Build
- Continuous Delivery
- CI Concepts
- Continuous Testing
- Why presubmit isnt enough
- Presubmit versus post-submit
- Release candidate testing
- Production testing
- CI Challenges
- Hermetic Testing
- CI at Google
- CI Case Study: Google Takeout
- Scenario #1: Continuously broken dev deploys
- What the team did
- Lesson learned
- Scenario #1: Continuously broken dev deploys
- Scenario #2: Indecipherable test logs
- What the team did
- Lesson learned
- CI Case Study: Google Takeout
- Scenario #3: Debugging all of Google
- What the team did
- Lesson learned
- Remaining challenge
- Future improvement
- Scenario #4: Keeping it green
- What the team did
- Lessons learned
- Future improvement
- Further challenges
- But I Cant Afford CI
- Conclusion
- TL;DRs
- 24. Continuous Delivery
- Idioms of Continuous Delivery at Google
- Velocity Is a Team Sport: How to Break Up a Deployment into Manageable Pieces
- Evaluating Changes in Isolation: Flag-Guarding Features
- Striving for Agility: Setting Up a Release Train
- No Binary Is Perfect
- Meet Your Release Deadline
- Quality and User-Focus: Ship Only What Gets Used
- Shifting Left: Making Data-Driven Decisions Earlier
- Changing Team Culture: Building Discipline into Deployment
- Conclusion
- TL;DRs
- 25. Compute as a Service
- Taming the Compute Environment
- Automation of Toil
- Simple automations
- Automated scheduling
- Automation of Toil
- Containerization and Multitenancy
- My neighbors dog barks in my RAM
- Rightsizing and autoscaling
- Taming the Compute Environment
- Summary
- Writing Software for Managed Compute
- Architecting for Failure
- Batch Versus Serving
- Managing State
- Connecting to a Service
- One-Off Code
- CaaS Over Time and Scale
- Containers as an Abstraction
- Containers and implicit dependencies
- Containers as an Abstraction
- One Service to Rule Them All
- Multitenancy for serving jobs
- Submitted Configuration
- Choosing a Compute Service
- Centralization Versus Customization
- Need for customization
- Centralization Versus Customization
- Level of Abstraction: Serverless
- What is serverless?
- Pros and cons
- The trade-off
- Public Versus Private
- Conclusion
- TL;DRs
- V. Conclusion
- Afterword
- Index
O'Reilly Media - inne książki
-
Keeping up with the Python ecosystem can be daunting. Its developer tooling doesn't provide the out-of-the-box experience native to languages like Rust and Go. When it comes to long-term project maintenance or collaborating with others, every Python project faces the same problem: how to build re...(201.03 zł najniższa cena z 30 dni)
200.93 zł
239.00 zł(-16%) -
Bringing a deep-learning project into production at scale is quite challenging. To successfully scale your project, a foundational understanding of full stack deep learning, including the knowledge that lies at the intersection of hardware, software, data, and algorithms, is required.This book il...(241.36 zł najniższa cena z 30 dni)
241.26 zł
289.00 zł(-17%) -
Frontend developers have to consider many things: browser compatibility, usability, performance, scalability, SEO, and other best practices. But the most fundamental aspect of creating websites is one that often falls short: accessibility. Accessibility is the cornerstone of any website, and if a...(200.59 zł najniższa cena z 30 dni)
200.09 zł
239.00 zł(-16%) -
In this insightful and comprehensive guide, Addy Osmani shares more than a decade of experience working on the Chrome team at Google, uncovering secrets to engineering effectiveness, efficiency, and team success. Engineers and engineering leaders looking to scale their effectiveness and drive tra...(114.93 zł najniższa cena z 30 dni)
114.88 zł
149.00 zł(-23%) -
Data modeling is the single most overlooked feature in Power BI Desktop, yet it's what sets Power BI apart from other tools on the market. This practical book serves as your fast-forward button for data modeling with Power BI, Analysis Services tabular, and SQL databases. It serves as a starting ...(199.08 zł najniższa cena z 30 dni)
198.88 zł
239.00 zł(-17%) -
C# is undeniably one of the most versatile programming languages available to engineers today. With this comprehensive guide, you'll learn just how powerful the combination of C# and .NET can be. Author Ian Griffiths guides you through C# 12.0 and .NET 8 fundamentals and techniques for building c...(241.02 zł najniższa cena z 30 dni)
240.92 zł
289.00 zł(-17%) -
Learn how to get started with Futures Thinking. With this practical guide, Phil Balagtas, founder of the Design Futures Initiative and the global Speculative Futures network, shows you how designers and futurists have made futures work at companies such as Atari, IBM, Apple, Disney, Autodesk, Luf...(148.10 zł najniższa cena z 30 dni)
148.00 zł
179.00 zł(-17%) -
Augmented Analytics isn't just another book on data and analytics; it's a holistic resource for reimagining the way your entire organization interacts with information to become insight-driven.Moving beyond traditional, limited ways of making sense of data, Augmented Analytics provides a dynamic,...(174.74 zł najniższa cena z 30 dni)
174.54 zł
219.00 zł(-20%) -
Learn how to prepare for—and pass—the Kubernetes and Cloud Native Associate (KCNA) certification exam. This practical guide serves as both a study guide and point of entry for practitioners looking to explore and adopt cloud native technologies. Adrián González Sánchez ...
Kubernetes and Cloud Native Associate (KCNA) Study Guide Kubernetes and Cloud Native Associate (KCNA) Study Guide
(169.14 zł najniższa cena z 30 dni)177.65 zł
199.00 zł(-11%) -
Python is an excellent way to get started in programming, and this clear, concise guide walks you through Python a step at a time—beginning with basic programming concepts before moving on to functions, data structures, and object-oriented design. This revised third edition reflects the gro...(140.34 zł najniższa cena z 30 dni)
140.14 zł
179.00 zł(-22%)
Dzieki opcji "Druk na żądanie" do sprzedaży wracają tytuły Grupy Helion, które cieszyły sie dużym zainteresowaniem, a których nakład został wyprzedany.
Dla naszych Czytelników wydrukowaliśmy dodatkową pulę egzemplarzy w technice druku cyfrowego.
Co powinieneś wiedzieć o usłudze "Druk na żądanie":
- usługa obejmuje tylko widoczną poniżej listę tytułów, którą na bieżąco aktualizujemy;
- cena książki może być wyższa od początkowej ceny detalicznej, co jest spowodowane kosztami druku cyfrowego (wyższymi niż koszty tradycyjnego druku offsetowego). Obowiązująca cena jest zawsze podawana na stronie WWW książki;
- zawartość książki wraz z dodatkami (płyta CD, DVD) odpowiada jej pierwotnemu wydaniu i jest w pełni komplementarna;
- usługa nie obejmuje książek w kolorze.
Masz pytanie o konkretny tytuł? Napisz do nas: sklep[at]helion.pl.
Książka, którą chcesz zamówić pochodzi z końcówki nakładu. Oznacza to, że mogą się pojawić drobne defekty (otarcia, rysy, zagięcia).
Co powinieneś wiedzieć o usłudze "Końcówka nakładu":
- usługa obejmuje tylko książki oznaczone tagiem "Końcówka nakładu";
- wady o których mowa powyżej nie podlegają reklamacji;
Masz pytanie o konkretny tytuł? Napisz do nas: sklep[at]helion.pl.
Książka drukowana
![Loader](https://static01.helion.com.pl/ebookpoint/img/ajax-loader.gif)
![ajax-loader](https://static01.helion.com.pl/ebookpoint/img/ajax-loader.gif)
Oceny i opinie klientów: Software Engineering at Google. Lessons Learned from Programming Over Time Titus Winters, Tom Manshreck, Hyrum Wright (0)
Weryfikacja opinii następuję na podstawie historii zamówień na koncie Użytkownika umieszczającego opinię. Użytkownik mógł otrzymać punkty za opublikowanie opinii uprawniające do uzyskania rabatu w ramach Programu Punktowego.