39 results back to index
Building Web Applications With Flask by Italo Maia
The message here is: do not make your product more robust or complex than you know it needs to be and do not waste time planning for what may, most likely, never happen. Tip Always plan for reasonable levels of safety, complexity, and performance. Premature optimization Is your software fast enough? Don't know? Then why are you optimizing that code, my friend? When you spend time optimizing software that you're not sure needs optimization, if no one complained about it being slow or you do not notice it to be slow in daily use, you're probably wasting time with premature optimization. And so, on to Flask. Blueprints 101 So far, our applications have all been flat: beautiful, single-file Web applications (templates and static resources not considered). In some cases, that's a nice approach; a reduced need for imports, easy to maintain with simple editors and all but… As our applications grow, we identify the need to contextually arrange our code.
SQLAlchemy Concepts Hands on Flask-SQLAlchemy MongoDB MongoEngine Flask-MongoEngine Relational versus NoSQL Summary 6. But I Wanna REST Mom, Now! Beyond GET Flask-Restless Summary 7. If Ain't Tested, It Ain't Game, Bro! What kinds of test are there? Unit testing Behavior testing Flask-testing LiveServer Extra assertions JSON handle Fixtures Extra – integration testing Summary 8. Tips and Tricks or Flask Wizardry 101 Overengineering Premature optimization Blueprints 101 Oh God, please tell me you have the logs… Debugging, DebugToolbar, and happiness Flask-DebugToolbar Sessions or storing user data between requests Exercise Summary 9. Extensions, How I Love Thee How to configure extensions Flask-Principal and Flask-Login (aka Batman and Robin) Admin like a boss Custom pages Summary 10. What Now? You deploy better than my ex Placing your code in a server Setting up your database Setting up the web server StackOverflow Structuring your projects Summary Postscript Index Building Web Applications with Flask * * * Building Web Applications with Flask Copyright © 2015 Packt Publishing All rights reserved.
You may purchase a nice Integrated Development Environment (IDE) such as PyCharm or WingIDE to improve your productivity or hire third-party services to help you test your code or control your development schedule, but these can do just so much. Good architecture and task automation will be your best friend in most projects. Before discussing suggestions on how to organize you code and which modules will help you save some typing here and there, let's discuss premature optimization and overengineering, two terrible symptoms of an anxious developer/analyst/nosy manager. Overengineering Making software is like making a condo, in a few ways. You'll plan ahead what you want to create before starting so that waste is kept to a minimum. Contrary to a condo, where it's advisable to plan the whole project before you start, you do not have to plan out your software because it will most likely change during development, and a lot of the planning may just go to waste.
The Art of UNIX Programming by Eric S. Raymond
A Pattern Language, Albert Einstein, barriers to entry, bioinformatics, Clayton Christensen, combinatorial explosion, commoditize, correlation coefficient, David Brooks, Debian, domain-specific language, don't repeat yourself, Donald Knuth, Everything should be made as simple as possible, facts on the ground, finite state, general-purpose programming language, George Santayana, Innovator's Dilemma, job automation, Larry Wall, MVC pattern, pattern recognition, Paul Graham, peer-to-peer, premature optimization, pre–internet, publish or perish, revision control, RFC: Request For Comment, Richard Stallman, Robert Metcalfe, Steven Levy, transaction costs, Turing complete, Valgrind, wage slave, web application
For slightly different reasons, Donald Knuth (author of The Art Of Computer Programming, one of the field's few true classics) popularized the observation that “Premature optimization is the root of all evil”. And he was right. Rushing to optimize before the bottlenecks are known may be the only error to have ruined more designs than feature creep. From tortured code to incomprehensible data layouts, the results of obsessing about speed or memory or disk usage at the expense of transparency and simplicity are everywhere. They spawn innumerable bugs and cost millions of man-hours — often, just to get marginal gains in the use of some resource much less expensive than debugging time. Disturbingly often, premature local optimization actually hinders global optimization (and hence reduces overall performance). A prematurely optimized portion of a design frequently interferes with changes that would have much higher payoffs across the whole design, so you end up with both inferior performance and excessively complex code.
This is good, and not just because it saves you work. The really valuable effect is that not optimizing that 90% holds down global complexity and reduces bugs. You may recall that we quoted Donald Knuth observing “Premature optimization is the root of all evil” in Chapter 1, and that Rob Pike and Ken Thompson had a few pungent observations on the topic as well. These were the voices of experience. Do good design. Think about what's right first. Tune for efficiency later. Profilers help you do this. If you get in the good habit of using them, you can get rid of the bad habit of premature optimization. Profilers don't just change the way you work; they change how you think. Profilers for compiled languages rely on instrumenting object code, so they are even more platform-dependent than compilers. On the other hand, a compiled-language profiler doesn't care about the source language of the programs it instruments.
The reference is to an early edition of The Mythical Man-Month [Brooks]; the quote is “Show me your flow charts and conceal your tables and I shall continue to be mystified, show me your tables and I won't usually need your flow charts; they'll be obvious”.  Jonathan Postel was the first editor of the Internet RFC series of standards, and one of the principal architects of the Internet. A tribute page is maintained by the Postel Center for Experimental Networking.  In full: “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil”. Knuth himself attributes the remark to C. A. R. Hoare. The Unix Philosophy in One Lesson All the philosophy really boils down to one iron law, the hallowed ‘KISS principle’ of master engineers everywhere: Unix gives you an excellent base for applying the KISS principle. The remainder of this book will help you learn how. Applying the Unix Philosophy These philosophical principles aren't just vague generalities.
Forge Your Future with Open Source by VM (Vicky) Brasseur
AGPL, anti-pattern, Benevolent Dictator For Life (BDFL), call centre, continuous integration, Debian, DevOps, don't repeat yourself, en.wikipedia.org, Firefox, Guido van Rossum, Internet Archive, Larry Wall, microservices, Perl 6, premature optimization, pull request, Richard Stallman, risk tolerance, Turing machine
Add to that a tendency toward perfectionism and you have a recipe for what’s called premature optimization, or trying to optimize a program or process before you’ve had the chance to see whether that optimization is even needed. When premature optimization occurs while trying to prepare a project to release as FOSS, there’s a very good chance that the release will be delayed indefinitely as everything is over-considered, over-architected, but undoubtedly under-documented. If you’ve never released a FOSS project before, you naturally want to do everything possible to make sure it goes smoothly. You want every single bug to be fixed. You want all of the code to be pristine. While that’s admirable, it does open the door to that premature optimization. Instead of focusing only on the code, work to keep the entire process and all policies you establish for the project very simple and as clear as possible.
Instead of focusing only on the code, work to keep the entire process and all policies you establish for the project very simple and as clear as possible. Use the time you would have spent on premature optimization to make sure that the project and its policies are well documented. The combination of a simpler, easier to follow process and clear documentation about it not only encourages people to use and contribute to your project, but it also saves you time from having to answer relatively simple questions. Starting out with simple processes and policies doesn’t preclude adding complexity later, should you find it necessary. In fact, you’ll find that your simplicity will scale and allow for modifications much more easily than any complexity you would have implemented earlier on. This allows for a lot of flexibility should the project community grow beyond just a few contributors.
Super Thinking: The Big Book of Mental Models by Gabriel Weinberg, Lauren McCann
affirmative action, Affordable Care Act / Obamacare, Airbnb, Albert Einstein, anti-pattern, Anton Chekhov, autonomous vehicles, bank run, barriers to entry, Bayesian statistics, Bernie Madoff, Bernie Sanders, Black Swan, Broken windows theory, business process, butterfly effect, Cal Newport, Clayton Christensen, cognitive dissonance, commoditize, correlation does not imply causation, crowdsourcing, Daniel Kahneman / Amos Tversky, David Attenborough, delayed gratification, deliberate practice, discounted cash flows, disruptive innovation, Donald Trump, Douglas Hofstadter, Edward Lorenz: Chaos theory, Edward Snowden, effective altruism, Elon Musk, en.wikipedia.org, experimental subject, fear of failure, feminist movement, Filter Bubble, framing effect, friendly fire, fundamental attribution error, Gödel, Escher, Bach, hindsight bias, housing crisis, Ignaz Semmelweis: hand washing, illegal immigration, income inequality, information asymmetry, Isaac Newton, Jeff Bezos, John Nash: game theory, lateral thinking, loss aversion, Louis Pasteur, Lyft, mail merge, Mark Zuckerberg, meta analysis, meta-analysis, Metcalfe’s law, Milgram experiment, minimum viable product, moral hazard, mutually assured destruction, Nash equilibrium, Network effects, nuclear winter, offshore financial centre, p-value, Parkinson's law, Paul Graham, peak oil, Peter Thiel, phenotype, Pierre-Simon Laplace, placebo effect, Potemkin village, prediction markets, premature optimization, price anchoring, principal–agent problem, publication bias, recommendation engine, remote working, replication crisis, Richard Feynman, Richard Feynman: Challenger O-ring, Richard Thaler, ride hailing / ride sharing, Robert Metcalfe, Ronald Coase, Ronald Reagan, school choice, Schrödinger's Cat, selection bias, Shai Danziger, side project, Silicon Valley, Silicon Valley startup, speech recognition, statistical model, Steve Jobs, Steve Wozniak, Steven Pinker, survivorship bias, The Present Situation in Quantum Mechanics, the scientific method, The Wisdom of Crowds, Thomas Kuhn: the structure of scientific revolutions, transaction costs, uber lyft, ultimatum game, uranium enrichment, urban planning, Vilfredo Pareto, wikimedia commons
Assumptions could be around cost (“I can afford this vacation”), satisfaction (“I will enjoy this vacation”), coordination (“my relatives can join me on this vacation”), etc. Here, de-risking is as easy as doing a few minutes of online research, reading reviews, and sending an email to your relatives. Unfortunately, people often make the mistake of doing way too much work before testing assumptions in the real world. In computer science this trap is called premature optimization, where you tweak or perfect code or algorithms (optimize) too early (prematurely). If your assumptions turn out to be wrong, you’re going to have to throw out all that work, rendering it ultimately a waste of time. It’s as if you booked an entire vacation assuming your family could join you, only to finally ask them and they say they can’t come. Then you have to go back and change everything, but all this work could have been avoided by a simple communication up front.
Realize that your intuitive interpretations of the world can often be wrong due to availability bias, fundamental attribution error, optimistic probability bias, and other related mental models that explain common errors in thinking. Use Ockham’s razor and Hanlon’s razor to begin investigating the simplest objective explanations. Then test your theories by de-risking your assumptions, avoiding premature optimization. Attempt to think gray in an effort to consistently avoid confirmation bias. Actively seek out other perspectives by including the Devil’s advocate position and bypassing the filter bubble. Consider the adage “You are what you eat.” You need to take in a variety of foods to be a healthy person. Likewise, taking in a variety of perspectives will help you become a super thinker. 2 Anything That Can Go Wrong, Will ALL YOUR ACTIONS HAVE CONSEQUENCES, but sometimes those consequences are unexpected.
., 38 oil, 105–6 Olympics, 209, 246–48, 285 O’Neal, Shaquille, 246 one-hundred-year floods, 192 Onion, 211–12 On the Origin of Species by Means of Natural Selection (Darwin), 100 OODA loop, 294–95 openness to experience, 250 Operation Ceasefire, 232 opinion, diversity of, 205, 206 opioids, 36 opportunity cost, 76–77, 80, 83, 179, 182, 188, 305 of capital, 77, 179, 182 optimistic probability bias, 33 optimization, premature, 7 optimums, local and global, 195–96 optionality, preserving, 58–59 Oracle, 231, 291, 299 order, 124 balance between chaos and, 128 organizations: culture in, 107–8, 113, 273–80, 293 size and growth of, 278–79 teams in, see teams ostrich with its head in the sand, 55 out-group bias, 127 outliers, 148 Outliers (Gladwell), 261 overfitting, 10–11 overwork, 82 Paine, Thomas, 221–22 pain relievers, 36, 137 Pampered Chef, 217 Pangea, 24–25 paradigm shift, 24, 289 paradox of choice, 62–63 parallel processing, 96 paranoia, 308, 309, 311 Pareto, Vilfredo, 80 Pareto principle, 80–81 Pariser, Eli, 17 Parkinson, Cyril, 74–75, 89 Parkinson’s law, 89 Parkinson’s Law (Parkinson), 74–75 Parkinson’s law of triviality, 74, 89 passwords, 94, 97 past, 201, 271–72, 309–10 Pasteur, Louis, 26 path dependence, 57–59, 194 path of least resistance, 88 Patton, Bruce, 19 Pauling, Linus, 220 payoff matrix, 212–15, 238 PayPal, 72, 291, 296 peak, 105, 106, 112 peak oil, 105 Penny, Jonathon, 52 pent-up energy, 112 perfect, 89–90 as enemy of the good, 61, 89–90 personality traits, 249–50 person-month, 279 perspective, 11 persuasion, see influence models perverse incentives, 50–51, 54 Peter, Laurence, 256 Peter principle, 256, 257 Peterson, Tom, 108–9 Petrified Forest National Park, 217–18 Pew Research, 53 p-hacking, 169, 172 phishing, 97 phones, 116–17, 290 photography, 302–3, 308–10 physics, x, 114, 194, 293 quantum, 200–201 pick your battles, 238 Pinker, Steven, 144 Pirahã, x Pitbull, 36 pivoting, 295–96, 298–301, 308, 311, 312 placebo, 137 placebo effect, 137 Planck, Max, 24 Playskool, 111 Podesta, John, 97 point of no return, 244 Polaris, 67–68 polarity, 125–26 police, in organizations and projects, 253–54 politics, 70, 104 ads and statements in, 225–26 elections, 206, 218, 233, 241, 271, 293, 299 failure and, 47 influence in, 216 predictions in, 206 polls and surveys, 142–43, 152–54, 160 approval ratings, 152–54, 158 employee engagement, 140, 142 postmortems, 32, 92 Potemkin village, 228–29 potential energy, 112 power, 162 power drills, 296 power law distribution, 80–81 power vacuum, 259–60 practice, deliberate, 260–62, 264, 266 precautionary principle, 59–60 Predictably Irrational (Ariely), 14, 222–23 predictions and forecasts, 132, 173 market for, 205–7 superforecasters and, 206–7 PredictIt, 206 premature optimization, 7 premises, see principles pre-mortems, 92 present bias, 85, 87, 93, 113 preserving optionality, 58–59 pressure point, 112 prices, 188, 231, 299 arbitrage and, 282–83 bait and switch and, 228, 229 inflation in, 179–80, 182–83 loss leader strategy and, 236–37 manufacturer’s suggested retail, 15 monopolies and, 283 principal, 44–45 principal-agent problem, 44–45 principles (premises), 207 first, 4–7, 31, 207 prior, 159 prioritizing, 68 prisoners, 63, 232 prisoner’s dilemma, 212–14, 226, 234–35, 244 privacy, 55 probability, 132, 173, 194 bias, optimistic, 33 conditional, 156 probability distributions, 150, 151 bell curve (normal), 150–52, 153, 163–66, 191 Bernoulli, 152 central limit theorem and, 152–53, 163 fat-tailed, 191 power law, 80–81 sample, 152–53 pro-con lists, 175–78, 185, 189 procrastination, 83–85, 87, 89 product development, 294 product/market fit, 292–96, 302 promotions, 256, 275 proximate cause, 31, 117 proxy endpoint, 137 proxy metric, 139 psychology, 168 Psychology of Science, The (Maslow), 177 Ptolemy, Claudius, 8 publication bias, 170, 173 public goods, 39 punching above your weight, 242 p-values, 164, 165, 167–69, 172 Pygmalion effect, 267–68 Pyrrhus, King, 239 Qualcomm, 231 quantum physics, 200–201 quarantine, 234 questions: now what, 291 what if, 122, 201 why, 32, 33 why now, 291 quick and dirty, 234 quid pro quo, 215 Rabois, Keith, 72, 265 Rachleff, Andy, 285–86, 292–93 radical candor, 263–64 Radical Candor (Scott), 263 radiology, 291 randomized controlled experiment, 136 randomness, 201 rats, 51 Rawls, John, 21 Regan, Ronald, 183 real estate agents, 44–45 recessions, 121–22 reciprocity, 215–16, 220, 222, 229, 289 recommendations, 217 red line, 238 referrals, 217 reframe the problem, 96–97 refugee asylum cases, 144 regression to the mean, 146, 286 regret, 87 regulations, 183–84, 231–32 regulatory capture, 305–7 reinventing the wheel, 92 relationships, 53, 55, 63, 91, 111, 124, 159, 271, 296, 298 being locked into, 305 dating, 8–10, 95 replication crisis, 168–72 Republican Party, 104 reputation, 215 research: meta-analysis of, 172–73 publication bias and, 170, 173 systematic reviews of, 172, 173 see also experiments resonance, 293–94 response bias, 142, 143 responsibility, diffusion of, 259 restaurants, 297 menus at, 14, 62 RetailMeNot, 281 retaliation, 238 returns: diminishing, 81–83 negative, 82–83, 93 reversible decisions, 61–62 revolving door, 306 rewards, 275 Riccio, Jim, 306 rise to the occasion, 268 risk, 43, 46, 90, 288 cost-benefit analysis and, 180 de-risking, 6–7, 10, 294 moral hazard and, 43–45, 47 Road Ahead, The (Gates), 69 Roberts, Jason, 122 Roberts, John, 27 Rogers, Everett, 116 Rogers, William, 31 Rogers Commission Report, 31–33 roles, 256–58, 260, 271, 293 roly-poly toy, 111–12 root cause, 31–33, 234 roulette, 144 Rubicon River, 244 ruinous empathy, 264 Rumsfeld, Donald, 196–97, 247 Rumsfeld’s Rule, 247 Russia, 218, 241 Germany and, 70, 238–39 see also Soviet Union Sacred Heart University (SHU), 217, 218 sacrifice play, 239 Sagan, Carl, 220 sales, 81, 216–17 Salesforce, 299 same-sex marriage, 117, 118 Sample, Steven, 28 sample distribution, 152–53 sample size, 143, 160, 162, 163, 165–68, 172 Sánchez, Ricardo, 234 sanctions and fines, 232 Sanders, Bernie, 70, 182, 293 Sayre, Wallace, 74 Sayre’s law, 74 scarcity, 219, 220 scatter plot, 126 scenario analysis (scenario planning), 198–99, 201–3, 207 schools, see education and schools Schrödinger, Erwin, 200 Schrödinger’s cat, 200 Schultz, Howard, 296 Schwartz, Barry, 62–63 science, 133, 220 cargo cult, 315–16 Scientific Autobiography and other Papers (Planck), 24 scientific evidence, 139 scientific experiments, see experiments scientific method, 101–2, 294 scorched-earth tactics, 243 Scott, Kim, 263 S curves, 117, 120 secondary markets, 281–82 second law of thermodynamics, 124 secrets, 288–90, 292 Securities and Exchange Commission, U.S., 228 security, false sense of, 44 security services, 229 selection, adverse, 46–47 selection bias, 139–40, 143, 170 self-control, 87 self-fulfilling prophecies, 267 self-serving bias, 21, 272 Seligman, Martin, 22 Semmelweis, Ignaz, 25–26 Semmelweis reflex, 26 Seneca, Marcus, 60 sensitivity analysis, 181–82, 185, 188 dynamic, 195 Sequoia Capital, 291 Sessions, Roger, 8 sexual predators, 113 Shakespeare, William, 105 Sheets Energy Strips, 36 Shermer, Michael, 133 Shirky, Clay, 104 Shirky principle, 104, 112 Short History of Nearly Everything, A (Bryson), 50 short-termism, 55–56, 58, 60, 68, 85 side effects, 137 signal and noise, 311 significance, 167 statistical, 164–67, 170 Silicon Valley, 288, 289 simulations, 193–95 simultaneous invention, 291–92 Singapore math, 23–24 Sir David Attenborough, RSS, 35 Skeptics Society, 133 sleep meditation app, 162–68 slippery slope argument, 235 slow (high-concentration) thinking, 30, 33, 70–71 small numbers, law of, 143, 144 smartphones, 117, 290, 309, 310 smoking, 41, 42, 133–34, 139, 173 Snap, 299 Snowden, Edward, 52, 53 social engineering, 97 social equality, 117 social media, 81, 94, 113, 217–19, 241 Facebook, 18, 36, 94, 119, 219, 233, 247, 305, 308 Instagram, 220, 247, 291, 310 YouTube, 220, 291 social networks, 117 Dunbar’s number and, 278 social norms versus market norms, 222–24 social proof, 217–20, 229 societal change, 100–101 software, 56, 57 simulations, 192–94 solitaire, 195 solution space, 97 Somalia, 243 sophomore slump, 145–46 South Korea, 229, 231, 238 Soviet Union: Germany and, 70, 238–39 Gosplan in, 49 in Cold War, 209, 235 space exploration, 209 spacing effect, 262 Spain, 243–44 spam, 37, 161, 192–93, 234 specialists, 252–53 species, 120 spending, 38, 74–75 federal, 75–76 spillover effects, 41, 43 sports, 82–83 baseball, 83, 145–46, 289 football, 226, 243 Olympics, 209, 246–48, 285 Spotify, 299 spreadsheets, 179, 180, 182, 299 Srinivasan, Balaji, 301 standard deviation, 149, 150–51, 154 standard error, 154 standards, 93 Stanford Law School, x Starbucks, 296 startup business idea, 6–7 statistics, 130–32, 146, 173, 289, 297 base rate in, 157, 159, 160 base rate fallacy in, 157, 158, 170 Bayesian, 157–60 confidence intervals in, 154–56, 159 confidence level in, 154, 155, 161 frequentist, 158–60 p-hacking in, 169, 172 p-values in, 164, 165, 167–69, 172 standard deviation in, 149, 150–51, 154 standard error in, 154 statistical significance, 164–67, 170 summary, 146, 147 see also data; experiments; probability distributions Staubach, Roger, 243 Sternberg, Robert, 290 stock and flow diagrams, 192 Stone, Douglas, 19 stop the bleeding, 234 strategy, 107–8 exit, 242–43 loss leader, 236–37 pivoting and, 295–96, 298–301, 308, 311, 312 tactics versus, 256–57 strategy tax, 103–4, 112 Stiglitz, Joseph, 306 straw man, 225–26 Streisand, Barbra, 51 Streisand effect, 51, 52 Stroll, Cliff, 290 Structure of Scientific Revolutions, The (Kuhn), 24 subjective versus objective, in organizational culture, 274 suicide, 218 summary statistics, 146, 147 sunk-cost fallacy, 91 superforecasters, 206–7 Superforecasting (Tetlock), 206–7 super models, viii–xii super thinking, viii–ix, 3, 316, 318 surface area, 122 luck, 122, 124, 128 surgery, 136–37 Surowiecki, James, 203–5 surrogate endpoint, 137 surveys, see polls and surveys survivorship bias, 140–43, 170, 272 sustainable competitive advantage, 283, 285 switching costs, 305 systematic review, 172, 173 systems thinking, 192, 195, 198 tactics, 256–57 Tajfel, Henri, 127 take a step back, 298 Taleb, Nassim Nicholas, 2, 105 talk past each other, 225 Target, 236, 252 target, measurable, 49–50 taxes, 39, 40, 56, 104, 193–94 T cells, 194 teams, 246–48, 275 roles in, 256–58, 260 size of, 278 10x, 248, 249, 255, 260, 273, 280, 294 Tech, 83 technical debt, 56, 57 technologies, 289–90, 295 adoption curves of, 115 adoption life cycles of, 116–17, 129, 289, 290, 311–12 disruptive, 308, 310–11 telephone, 118–19 temperature: body, 146–50 thermostats and, 194 tennis, 2 10,000-Hour Rule, 261 10x individuals, 247–48 10x teams, 248, 249, 255, 260, 273, 280, 294 terrorism, 52, 234 Tesla, Inc., 300–301 testing culture, 50 Tetlock, Philip E., 206–7 Texas sharpshooter fallacy, 136 textbooks, 262 Thaler, Richard, 87 Theranos, 228 thermodynamics, 124 thermostats, 194 Thiel, Peter, 72, 288, 289 thinking: black-and-white, 126–28, 168, 272 convergent, 203 counterfactual, 201, 272, 309–10 critical, 201 divergent, 203 fast (low-concentration), 30, 70–71 gray, 28 inverse, 1–2, 291 lateral, 201 outside the box, 201 slow (high-concentration), 30, 33, 70–71 super, viii–ix, 3, 316, 318 systems, 192, 195, 198 writing and, 316 Thinking, Fast and Slow (Kahneman), 30 third story, 19, 92 thought experiment, 199–201 throwing good money after bad, 91 throwing more money at the problem, 94 tight versus loose, in organizational culture, 274 timeboxing, 75 time: management of, 38 as money, 77 work and, 89 tipping point, 115, 117, 119, 120 tit-for-tat, 214–15 Tōgō Heihachirō, 241 tolerance, 117 tools, 95 too much of a good thing, 60 top idea in your mind, 71, 72 toxic culture, 275 Toys “R” Us, 281 trade-offs, 77–78 traditions, 275 tragedy of the commons, 37–40, 43, 47, 49 transparency, 307 tribalism, 28 Trojan horse, 228 Truman Show, The, 229 Trump, Donald, 15, 206, 293 Trump: The Art of the Deal (Trump and Schwartz), 15 trust, 20, 124, 215, 217 trying too hard, 82 Tsushima, Battle of, 241 Tupperware, 217 TurboTax, 104 Turner, John, 127 turn lemons into lemonade, 121 Tversky, Amos, 9, 90 Twain, Mark, 106 Twitter, 233, 234, 296 two-front wars, 70 type I error, 161 type II error, 161 tyranny of small decisions, 38, 55 Tyson, Mike, 7 Uber, 231, 275, 288, 290 Ulam, Stanislaw, 195 ultimatum game, 224, 244 uncertainty, 2, 132, 173, 180, 182, 185 unforced error, 2, 10, 33 unicorn candidate, 257–58 unintended consequences, 35–36, 53–55, 57, 64–65, 192, 232 Union of Concerned Scientists (UCS), 306 unique value proposition, 211 University of Chicago, 144 unknown knowns, 198, 203 unknowns: known, 197–98 unknown, 196–98, 203 urgency, false, 74 used car market, 46–47 U.S.
Code Complete (Developer Best Practices) by Steve McConnell
Ada Lovelace, Albert Einstein, Buckminster Fuller, call centre, continuous integration, data acquisition, database schema, don't repeat yourself, Donald Knuth, fault tolerance, Grace Hopper, haute cuisine, if you see hoof prints, think horses—not zebras, index card, inventory management, iterative process, Larry Wall, loose coupling, Menlo Park, Perl 6, place-making, premature optimization, revision control, Sapir-Whorf hypothesis, slashdot, sorting algorithm, statistical model, Tacoma Narrows Bridge, the scientific method, Thomas Kuhn: the structure of scientific revolutions, Turing machine, web application
This flies in the face of the folk wisdom that you can code like hell and then test all the mistakes out of the software. That idea is dead wrong. Testing merely tells you the specific ways in which your software is defective. Testing won't make your program more usable, faster, smaller, more readable, or more extensible. Premature optimization is another kind of process error. In an effective process, you make coarse adjustments at the beginning and fine adjustments at the end. If you were a sculptor, you'd rough out the general shape before you started polishing individual features. Premature optimization wastes time because you spend time polishing sections of code that don't need to be polished. You might polish sections that are small enough and fast enough as they are, you might polish code that you later throw away, and you might fail to throw away bad code because you've already spent time polishing it.
When you tune code, you're implicitly signing up to reprofile each optimization every time you change your compiler brand, compiler version, library version, and so on. If you don't reprofile, an optimization that improves performance under one version of a compiler or library might well degrade performance when you change the build environment. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. — Donald Knuth You should optimize as you go—false! One theory is that if you strive to write the fastest and smallest possible code as you write each routine, your program will be fast and small. This approach creates a forest-for-the-trees situation in which programmers ignore significant global optimizations because they're too busy with micro-optimizations.
Developers immerse themselves in algorithm analysis and arcane debates that in the end don't contribute much value to the user. Concerns such as correctness, information hiding, and readability become secondary goals, even though performance is easier to improve later than these other concerns are. Post hoc performance work typically affects less than five percent of a program's code. Would you rather go back and do performance work on five percent of the code or readability work on 100 percent? In short, premature optimization's primary drawback is its lack of perspective. Its victims include final code speed, performance attributes that are more important than code speed, program quality, and ultimately the software's users. If the development time saved by implementing the simplest program is devoted to optimizing the running program, the result will always be a program that runs faster than one developed with indiscriminate optimization efforts (Stevens 1981).
Write Great Code, Volume 2 by Randall Hyde
Optimization can fine-tune the performance of a system, but it can rarely deliver a miracle. Although the quote is often attributed to Donald Knuth, who popularized it, it was Tony Hoare who originally said, “Premature optimization is the root of all evil.” This statement has long been the rallying cry of software engineers who avoid any thought of application performance until the very end of the software-development cycle—at which point the optimization phase is typically ignored for economic or time-to-market reasons. However, Hoare did not say, “Concern about application performance during the early stages of an application’s development is the root of all evil.” He specifically said premature optimization, which, back then, meant counting cycles and instructions in assembly language code—not the type of coding you want to do during initial program design, when the code base is rather fluid.
The following excerpt from a short essay by Charles Cook (www.cookcomputing.com/blog/archives/000084.html) describes the problem with reading too much into this statement: I’ve always thought this quote has all too often led software designers into serious mistakes because it has been applied to a different problem domain to what was intended. The full version of the quote is “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.” and I agree with this. It’s usually not worth spending a lot of time micro-optimizing code before it’s obvious where the performance bottlenecks are. But, conversely, when designing software at a system level, performance issues should always be considered from the beginning. A good software developer will do this automatically, having developed a feel for where performance issues will cause problems.
These chapters describe disassemblers, object code dump tools, debuggers, various HLL compiler options for displaying assembly language code, and other useful software tools. The remainder of the book, Chapter 7 through Chapter 15, describes how compilers generate machine code for different HLL statements and data types. Armed with this knowledge, you will be able to choose the most appropriate data types, constants, variables, and control structures to produce efficient applications. While you read, keep Dr. Hoare’s quote in mind: “Premature optimization is the root of all evil.” It is certainly possible to misapply the information in this book and produce code that is difficult to read and maintain. This would be especially disastrous during the early stages of your project’s design and implementation, when the code is fluid and subject to change. But remember: This book is not about choosing the most efficient statement sequence, regardless of the consequences; it is about understanding the cost of various HLL constructs so that, when you have a choice, you can make an educated decision concerning which sequence to use.
Code Simplicity by Max Kanat-Alexander
That’s something you should fix. Sometimes a user will report that there’s a bug, when actually it’s the program behaving exactly as you intended it to. In this case, it’s a matter of majority rules. If a significant number of users think that the behavior is a bug, it’s a bug. If only a tiny minority (like one or two) think it’s a bug, it’s not a bug. The most famous error in this area is what we call “premature optimization.” That is, some developers seem to like to make things go fast, but they spend time optimizing their code before they know that it’s slow! This is like a charity sending food to rich people and saying, “We just wanted to help people!” Illogical, isn’t it? They’re solving a problem that doesn’t exist. The only parts of your program where you should be concerned about speed are the exact parts that you can show are causing a real performance problem for your users.
Getting Real by Jason Fried, David Heinemeier Hansson, Matthew Linderman, 37 Signals
call centre, David Heinemeier Hansson, iterative process, John Gruber, knowledge worker, Merlin Mann, Metcalfe's law, performance metric, post-work, premature optimization, Ruby on Rails, slashdot, Steve Jobs, web application
Most attempts at optimization — tying something down very explicitly — reduces the breadth and scope of interactions and relationships, which is the very source of emergence. In the flocking birds example, as with a well-designed system, it's the interactions and relationships that create the interesting behavior. The harder we tighten things down, the less room there is for a creative, emergent solution. Whether it's locking down requirements before they are well understood or prematurely optimizing code, or inventing complex navigation and workflow scenarios before letting end users play with the system, the result is the same: an overly complicated, stupid system instead of a clean, elegant system that harnesses emergence. Keep it small. Keep it simple. Let it happen. —Andrew Hunt, The Pragmatic Programmers Table of contents | Essay list for this chapter | Next essay The Three Musketeers Use a team of three for version 1.0 For the first version of your app, start with only three people.
Relevant Search: With Examples Using Elasticsearch and Solr by Doug Turnbull, John Berryman
commoditize, crowdsourcing, domain-specific language, finite state, fudge factor, full text search, information retrieval, natural language processing, premature optimization, recommendation engine, sentiment analysis
Violating the prime directive Star Trek was notorious for having rules that brash starship captains routinely violated. Well, by indexing TMDB directly, you violated some advice we gave earlier. You directly placed the source data model into Elasticsearch. Shouldn’t you have done some signal modeling? If you use this data directly to create a search index, won’t you end up with relevance problems? Well, yes, but that’s for a good reason. Search is a place ripe for premature optimization. You’re likely to reach the heat death of the universe before achieving a perfect search solution in every direction. You know there will be relevance problems, but you don’t quite know what those are until you experiment with user searches. There are few areas that emphasize “fail fast” as much as search relevance. Load your data, get something basic working, find where it’s broken, reconfigure, reindex if need be, requery, rinse, and repeat.
combining high-value tiers scored with simple Solr multiplying variables MUST clause, 2nd MUST_NOT clause, 2nd my_doublemetaphone filter N n-gram token filter n-gramming analyzer name field named attributes negative boosting nested documents no_match_size parameter nongreedy clauses nonwinning fields normalize acronyms NOT operator number_of_fragments numerical attributes numerical boosts numerical data num_of_fragments parameter O OLAP (online analytical processing) optimizing signals OR operator order parameter ordering documents origin variable original_id field, 2nd overview field, 2nd P PageRank algorithm, 2nd, 3rd pair tuning, 2nd paired relevance tuning parent-child documents parentheses parsons analyzer Parsons code path_hierarchy analyzer path_hierarchy tokenizer paths, modeling specificity with pattern_capture filter payloads, 2nd people.name field, 2nd persona personalizing search based on user behavior collaborative filtering tying behavior information back to search index based on user profiles gathering profile information tying profile information back to search index concept search and phone_number field phone_num_parts filter phonetic analyzer phonetic plugin phonetic tokenization, 2nd, 3rd phrase query, 2nd, 3rd phrase-matching clause phrases, concept search and pogo-sticking popularity field position entry positional and phrase matching postings highlighter, 2nd postings list, 2nd post_tags parameter precision analysis for by example combining field-centric and term-centric search multiple search terms and multiple fields phonetic tokenization scoring strength of feature in single field premature optimization pre_tags parameter price field prioritizing documents product codes product owner profile-based personalization profiles promoted field prose text pseudo-content Python example search application Q quadrants query behavior, explaining Query DSL, 2nd, 3rd query function query matching, debugging analysis to solve matching issues comparing query to inverted index fixing by changing analyzers query parsing underlying strategy query normalization query parameter query parsers, 2nd, 3rd query validation endpoint, 2nd query-time analysis, 2nd, 3rd query-time boosting query-time personalization queryNorm queryWeight, 2nd quotes R ranking adding high-value tiers adding new tier for medium-confidence boosts tiered relevance layers debugging computing weight explain feature scoring matches to measure relevance search term importance similarity vector-space model learning to rank term-centric real-estate search recall analysis for by example combining field-centric and term-centric search improving multiple search terms and multiple fields phonetic tokenization scoring strength of feature in single field recency achieving users’ recency goals overview reducing boost weight reindex function, 2nd, 3rd, 4th reindexing with English analyzer related_items field relevance engineers duties of gaining skills of overview relevance.
ANSI Common LISP by Paul Graham
A profiler is a valuable tool—perhaps even a necessity—in producing the most efficient code. If your Lisp implementation provides one, use it to guide optimization. If not, you are reduced to guessing where the bottlenecks are, and you might be surprised how often such guesses turn out to be wrong. A corollary of the bottleneck rule is that one should not put too much effort into optimization early in a program's life. Knuth puts the point even more strongly: "Premature optimization is the root of all evil (or at least most of it) in programming."0 It's hard to see where the real bottlenecks will be when you've just started writing a program, so there's more chance you'll be wasting your time. Optimizations also tend to make a program harder to change, so trying to write a program and optimize it at the same time can be like trying to paint a picture with paint that dries too fast.
162 n i n t e r s e c t i o n function 357, 222 n i n t h function 357,40 no-applicable-method generic function 334 no-next-method generic function 334 Norvig, Peter 410,412 not function 321, 13 not any function 321 not every function 321 not i n l i n e declaration 315, 313 nreconc function 359 nreverse function 369, 222 n s e t - d i f f erence function 359, 222 n s e t - e x c l u s i v e - o r function 359 n s t r i n g - c a p i t a l i z e function 365 nstring-downcase function 365 n s t r i n g - u p c a s e function 365 n s u b l i s function 359 nsubst function 360, 222 n s u b s t - i f function 360, 222 n s u b s t - i f - n o t function 360 n s u b s t i t u t e function 369 nsubst i t u t e - i f function 369 n s u b s t i t u t e - i f - n o t function 370 n t h function 358,39 n t h - v a l u e macro 321 n t h c d r function 358,39 ntimes 167 n u l l function 358, 13 numbers comparison of 146 complex 143 conversion to reals 144 extracting components of 146 floating-point 143 contagion 143 limits of 150,407 overflow 150 printing 124 types of 150 integer 11 no limit on size of 150 parsing 68 see also: bignums, fixnums random 146 ratio 143 conversion to integers 144 extracting components of 146 types of 143 converting between 144 numberp function 351, 20 numerator function 351, 146 nunion function 360, 222 object-oriented programming 176 analogy to hardware 176 benefits of 178 broad application of term 285 implementing 269 for reusable software 104 as a way to get run-time typing 410 and spaghetti code 408 transcended by Lisp 2, 285 two models of 192 see also: classes, CLOS, encapsulation, inheritance, instances, messagepassing, methods, multimethods, slots oddp function 352, 44, 147 oil paint 5,402 open function 376, 120 open-stream-p generic function 377 operator 8 optimization destructive operations 222 efficient algorithms 214 fast operators 228 426 focus of 213 premature 214, 229 tail recursion—see recursion, tail see also: consing, avoiding optimize declaration 315, 313 feoptional—see parameters, optional or macro 321, 14 OS/360 4 otherwise symbol 316 output 18, 123 output-stream-p generic function 377 overflow—see numbers, floating-point packages based on names 239 default 136,236 defining 137 exporting from 137, 238 grossness of 411 importing into 238 nicknames of 137 purpose of 136,237 setting 137 used 137,239 •package* variable 394, 236 package-error-package generic function 345 package-name function 345, 236 package-nicknames function 345 package-shadowing-symbols function 345 p a c k a g e - u s e - l i s t function 346 p a c k a g e - u s e d - b y - l i s t function 346 packagep function 345 painting 5, 214, 402 p a i r l i s function 358 palindromes 46, 63 parentheses 8, 17 parameters 14 compilation—see compilation parameters congruent 186 efficiency of 228 keyword 103 optional 102 required 102 rest 102 specialized—see specialization p a r s e - i n t e g e r function 352, 68 parse-namestring function 372 pathname function 372 pathnames 120 pathname-device function 373 INDEX pathname-directory function 373 pathname-host function 372 pathname-mat ch-p function 373 pathname-name function 373 pathname-type function 373 pathname-vers ion function 373 pathnamep function 373 patterns for destructuring 85, 103 matching 249 peek-char function 377, 123 phase function 352 Perdue, Crispin 401 PGM 152 p i constant 394, 149 Pitman, Kent M. 401 planning 5,229 plists—see property lists plusp function 352, 147 poetry 407 pointers avoiding 219 conses as pairs of 32 implicit 34 see also: lists pop macro 359, 47 p o s i t i o n function 367, 64 p o s i t i o n - i f function 367, 65 p o s i t i o n - i f - n o t function 368 p p r i n t function 384, 168 p p r i n t - d i s p a t c h function 384 pprint-exit-if-list-exhausted macro 384 p p r i n t - f i l l function 384 p p r i n t - i n d e n t function 384 p p r i n t - l i n e a r function 384 p p r i n t - l o g i c a l - b l o c k macro 384 p p r i n t - n e w l i n e function 385 p p r i n t - p o p macro 385 p p r i n t - t a b function 385 p p r i n t - t a b u l a r function 385 precedence 182 implementing 274 purpose of 183 prefix notation 8 premature optimization 214 primary methods 187 p r i n l function 386, 123 p r i n l - t o - s t r i n g function 386 p r i n c function 385,123 p r i n c - t o - s t r i n g function 385 p r i n t function 385, 160 • p r i n t - a r r a y * variable 394, 59, 280 • p r i n t - b a s e * variable 394, 113 INDEX • p r i n t - c a s e * variable 394 • p r i n t - c i r c l e * variable 394, 208 • p r i n t - e s c a p e * variable 394 •print-gensym* variable 395 • p r i n t - l e n g t h * variable 395 • p r i n t - l e v e l * variable 395 • p r i n t - l i n e s * variable 395 • p r i n t - m i s e r - w i d t h * variable 395 p r i n t - n o t - r e a d a b l e - o b j ect generic function 385 p r i n t - o b j e c t generic function 385 *print-pprint-dispatch* variable 395 • p r i n t - p r e t t y * variable 395 • p r i n t - r a d i x * variable 395 • p r i n t - r e a d a b l y * variable 395 * p r i n t - r i g h t - m a r g i n * variable 395 p r i n t - u n r e a d a b l e - o b j e c t macro 386, 70 p r o b e - f i l e function 374 proclaim function 315, 215 profilers 214 prog macro 321 prog* macro 321 progl macro 321, 127, 274 prog2 macro 321 progn special operator 321, 24 progv special operator 321 prompt 7, 19 property lists 134 provide function 388 psetf macro 322 psetq macro 322 push macro 359,47 pushnew macro 359, 49 qualifiers 188 •query-io* variable 395 queues using lists as—see lists, as queues using vectors as 126 Quicksort 164 quote special operator 315, 10, 161 random function 352, 146 random-choice 170 •random-state* variable 395 random-state-p function 352 random text 138 rapid prototyping 3, 23, 401 rassoc function 359 r a s s o c - i f function 359 r a s s o c - i f - n o t function 359 427 ratios—see numbers, ratio r a t i o n a l function 352 r a t i o n a l i z e function 352 r a t ionalp function 352 ray-tracing 151 r c u r r y 110 read function 387, 18, 122 • r e a d - b a s e * variable 395 r e a d - b y t e function 377, 234 r e a d - c h a r function 377, 123 r e ad-char-no-hang function 377 •read-default-float-format* variable 396 r e a d - d e l i m i t e d - l i s t function 387, 236 *read-eval* variable 396, 406 r e a d - f r o m - s t r i n g function 387, 123 r e a d - l i n e function 377, 121 read-macros defining 235 dispatching 131, 235 predefined 399, 130 read-preserving-whitespace function 387 read-sequence function 377 *read-suppress* variable 396 • r e a d t a b l e * variable 396 r e a d t a b l e - c a s e function 387 r e a d t a b l e p function 387 r e a l p function 352 r e a l p a r t function 352, 146 Rees, Jonathan A. 405, 411 recursion 16 efficiency of 116 and functional programming 114 can't be inlined 217 local 101 proper metaphor for 16 tail 116,215,289,409 using 114 verifying 42 reduce function 368, 66 extends two-argument functions 66 : key argument to 406 more efficient than apply 228 r e i n i t i a l i z e - i n s t a n c e generic function 334 rem function 352, 145 remf macro 359 remhash function 371 remove function 368, 22, 55, 66 remove-duplicates function 368, 66 remove-if function 368, 66 remove-if-not function 368 428 remove-method generic function 335 remprop function 343 rename-f i l e function 374 rename-package function 346 rendering 151 r e p l a c e function 369 Replicator 414 r e q u i r e function 388 ftrest—see parameters, rest r e s t function 359 r e s t a r t - b i n d macro 340 r e s t a r t - c a s e macro 341 r e s t a r t - n a m e function 341 r e t u r n macro 322, 82 return-from special operator 322, 81 reusable software 3, 104 revappend function 359 r e v e r s e function 369, 46 rewriting 262,402 rhyming dictionaries 224 ring buffers 126 risk 5, 6 room function 390 r o t a t e f macro 322, 165 round function 352, 145 rounding to even digit 145 unpredictable, by format 125 row-major-aref function 363 row-major order 221 r p l a c a function 359 r p l a c d function 359 rules 247 run-length encoding 36 run-time typing 2,6,218,410 Russell, Stuart 412 s a f e t y compilation parameter 214 s b i t function 363 s c a l e - f l o a t function 352 schar function 364 Scheme 109,405,411 scope 112,405 search function 369 search binary 60 breadth-first 51 second function 357, 40 Sedgewick, Robert 402, 406 self-modifying programs 210 sequences 45, 63 access to elements of 63 copying segments of 46 INDEX finding the lengths of 45 finding elements of 64 removing duplicates from 66 replacing elements of 41 reversing 46 sorting 46, 164 see also: arrays, lists, vectors sequence functions 63 s e t function 343 sets hash tables as 77 lists as 43 s e t - d i f f e r e n c e function 359, 45 set-dispatch-macro-character function 387,235 s e t - e x c l u s i v e - o r function 359 set-macro-character function 387, 235 s e t - p p r i n t - d i s p a t c h function 386 set-syntax-from-char function 387 s e t f macro 322, 21 defining expansions of 100, 404 macros that expand into 168 macro call as first argument to 168 s e t q special operator 322 seventh function 357, 40 shadow function 346 shadowing-import function 346 Shalit, Andrew 405 s h a r e d - i n i t i a l i z e generic function 335 sharp-quote 25, 131 s h i f t f macro 322 s h o r t - f l o a t - e p s i l o n constant 392 s h o r t - f l o a t - n e g a t i v e - e p s i l o n constant 392 s h o r t - s i t e - n a m e function 390 shortest path 51 side-effects 19,22,201 s i g n a l function 341 signum function 353,146 s i m p l e - b i t - v e c t o r - p function 363 simple-condition-formatarguments generic function 341 simple-condition-format-control generic function 341 s i m p l e - s t r i n g - p function 364 simple-vector-p function 364 s i n function 353, 149 s i n g l e ?
Hands-On Functional Programming in RUST by Andrew Johnson
In this chapter, we will learn the following: Recognizing and applying good performant code practices Diagnosing and improving performance bottlenecks Recognizing and applying good defensive coding practices Diagnosing and resolving software bugs Recognizing and applying metaprogramming techniques Technical requirements A recent version of Rust is necessary to run the examples provided: https://www.rust-lang.org/en-US/install.html This chapter's code is available on GitHub: https://github.com/PacktPublishing/Hands-On-Functional-Programming-in-RUST Specific installation and build instructions are also included in each chapter's README.md file. Writing faster code Premature optimization is the root of all evil – Donald Knuth A good software design tends to create faster programs, while a bad software design tends to create slower programs. If you find yourself asking, "Why is my program slow?, then first ask yourself, Is my program disorderly?" In this section, we describe some performance tips. These are generally good habits when programming in Rust that will coincidentally lead to improved performance.
Designing Web APIs: Building APIs That Developers Love by Brenda Jin, Saurabh Sahni, Amir Shevat
active measures, Amazon Web Services, augmented reality, blockchain, business process, continuous integration, create, read, update, delete, Google Hangouts, if you build it, they will come, Lyft, MITM: man-in-the-middle, premature optimization, pull request, Silicon Valley, Snapchat, software as a service, the market place, uber lyft, web application, WebSocket
To do operations asynchronously, you can use task queue services provided by various cloud service providers, like Amazon and Goo‐ gle. You can also use an open source task queue like Celery. Scaling Throughput Best Practices Here are some best practices that will help your applications to scale to high load: • Measure and find your bottlenecks first before starting to make changes for scaling. The database is the most common bottle‐ neck in modern applications. • Avoid premature optimizations. Scaling optimizations often come at a cost, and some of them can increase the development time of your application. Unless you have scaling problems, you probably don’t want to add that complexity. • Prefer horizontal scalability over vertical scalability. • Understand that database indexes are among the best ways to address slow database queries. • Determine which data you use frequently, and cache it. • If you add caching, do not forget to add cache invalidation. • Consider performing expensive operations asynchronously.
The Practice of Cloud System Administration: DevOps and SRE Practices for Web Services, Volume 2 by Thomas A. Limoncelli, Strata R. Chalup, Christina J. Hogan
active measures, Amazon Web Services, anti-pattern, barriers to entry, business process, cloud computing, commoditize, continuous integration, correlation coefficient, database schema, Debian, defense in depth, delayed gratification, DevOps, domain-specific language, en.wikipedia.org, fault tolerance, finite state, Firefox, Google Glasses, information asymmetry, Infrastructure as a Service, intermodal, Internet of things, job automation, job satisfaction, Kickstarter, load shedding, longitudinal study, loose coupling, Malcom McLean invented shipping containers, Marc Andreessen, place-making, platform as a service, premature optimization, recommendation engine, revision control, risk tolerance, side project, Silicon Valley, software as a service, sorting algorithm, standardized shipping container, statistical model, Steven Levy, supply-chain management, Toyota Production System, web application, Yogi Berra
This is where the design features that enable further scaling come into play. While every effort is made to foresee potential scaling issues, not all of them can receive engineering attention. The additional design and coding effort that will help deal with future potential scaling issues is lower priority than writing code to fix the immediate issues of the day. Spending too much time preventing scaling problems that may or may not happen is called premature optimization and should be avoided. 5.1.1 Identify Bottlenecks A bottleneck is a point in the system where congestion occurs. It is a point that is resource starved in a way that limits performance. Every system has a bottleneck. If a system is underperforming, the bottleneck can be fixed to permit the system to perform better. If the system is performing well, knowing the location of the bottleneck can be useful because it enables us to predict and prevent future problems.
., 11 Playbooks oncall, 297–298 process, 153 Pods, 137 Points of presence (POPs), 83–85 Pollers, 352 Post-crash recovery, 35 Postmortems, 152 communication, 302 DevOps, 184 oncall, 291, 300–302 purpose, 300–301 reports, 301–302 templates, 484–485 Power failures, 34, 133 Power of 2 mapping process, 110–111 Practical Approach to Large-Scale Agile Development: How HP Transformed HP LaserJet FutureSmart Firmware, 188 Practice of System and Network Administration, 132, 204 Pre-checks, 141 Pre-shift oncall responsibilities, 294 Pre-submit checks in build phase, 202–203 Pre-submit tests, 267 Pre-web era (1985-1994), 452–455 Prefork processing module, 114 Premature optimization, 96 Prescriptive failure domains, 127 Primary resources capacity planning, 372 defined, 366 Prioritizing automation, 257–258 feature requests, 46 for stability, 150 Privacy in platform selection, 63 Private cloud factor in platform selection, 62 Private sandbox environments, 197 Proactive scaling solutions, 97–98 Problems to solve in DevOps, 187 Process watchers, 128 Processes automation benefits, 253 containers, 60 instead of threads, 114 Proctors for Game Day, 318 Product Management (PM) monitoring, 336 Production candidates, 216 Production health in continuous deployment, 237 Project-focused days, 162–163 Project planning frequencies, 410 Project work, 161–162 Promotion step in deployment phase, 212 Propellerheads, 451 Proportional shedding, 230 Protocols collections, 351 network, 489 Prototyping, 258 Provider comparisons in service platform selection, 53 Provisional end-of-shift reports, 299 Provisioning in capacity planning, 384–385 in DevOps, 185–186 Proxies monitoring, 352 reverse proxy service, 80 Public cloud factor in platform selection, 62 Public Information Officers in Incident Command System, 325–326 Public key infrastructure (PKI), 40 Public safety arena in Incident Command System, 325 Publishers in message bus architectures, 85 Publishing postmortems, 302 PubSub2 system, 86 Pull monitoring, 350–351 Puppet systems configuration management, 261 deployment phase, 213 multitenant, 271 Push conflicts in continuous deployment, 238 Push monitoring, 350–351 “Pushing Millions of Lines of Code Five Days a Week” presentation, 233 PV (paravirtualization), 58–59 Python language libraries, 55 overview, 259–261 QPS (queries per second) defined, 10 limiting, 40–41 Quadratic scaling, 476 Quality Assurance monitoring, 335 Quality assurance (QA) engineers, 199 Quality measurements, 402 Queries in HTTP, 69 Queries of death, 130–131 Queries per second (QPS) defined, 10 limiting, 40–41 Queues, 113 benefits, 113 draining, 35–36 issue tracking systems, 263 messages, 86 variations, 113–114 Quick fixes vs. long-term, 295–296 RabbitMQ service, 86 Rachitsky, L., 302 Rack diversity, 136 Racks failures, 136 locality, 137 RAID systems, 132 RAM for caching, 104–106 failures, 123, 131–132 Random testing for disaster preparedness, 314–315 Rapid development, 231–232 Rate limits in design for operations, 40–41 Rate monitoring, 348 Rationale, documenting, 276 Re-assimilate tool, 255 Read-only replica support, 37 Real-time analysis, 353 Real user monitoring (RUM), 333 Reboots, 34 Recommendations in postmortem reports, 301 Recommended reading, 487–489 Recovery-Oriented Computing (ROC), 461 Recovery tool, 255 Redis storage system, 24, 106 Reduced risk factor in service delivery, 200 Reducing risk, 309–311 Reducing toil, automation for, 257 Redundancy design for operations, 37 file chunks, 20 for resiliency, 124–125 servers, 17 Reengineering components, 97 Refactoring, 97 Regional collectors, 352–353 Registering packages, 204, 206 Regression analysis, 375–376 Regression lines, 376 Regression tests for performance, 156, 215 Regular meetings in DevOps, 187 Regular oncall responsibilities, 294–295 Regular software crashes, 128 Regular Tasks (RT) assessments, 423–425 operational responsibility, 403 Regulating system integration, 250 Relationships in DevOps, 182 Release atomicity, 240–241 Release candidates, 197 Release engineering practice in DevOps, 186 Release vehicle packaging in DevOps, 185 Releases defined, 196 DevOps, 185 Reliability automation for, 253 message bus architectures, 87 Reliability zones in service platform selection, 53–54 Remote hands, 163 Remote monitoring stations, 352 Remote Procedure Call (RPC) protocol, 41 Repair life cycle, 254–255 Repeatability automation for, 253 continuous delivery, 190 Repeatable level in CMM, 405 Replacement algorithms for caches, 107 Replicas, 124 in design for operations, 37–38 load balancers with, 12–13 three-tier web service, 76 updating, 18 Reports for postmortems, 301–302 Repositories in build phase, 197 Reproducibility in continuous deployment, 237 Requests in updating state, 18 “Resilience Engineering: Learning to Embrace Failure” article, 320 Resiliency, 119–120 capacity planning, 370–371 DevOps, 178 exercises, 143 failure domains, 126–128 human error, 141–142 malfunctions, 121–123 overload failures, 138–141 physical failures.
Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs by Ken Kocienda
1960s counterculture, anti-pattern, Apple's 1984 Super Bowl advert, bash_history, Charles Lindbergh, conceptual framework, Donald Knuth, en.wikipedia.org, HyperCard, Kickstarter, Lao Tzu, premature optimization, profit motive, QWERTY keyboard, Richard Feynman, Richard Stallman, Robert X Cringely, Silicon Valley, Steve Ballmer, Steve Jobs, Steven Levy, zero-sum game
For software developers who take their work seriously, Knuth is the consummate craftsman. Here’s what he has to say about optimization: Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.2 (Emphasis added.) Optimization is the process where programmers try to make code execute faster. Isn’t that what the PLT was all about? So, isn’t optimization a good thing? Not always, and if the Knuthian numerical estimate is to be given the credence it deserves, and he is an extraordinarily deliberative man, then optimization is bad about 97 percent of the time.
The Pragmatic Programmer by Andrew Hunt, Dave Thomas
A Pattern Language, Broken windows theory, business process, buy low sell high, c2.com, combinatorial explosion, continuous integration, database schema, domain-specific language, don't repeat yourself, Donald Knuth, general-purpose programming language, George Santayana, Grace Hopper, if you see hoof prints, think horses—not zebras, index card, lateral thinking, loose coupling, Menlo Park, MVC pattern, premature optimization, Ralph Waldo Emerson, revision control, Schrödinger's Cat, slashdot, sorting algorithm, speech recognition, traveling salesman, urban decay, Y2K
Best Isn't Always Best You also need to be pragmatic about choosing appropriate algorithms—the fastest one is not always the best for the job. Given a small input set, a straightforward insertion sort will perform just as well as a quicksort, and will take you less time to write and debug. You also need to be careful if the algorithm you choose has a high setup cost. For small input sets, this setup may dwarf the running time and make the algorithm inappropriate. Also be wary of premature optimization. It's always a good idea to make sure an algorithm really is a bottleneck before investing your precious time trying to improve it. Related sections include: Estimating, page 64 Challenges Every developer should have a feel for how algorithms are designed and analyzed. Robert Sedgewick has written a series of accessible books on the subject ([Sed83, SF96, Sed92] and others).
Everything for Everyone: The Radical Tradition That Is Shaping the Next Economy by Nathan Schneider
1960s counterculture, Affordable Care Act / Obamacare, Airbnb, altcoin, Amazon Mechanical Turk, back-to-the-land, basic income, Berlin Wall, Bernie Sanders, bitcoin, blockchain, Brewster Kahle, Burning Man, Capital in the Twenty-First Century by Thomas Piketty, carbon footprint, Clayton Christensen, collaborative economy, collective bargaining, Community Supported Agriculture, corporate governance, creative destruction, crowdsourcing, cryptocurrency, Debian, disruptive innovation, do-ocracy, Donald Knuth, Donald Trump, Edward Snowden, Elon Musk, Ethereum, ethereum blockchain, Food sovereignty, four colour theorem, future of work, gig economy, Google bus, hydraulic fracturing, Internet Archive, Jeff Bezos, jimmy wales, joint-stock company, Joseph Schumpeter, Julian Assange, Kickstarter, Lyft, M-Pesa, Marc Andreessen, Mark Zuckerberg, Marshall McLuhan, mass immigration, means of production, multi-sided market, new economy, offshore financial centre, old-boy network, Peter H. Diamandis: Planetary Resources, post-work, precariat, premature optimization, pre–internet, profit motive, race to the bottom, Richard Florida, Richard Stallman, ride hailing / ride sharing, Sam Altman, Satoshi Nakamoto, self-driving car, shareholder value, sharing economy, Silicon Valley, Slavoj Žižek, smart contracts, Steve Jobs, Steve Wozniak, Stewart Brand, transaction costs, Turing test, Uber and Lyft, uber lyft, underbanked, undersea cable, universal basic income, Upton Sinclair, Vanguard fund, white flight, Whole Earth Catalog, WikiLeaks, women in the workforce, working poor, Y Combinator, Y2K, Zipcar
In the twentieth century, Charlie Chaplin and his friends formed United Artists to produce their own films, and photographers such as Henri Cartier-Bresson and Robert Capra formed Magnum, a cooperative syndication guild. Less glamorously, the professional organizations for doctors, lawyers, real estate agents, and hairdressers have clung to the guild model, complete with monopoly powers recognized by governments and peers. As we talked on the rooftop, Prime Produce’s founders freely mixed medieval idiom with that of Silicon Alley. Taeyoung cited the computer programming guru Donald Knuth’s dictum, “Premature optimization is the root of all evil.” That is, if they decided too much ahead of time and in too much detail, they wouldn’t be as flexible or as iterative. Hsu described what Prime Produce was doing as “crafted social innovation,” a form of “slow entrepreneurship.” The guild’s appeal wasn’t just nostalgic to them but was a means of navigating an often lonely, attention-deficient economy, by cultivating habits of excellence and communizing resources like office space, companionship, and broadband.
The Big Ratchet: How Humanity Thrives in the Face of Natural Crisis by Ruth Defries
agricultural Revolution, Columbian Exchange, demographic transition, double helix, European colonialism, food miles, Francisco Pizarro, Haber-Bosch Process, Intergovernmental Panel on Climate Change (IPCC), Internet Archive, John Snow's cholera map, out of africa, planetary scale, premature optimization, profit motive, Ralph Waldo Emerson, social intelligence, Thomas Malthus, trade route, transatlantic slave trade
There’s no way to stop the process of natural selection. A pesticide might work for a decade or two. Beyond that, natural selection is likely to render the compound ineffective. Companies in the pesticide market need to continually synthesize new compounds to combat resistance. Many, many hundreds of different synthesized pesticides exist for this reason. It’s a costly endeavor with no endpoint. Resistance put a big dent in the premature optimism that DDT would once and for all make humanity the victor in the battle against pests. Pest resistance wrought by natural selection wasn’t the only problem with the DDT bonanza. The pesticide, when sprayed across fields and forests and inside homes, attacked all living organisms with which it came into contact. Again, this wasn’t new. Before DDT, strychnine to control rodents killed quail and songbirds, and arsenic to control tree diseases killed deer.
Martin Kleppmann-Designing Data-Intensive Applications. The Big Ideas Behind Reliable, Scalable and Maintainable Systems-O’Reilly (2017) by Unknown
active measures, Amazon Web Services, bitcoin, blockchain, business intelligence, business process, c2.com, cloud computing, collaborative editing, commoditize, conceptual framework, cryptocurrency, database schema, DevOps, distributed ledger, Donald Knuth, Edward Snowden, Ethereum, ethereum blockchain, fault tolerance, finite state, Flash crash, full text search, general-purpose programming language, informal economy, information retrieval, Internet of things, iterative process, John von Neumann, Kubernetes, loose coupling, Marc Andreessen, microservices, natural language processing, Network effects, packet switching, peer-to-peer, performance metric, place-making, premature optimization, recommendation engine, Richard Feynman, self-driving car, semantic web, Shoshana Zuboff, social graph, social web, software as a service, software is eating the world, sorting algorithm, source of truth, SPARQL, speech recognition, statistical model, undersea cable, web application, WebSocket, wikimedia commons
This book breaks down the internals of various databases and data processing systems, and it’s great fun to explore the bright thinking that went into their design. Sometimes, when discussing scalable data systems, people make comments along the lines of, “You’re not Google or Amazon. Stop worrying about scale and just use a relational database.” There is truth in that statement: building for scale that you don’t need is wasted effort and may lock you into an inflexible design. In effect, it is a form of premature optimization. However, it’s also important to choose the right tool for the job, and different technologies each have their own strengths and weaknesses. As we shall see, relational databases are important but not the final word on dealing with data. Scope of This Book This book does not attempt to give detailed instructions on how to install or use spe‐ cific software packages or APIs, since there is already plenty of documentation for those things.
A single integra‐ ted software product may also be able to achieve better and more predictable perfor‐ mance on the kinds of workloads for which it is designed, compared to a system consisting of several tools that you have composed with application code . As I said in the Preface, building for scale that you don’t need is wasted effort and may lock you into an inflexible design. In effect, it is a form of premature optimization. The goal of unbundling is not to compete with individual databases on performance for particular workloads; the goal is to allow you to combine several different data‐ bases in order to achieve good performance for a much wider range of workloads than is possible with a single piece of software. It’s about breadth, not depth—in the same vein as the diversity of storage and processing models that we discussed in “Comparing Hadoop to Distributed Databases” on page 414.
Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems by Martin Kleppmann
active measures, Amazon Web Services, bitcoin, blockchain, business intelligence, business process, c2.com, cloud computing, collaborative editing, commoditize, conceptual framework, cryptocurrency, database schema, DevOps, distributed ledger, Donald Knuth, Edward Snowden, Ethereum, ethereum blockchain, fault tolerance, finite state, Flash crash, full text search, general-purpose programming language, informal economy, information retrieval, Infrastructure as a Service, Internet of things, iterative process, John von Neumann, Kubernetes, loose coupling, Marc Andreessen, microservices, natural language processing, Network effects, packet switching, peer-to-peer, performance metric, place-making, premature optimization, recommendation engine, Richard Feynman, self-driving car, semantic web, Shoshana Zuboff, social graph, social web, software as a service, software is eating the world, sorting algorithm, source of truth, SPARQL, speech recognition, statistical model, undersea cable, web application, WebSocket, wikimedia commons
This book breaks down the internals of various databases and data processing systems, and it’s great fun to explore the bright thinking that went into their design. Sometimes, when discussing scalable data systems, people make comments along the lines of, “You’re not Google or Amazon. Stop worrying about scale and just use a relational database.” There is truth in that statement: building for scale that you don’t need is wasted effort and may lock you into an inflexible design. In effect, it is a form of premature optimization. However, it’s also important to choose the right tool for the job, and different technologies each have their own strengths and weaknesses. As we shall see, relational databases are important but not the final word on dealing with data. Scope of This Book This book does not attempt to give detailed instructions on how to install or use specific software packages or APIs, since there is already plenty of documentation for those things.
A single integrated software product may also be able to achieve better and more predictable performance on the kinds of workloads for which it is designed, compared to a system consisting of several tools that you have composed with application code . As I said in the Preface, building for scale that you don’t need is wasted effort and may lock you into an inflexible design. In effect, it is a form of premature optimization. The goal of unbundling is not to compete with individual databases on performance for particular workloads; the goal is to allow you to combine several different databases in order to achieve good performance for a much wider range of workloads than is possible with a single piece of software. It’s about breadth, not depth—in the same vein as the diversity of storage and processing models that we discussed in “Comparing Hadoop to Distributed Databases”.
Coders at Work by Peter Seibel
Ada Lovelace, bioinformatics, cloud computing, Conway's Game of Life, domain-specific language, don't repeat yourself, Donald Knuth, fault tolerance, Fermat's Last Theorem, Firefox, George Gilder, glass ceiling, Guido van Rossum, HyperCard, information retrieval, Larry Wall, loose coupling, Marc Andreessen, Menlo Park, Metcalfe's law, Perl 6, premature optimization, publish or perish, random walk, revision control, Richard Stallman, rolodex, Ruby on Rails, Saturday Night Live, side project, slashdot, speech recognition, the scientific method, Therac-25, Turing complete, Turing machine, Turing test, type inference, Valgrind, web application
So now I say, “When Alan Turing wrote the first programming manual for the Mark I, in 1950. …” Mathematical things: similarly I'll get people who miss it. So then I'll say, you know, I actually said it correctly, but I know I still have to change it and make it better. Seibel: When you publish a literate program, it's the final form of the program, typically. And you are often credited with saying, “Premature optimization is the root of all evil.” But by the time you get to the final form it's not premature—you may have optimized some parts to be very clever. But doesn't that make it hard to read? Knuth: No. A good literate program will show its history. A good literate program will say, “Here's the obvious way to do it and then why we don't follow that road?” When you put subtle stuff in your program, literate programming shines because you don't just have the code that does it but also your documentation.
And read version two or you'll never understand version three.” I write a whole variety of different kinds of programs. Sometimes I'll write a program where I couldn't care less about efficiency—I just want to get the answer. I'll use brute force, something that I'm guaranteed I won't have to think—there'll be no subtlety at all so I won't be outsmarting myself. There I'm not doing any premature optimization. Then I can change that into something else and see if I get something that agrees with my brute-force way. Then I can scale up the program and go to larger cases. Most programs stop at that stage because you're not going to execute the code a trillion times. When I'm doing an illustration for The Art of Computer Programming I may change that illustration several times and the people who translate my book might have to redo the program, but it doesn't matter that I drew the illustration by a very slow method because I've only got to generate that file once and then it goes off to the publisher and gets printed in a book.
Ruby by example: concepts and code by Kevin C. Baird
Benevolent Dictator For Life (BDFL), David Heinemeier Hansson, Debian, digital map, Donald Knuth, en.wikipedia.org, Firefox, fudge factor, general-purpose programming language, Guido van Rossum, Larry Wall, MVC pattern, Paul Graham, Perl 6, premature optimization, union organizing, web application
Each new version of these factorial or Fibonacci scripts adds some feature intended to optimize the code, or produce a speed improvement. In some cases, these features result in a very dramatic improvement, but in other cases, they either fail to improve the code or sometimes even make it worse. The places where these attempts fail to improve speed are often as interesting as where they succeed. There’s an old adage among programmers: Premature optimization is the root of all evil.2 Keep that in mind while reading these examples. The Code For this chapter, we’ll be looking at some short scripts in pairs. Here’s factorial1.rb: #!/usr/bin/env ruby # factorial1.rb class Integer def fact() return 1 if (self.zero?) or (self == 1) return self * (self-1).fact end end And here’s fibonacci1.rb: #!/usr/bin/env ruby # fibonacci1.rb class Integer def fib() return 0 if (self.zero?)
Range: Why Generalists Triumph in a Specialized World by David Epstein
Airbnb, Albert Einstein, Apple's 1984 Super Bowl advert, Atul Gawande, Checklist Manifesto, Claude Shannon: information theory, Clayton Christensen, clockwork universe, cognitive bias, correlation does not imply causation, Daniel Kahneman / Amos Tversky, deliberate practice, Exxon Valdez, Flynn Effect, Freestyle chess, functional fixedness, game design, Isaac Newton, Johannes Kepler, knowledge economy, lateral thinking, longitudinal study, Louis Pasteur, Mark Zuckerberg, medical residency, meta analysis, meta-analysis, Mikhail Gorbachev, Nelson Mandela, Netflix Prize, pattern recognition, Paul Graham, precision agriculture, prediction markets, premature optimization, pre–internet, random walk, randomized controlled trial, retrograde motion, Richard Feynman, Richard Feynman: Challenger O-ring, Silicon Valley, Stanford marshmallow experiment, Steve Jobs, Steve Wozniak, Steven Pinker, Walter Mischel, Watson beat the top human players on Jeopardy!, Y Combinator, young professional
Most of the work I’ve done in the last ten years didn’t exist when I was in high school. . . . In such a world it’s not a good idea to have fixed plans. And yet every May, speakers all over the country fire up the Standard Graduation Speech, the theme of which is: don’t give up on your dreams. I know what they mean, but this is a bad way to put it, because it implies you’re supposed to be bound by some plan you made early on. The computer world has a name for this: premature optimization. . . . . . . Instead of working back from a goal, work forward from promising situations. This is what most successful people actually do anyway. In the graduation-speech approach, you decide where you want to be in twenty years, and then ask: what should I do now to get there? I propose instead that you don’t commit to anything in the future, but just look at the options available now, and choose those that will give you the most promising range of options afterward.
Building Microservices by Sam Newman
airport security, Amazon Web Services, anti-pattern, business process, call centre, continuous integration, create, read, update, delete, defense in depth, don't repeat yourself, Edward Snowden, fault tolerance, index card, information retrieval, Infrastructure as a Service, inventory management, job automation, Kubernetes, load shedding, loose coupling, microservices, MITM: man-in-the-middle, platform as a service, premature optimization, pull request, recommendation engine, social graph, software as a service, source of truth, the built environment, web application, WebSocket
One of the downsides is that this navigation of controls can be quite chatty, as the client needs to follow links to find the operation it wants to perform. Ultimately, this is a trade-off. I would suggest you start with having your clients navigate these controls first, then optimize later if necessary. Remember that we have a large amount of help out of the box by using HTTP, which we discussed earlier. The evils of premature optimization have been well documented before, so I don’t need to expand upon them here. Also note that a lot of these approaches were developed to create distributed hypertext systems, and not all of them fit! Sometimes you’ll find yourself just wanting good old-fashioned RPC. Personally, I am a fan of using links to allow consumers to navigate API endpoints. The benefits of progressive discovery of the API and reduced coupling can be significant.
Zero to Sold: How to Start, Run, and Sell a Bootstrapped Business by Arvid Kahl
"side hustle", business process, centre right, Chuck Templeton: OpenTable:, continuous integration, coronavirus, COVID-19, Covid-19, crowdsourcing, domain-specific language, financial independence, Google Chrome, if you build it, they will come, information asymmetry, information retrieval, inventory management, Jeff Bezos, job automation, Kubernetes, minimum viable product, Network effects, performance metric, post-work, premature optimization, risk tolerance, Ruby on Rails, sentiment analysis, Silicon Valley, software as a service, source of truth, statistical model, subscription business, supply-chain management, trickle-down economics, web application
This is an example of the classical "Next Feature Fallacy": the thinking that the next thing you do will have the big impact you're waiting for. But it usually doesn't. Usually, it will be yet another attempt at making a big difference and failing. This is a great opportunity to dust yourself off and try again. Just make sure you remove the feature that has proven not to work. Don't keep it hanging around. There are a number of other reasons that can cause you to build things you shouldn't have: "Premature Optimization"-like integrations. You thought you could use this eventually, and you'd better already have it in the product before you need it. Maybe you intend to eventually partner with a service, so you build an integration ahead of time. And then the partnership falls through, and you never need it. Many technical founders then fall prone to the sunk cost fallacy, thinking that since they already invested their time, the functionality needs to stay there.
Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14 by Scott Meyers
Universal references are rvalue references in contexts where type deduction distinguishes lvalues from rvalues and where reference collapsing occurs. Item 29: Assume that move operations are not present, not cheap, and not used. Move semantics is arguably the premier feature of C++11. “Moving containers is now as cheap as copying pointers!” you’re likely to hear, and “Copying temporary objects is now so efficient, coding to avoid it is tantamount to premature optimization!” Such sentiments are easy to understand. Move semantics is truly an important feature. It doesn’t just allow compilers to replace expensive copy operations with comparatively cheap moves, it actually requires that they do so (when the proper conditions are fulfilled). Take your C++98 code base, recompile with a C++11-conformant compiler and Standard Library, and—shazam!—your software runs faster.
Text Analytics With Python: A Practical Real-World Approach to Gaining Actionable Insights From Your Data by Dipanjan Sarkar
bioinformatics, business intelligence, computer vision, continuous integration, en.wikipedia.org, general-purpose programming language, Guido van Rossum, information retrieval, Internet of things, invention of the printing press, iterative process, natural language processing, out of africa, performance metric, premature optimization, recommendation engine, self-driving car, semantic web, sentiment analysis, speech recognition, statistical model, text mining, Turing test, web application
Principles like abstraction, encapsulation, inheritance, and polymorphism can also be implemented and exhibited using Python. There are several advanced features in Python, including iterators, generators, list comprehensions, lambda expressions, and several modules like itertools and functools, which provide the ability to write code following the functional programming paradigm. Python was designed keeping in mind the fact that simple and beautiful code is more elegant and easy to use rather than doing premature optimization and writing hard-to-interpret code. Python’s standard libraries are power-packed with a wide variety of capabilities and features ranging from low-level hardware interfacing to handling files and working with text data. Easy extensibility and integration was considered when developing Python such that it can be easily integrated with existing applications—rich application programming interfaces (APIs) can even be created to provide interfaces to other applications and tools.
Concepts, Techniques, and Models of Computer Programming by Peter Van-Roy, Seif Haridi
computer age, Debian, discrete time, Donald Knuth, Eratosthenes, fault tolerance, G4S, general-purpose programming language, George Santayana, John von Neumann, Lao Tzu, Menlo Park, natural language processing, NP-complete, Paul Graham, premature optimization, sorting algorithm, Therac-25, Turing complete, Turing machine, type inference
Then the program has to be rewritten to improve performance. Rewriting a program to improve some characteristic is called optimizing it, although it is never “optimal” in any mathematical sense. Usually, the program can easily be improved up to a point, after which diminishing returns set in and the program rapidly becomes more complex for ever smaller improvements. Optimization should therefore not be done unless necessary. Premature optimization is the bane of computing. Optimization has a good side and a bad side. The good side is that the overall execution time of most applications is largely determined by a very small part of the program text. Therefore performance optimization, if necessary, can almost always be done by rewriting just this small part (sometimes a few lines suﬃce). The bad side is that it is usually not obvious, even to experienced programmers, where this part is a priori.
. , see parameter passing pattern matching case statement, 6, 67 function (in Erlang), 388 Haskell, 309 receive expression (in Erlang), 391 reduction rule semantics, 784 PDA (procedural data abstraction), 420 pencil, xviii Pentium III processor, 201, 471 performance cluster computing, 711 competitive concurrency, 254 constraint programming, 758 Cray-1 supercomputer, 175 declarative programming, 313 dictionary, 201 distributed stream, 724 lazy language, 289, 342 measuring, 167 memoization, 25, 315 mobile object, 724 monitor, 597 Mozart Programming System, 201, 379 personal computer, 175 price of concurrency, 339 record ﬁeld access, 438 role of optimization, 177, 265, 302 role of parallelism, 237, 322 transitive closure, 471 word-of-mouth simulation, 486 permanent failure, 739 permutations, 2 persistence data structure, 149, 297 database, 654 Erlang, 387 transaction, 600 personal computer, 3, 252, 254, 289, 304 low-cost, 74, 175 pessimistic scheduling, 603 Phidani Software, 642 π calculus, xvii, 41, 54, 805 pipeline, 259 pixel, 556 placeholder dataﬂow variable, 86 future (in Multilisp), 336 GUI design, 686, 703 planning ﬂight, 671 WARPLAN, 621 Plotkin, Gordon, 779 point resting, 338 synchronization, 333 two-dimensional space, 554 pointer, 76 content edge, 733 888 Index dependency, 459 dynamic typing, 106 garbage collection, 76 memory block, 480 resource, 480 state, 733 POLA (Principle of Least Authority), 209 polymorphism, 18, 106, 425, 462, 493 active objects, 429 ad-hoc, 429 apportioning responsibility, 425 example, 530 Haskell, 312 object-oriented programming, 490 port objects, 429 stream objects, 429 universal, 429 Ponsard, Christophe, 545 port (explicit state), 349, 719, 848 communication from inside encapsulated search, 673 distributed semantics, 383 Port.sendRecv operation, 673 portal, 476 postcondition, 441, 521 potential function, 175 precondition, 441, 521 predicate calculus, 633 preemption, 252 preprocessor, 318 DCG (in Prolog), 649 design patterns, 536 extended DCG (in Prolog), 140 fallacy of, 318 presentation model (in GUI), 695 principle abstraction, 410 avoid changing interfaces, 458 avoid premature optimization, 177, 452 balance planning and refactoring, 452 centralized ﬁrst, distributed later, 745 class is ﬁnal by default, 492 compartmentalize responsibility, 425, 451 concentrate explicit state, 412 creative extension, xiv, 844 decisions at right level, 460 declarative concurrency, 242, 281 document component interfaces, 451 documented violations, 460 eager default, lazy declared, 330 encapsulate design decisions, 458 enriching control (in logic programming), 640 error conﬁnement, 90 “everything should be an object”, 542 exploit data abstraction uniformity, 543 form mirrors content, 544 freely exchange knowledge, 451 function structure follows type structure, 135 functional abstraction, 4 last call optimization, 72 layered language design, 850 least authority (POLA), 209 least expressiveness, 323 least privilege, 209 minimize dependencies, 387, 459 minimize indirections, 459 model independence, 457 more is not better or worse, just diﬀerent, xx Mozart design rules, xxvi natural selection, 451, 462 need to know, 209 objects over ADTs, 490 pay only on use, 620 predictable dependencies, 460 run time is all there is, 504, 690 separation of concerns, 567 stateful component with declara- Index 889 tive behavior, 417 substitution property, 518, 521, 523 syntax stability, 643 system decomposition, 210 type ﬁrst, 137 use data abstraction everywhere, 489, 543 working software keeps working, 59, 459, 722 private scope, 507, 508 C++ and Java sense, 508 Smalltalk and Oz sense, 507 probability exponential distribution, 475 Gaussian distribution, 476 normal distribution, 476 uniform distribution, 474 unique name generation, 207 problem cryptarithmetic, 755, 776 digital logic satisﬁability, 176 Flavius Josephus, 558–561 ﬂight planning, 671 grocery puzzle, 774 halting, 209, 681 Hamming, 293, 342 intractable, 176 library scheduler, 672 making change, 775 n-queens, 629 NP-complete, 176 palindrome product, 628, 757 Send-More-Money, 755, 776 undecidable, 209 zebra puzzle, 774 proc statement, 65, 792 procedure as component, 412 basic operations, 55 external reference, 65 importance, 54 order, 177 tail-recursive, 72 procedure value (closure), 65, 178, 792 anonymous, 53 common limitation, 179, 552 distributed lexical scoping, 722 encoding as an object, 540 higher-order programming, 177 relation to inner class, 552 process concurrent calculus, 54 concurrent program design, 364 CSP, 619 distributed system, 707 Erlang, 350, 386, 389 large program design, 450 operating system, 255 producer and consumer, 724 run-time error, 96 small program design, 218 processor, 237 cluster computing, 711 dataﬂow machine, 337, 469 parallel functional programming, 331 shared-memory multiprocessor, 710 producer, 257 proﬁling, 177, 452 program design, see software development program point, 444, 606 programming, xv, 1 accumulator, 139 component-based, 412 concurrent, 573 constraint, 44, 274, 577, 663 data-centered, 576 declarative, 29, 406 descriptive, 115 need for algorithms, 116 programmable, 115 Erlang, 388 ﬂow-based, 257 functional, 406 890 Index future developments, 461 good style, xxi Haskell, 309 higher-order, 113, 123, 177–194 introduction, 13 relation to object-oriented, 538 imperative, 29, 406 Java, 552, 615 kernel language approach, xvi logic, 44, 101, 142, 406, 632 multi-agent, 412, 576 multiparadigm, xiv, xxvi event manager, 566 nonalgorithmic, 622 object-based, 19, 538 object-oriented (OOP), 19, 413, 489 open, 105, 202 paradigm, xiii, xvi, 29, see computation model Prolog, 663 real-time, 304 relational, 621 stateful, 29 stateless, 29 synchronous, 266 programming model, xiii, 29 Prolog, 660–671 Aquarius, 140, 661 Parma, 661 SICStus, 190, 663 state threads package, 190 proof engineering, 117 proof rule, 444 propagate-and-search, 629, 750 propagator, 752, 760 property liveness, 602 object, 497 safety, 602 propositional logic, 632 protected scope, 508 C++ sense, 509 Java sense, 567 protection boundary, 202 protector, 325 protocol, 353 by-need, 282 communication, 715 consistency, 712 DHCP (Dynamic Host Connection Protocol), 207 distributed binding, 733 distributed uniﬁcation, 733 eager copy, 734 eager immediate copy, 734 interaction (in GUI), 682 invalidation, 733 IP (Internet Protocol), 206 lazy copy, 733 meta-object, 516 mobile state, 733 negotiation, 376 short-circuit, 559 stationary state, 733 TCP (Transmission Control Protocol), 712, 740 timer, 368 Prototyper tool, 689 pseudorandom numbers, 473 Psion Series 3 palmtop computer, 378 public scope, 507 pure object-oriented language, 543 QTk, 213, 680, 729 interactive use, 214, 684 Prototyper, 689 use in application, 225 quadratic equation, 179 quantiﬁer, 441, 445, 633, 645 existential (in Prolog), 671 quantum (in thread scheduling), 252 query database, 655 logic programming, 634 queue, 145 amortized ephemeral, 147 amortized persistent, 298 Index 891 breadth-ﬁrst traversal, 156 concurrent, 379, 583 nonblocking delete, 598 priority, 605, 614 worst-case ephemeral, 147 worst-case persistent, 299 race condition, 20, 234 raise statement, 93, 801 random number generation, 472 rational tree, 760 Raymond, Eric, 462 reachable memory, 74 ReadOnly operation, 799 real-time computing garbage collection, 76 hard, 174, 253, 254, 304 soft, 304 reasoning algebraic, 111, 116, 323 atomic action, 581 causal, 353, 575 lift control system, 375 logical, xix, 111, 632 message-passing concurrent model, 352 shared-shate concurrent model, 324 stateful model, 324, 440 receive asynchronous, 332 nonblocking, 333 synchronous, 332 receive expression (in Erlang), 391 recomputation, 761, 776 record, 19, 52, 825 adjoin, 827 basic operations, 54, 826 dynamic creation, 165, 549, 695 importance, 53 type, 438 usage trade-oﬀs, 438 recurrence equation, 167 recursion, 3, 113, 124 direct, 113 indirect, 113 mutual, 110 polymorphic, 309 programming with, 127 Prototyper tool, 690 tail recursion optimization, 72 red cut (in Prolog), 670 Red Hat Corporation, xxvi, 201, 471 reduction order, 330–332 applicative, 330 normal, 330 reduction rule, 784 reengineering, 522 refactoring, 452 reference, 714 referential transparency, 113 reﬂection, 515 region (in OPI), 815 register abstract machine, 56 forwarding, 621 memory management, 74 registration action procedures (in GUI), 683 display refresh (FlexClock), 700 distributed binding, 737 ﬁnalization, 481 relation, 655 relative error, 120 reliability, 711 rendezvous, 619 replicator, 326 research project, xxiv resolution deadlock, 605 logic programming, 635, 640, 662 SLDNF, 662 video display, 321 resource distributed component, 746 distributed system, 729 external, 77, 480 ﬁle descriptor, 293 892 Index localized, 709 producer/consumer pipeline, 261 use of laziness, 289 responsibility atomicity and consistency (in transaction), 600 compartmentalize (in a team), 451 coroutine (avoiding starvation), 275 design by contract, 521 distributed memory management, 738 dynamic typing, 493 failure conﬁnement, 245 memory management, 76 role of polymorphism, 425 type inference, 137 resting point, 338 restriction (environment), 62 retract/1 operation (in Prolog), 662 return (in for loop), 190 Reuter, Andreas, 582, 600 Reynolds, John C., 419 right, see name Rinard, Martin C., 338 RISC (Reduced Instruction Set Computer) microprocessor, 621 RMI (remote method invocation), 354, 709, 724, 725 root variable, 763 Round operation, 822 RPC (remote procedure call), 354, 709 rubber band, 251 runic inscription, 779 Runnable interface (in Java), 616 s-expression, 650 Sacks, Oliver, 405 safety, 602 Saint-Exupéry, Antoine de, 111 Santayana, George, 694 Saraswat, Vijay A., 338, 662, 808 scalability compilation, 458 multiprocessor, 710 program development, 105 weighted reference counting, 737 scalar product (constraint), 775 scheduler Delay operation, 304 deterministic, 253 lift control system, 366 nondeterministic, 253 randomness, 473 resource allocation, 672 round-robin, 252, 256 thread, 239, 252 transaction, 603 Schulte, Christian, xxvi science, xv, xviii scientiﬁc method, xvii scope, 56, 507 attribute, 510 dynamic, 59 lexical, 57, 59, 64, 508, 539 absence in Prolog, 661 distributed, 722 hiding, 221, 411, 423, 442, 483, 495, 549 substitution, 803 private, 507, 508 protected, 508 public, 507 static, see lexical user-deﬁned, 508 search aggregate, 670 all-solutions, 626 binary, 151 branch-and-bound, 772 breadth-ﬁrst, 644 communication from inside encapsulated search, 673 constraint programming, 274 contribution of AKL, 809 danger, 639 Index 893 database query, 657 depth-ﬁrst, 622, 644 deterministic, 621 encapsulated, 625 generate-and-test, 629, 758 iterative deepening, 644 linear, 197 logic programming, 661 n-queens problem, 629 one-solution, 626 overuse, xxi propagate-and-search, 629, 750 pruning, 662 relational computation model, 623 relational programming, 621 saturation, 772 search space, 622 search strategy, 761 search tree, 624 security abstract data type, 201–210 application, 744 atom vs. name, 508 capability, 208 data abstraction, 419–435 distributed resources, 731 distributed system, 743 engineering, 744 hardware, 744 human society, 208 implementation, 744 kernel language concepts, 847 language, 208, 744 linguistic abstraction, 39 mechanism, 208 open distribution, 711 policy, 208 right, 791, 847 static typing, 106 threat model, 744 self clone, 517 delegation, 511 dynamic binding, 505 forwarding, 511 Java, 553 this notation, 551 self (in Erlang), 390 semantic stack, 62 runnable, 62 suspended, 62 terminated, 62 semantics, 31 abstract machine, 56–78, 92–94, 239–241, 282–283, 348–349, 416–417 axiomatic, 38, 440–450, 632 by-need trigger, 282 cell, 416 common abstractions, 808 denotational, 38 exceptions, 92 interleaving, 780 kernel language, see abstract machine kernel language approach, 38 logical, 38, 631–641 monitor (in Java), 592 operational, 38, 60, 635, 779–811 port, 348, 383 secure types, 203 semantic statement, 61 SOS (structural operational semantics), 779 thread, 239 Send operation, 349 slot-reserving semantics, 384 send asynchronous, 332 latency, 263 nonblocking, 333 synchronous, 332 Send-More-Money problem, 755, 776 separation of concerns, 567 sequential logic, 269 serializability, 600 serialization, 709 894 Index serializer, 325 set comprehension, 301 setof/3 operation (in Prolog), 626, 666, 670 Shakespeare, William, 815 shared-state concurrency, see atomic action, see lock, see monitor, see transaction sharing, 418 Browser tool, 102, 829 distributed state, 720 distributed value, 716 thread, 378 short-circuit concurrent composition, 277 Flavius Josephus problem, 559 transitive closure, 464 Show operation, 340 side eﬀect, 411 declarative, 288 signal operation (in monitor), 592 signature (of procedure), 129 simulation components, 412 digital logic, 266–272 inadequacy of declarative model, 173 Internet, 412 multi-agent, 412 slow network, 578 small world, 486 word-of-mouth, 476 Simurgh, 707 single-assignment store, 42–49, 60, 781 importance, 43 singularity, 176 sink (consumer), 259 64-bit address, 78 64-bit word, 74, 175, 820 skip statement, 62, 785 SLDNF resolution, 662 small world graph, 461 simulation, 486 Smolka, Gert, xxvi snapshot (of state), 437, 718 software design, see design methodology, see language design software development, 218, 450 bottom-up, 451 compositional, 453 concurrent components, 362 distributed programming, 745 evolutionary, 451 extreme programming, 452 framework, 492 IID (Iterative and Incremental), 451 importance of names, 508 in the large, 450 in the small, 218 incremental, 451 interactive interface, 87 iterative, 451 middle-out, 451 stepwise reﬁnement, 465, 604 test-driven, 452 top-down, 8, 451 software engineering, 450 component as unit of deployment, 221 concurrency, 233 distributed lexical scoping, 722 further reading, 462 informatics curriculum, xxii lexical scoping, 59 software rot, 459 Solaris operating system, xxvi, xxix Solve operation, 626, 773 SolveAll operation, 626 SolveOne operation, 626 Sort operation, 670, 829 SOS (structural operational semantics), 779 source (producer), 259 source code, 221 interactive, 815 Index 895 million line, xvi, 36, 387, 457, 458 nonexistent, 492 preprocessor input, 318 reengineering, 522 set of functors, 285 textual scope, 64 variable name, 44 space, see computation space, see memory space leak, see memory leak speciﬁcation, 410 component, 461 speciﬁcation language, 116 speculative execution (in nonstrict language), 331 stack declarative object, 423 depth-ﬁrst traversal, 156 memory management, 74 open declarative, 195, 421 proving it correct, 442 secure declarative bundled, 423 secure declarative unbundled, 205, 422 secure stateful bundled, 424 secure stateful unbundled, 424 semantic, 61 stateful concurrent, 578 standalone application, 222 declare not allowed, 87 Java, 555 uncaught exception, 93 starvation, 275 wait set implementation, 597 state cell (mutable variable), 414 declarative, 408 explicit, 16, 409 implicit, 408 interaction with call by name, 485 lazy execution, 481 lazy language, 331 memory management, 77 modularity property, 315 nonstrict language, 331 port (communication channel), 347 reasoning with, 38, 440 revocable capability, 434 threading, 139 transformation, 133 state transition diagram, 353, 368 component design, 364 ﬂoor component, 369 lift component, 371 lift controller component, 369 transaction, 607 stateless (declarative programming), 111 statement case, 67, 790 catch (clause in try), 94 choice, 623, 772 conc, 278 declare, 2, 87 fail, 623 finally (clause in try), 94 for, 188 fun, 84 functor, 223 gate, 272 if, 66, 790 local, 56, 63, 786 lock, 22, 583 proc, 65, 792 raise, 93, 801 skip, 62, 785 thread, 241, 785 try, 92, 799 break, 486 compound, 117 compound (in Java), 552 declarative kernel language, 49 interactive, 87 procedure application, 66 sequential composition, 63, 785 suspendable, 65 896 Index value creation, 63 variable-variable binding, 63 static binding, 506 linking, 222 scope, see scope, lexical typing, 51, 104–106 stdin (standard input), 229, 553 stdout (standard output), 553 Steiner, Jennifer G., 334 Stirling’s formula for factorial, 618 storage manager, 325 store, 781 equivalence, 785 mutable (for cells), 416 mutable (for ports), 348 need, 780, 795 predicate, 781 read-only, 206, 798 single-assignment, 42–49, 60, 99, 235, 781 trigger, 282, 795 value, 43 stream, 795 deterministic, 257 Java, 553 merger, 395 producer/consumer, 257 usage trade-oﬀs, 439 strict . . . , see eager . . . strict two-phase locking, 604 strictness analysis, 289, 310, 342 string, 53, 830 virtual, 211, 831 StringToAtom operation, 824 structure compiler, 162 compositional, 461 diﬀerence, 141 distribution, 255 eﬀect of concurrency, 252 grammar, 32 hierarchical, 453 interpreter, 653 noncompositional, 461 program, 219, 220 structure equality, 103, 418, 723 substitution, 126, 803 substitution property, 518, 521, 523 subtype basic types, 52 class hierarchy, 518 Sun Microsystems, xxvi, 462 superclass, 503, 513, 556 supercomputer, 175 supply-driven execution, see eager execution suspension Delay operation, 305 due to program error, 48, 89 thread, 239, 276 Sussman, Gerald Jay, 42 Sussman, Julie, 42 Symbian Ltd., 378 symbolic link, 459 synchronization, 333–337 clock, 308 dataﬂow, 790 synchronized keyword, 593, 616 synchronous communication, 332 active object variant, 562 component interaction, 456 CSP, 619 dependency, 387 error reporting, 360 failure detection, 400, 739 fault conﬁnement, 745 receive, 332 send, 332 synchronous programming, 266 syntactic sugar, 40, 79–84 dynamic record creation, 165 local statement, 40 state transition diagram, 369 syntax, 31 convention for examples, xxix language, 31 nestable constructs (in Oz), 833 Index 897 nestable declarations (in Oz), 833 Oz language, 833 Oz lexical, 839 Prolog, 663 term (in Oz), 833 synthesized argument, 161 system exception, 96 Szyperski, Clemens, 462 tail call optimization, 72 Tanenbaum, Andrew S., 334 task (in concurrency), 780 tautology, 632 TCP (Transmission Control Protocol), 712, 740 technology, xv dangers of concurrency, 21 history of computing, 176 magic, 314 molecular computing, 176 Prolog implementation, 661 reengineering, 522 singularity, 176 software component, 462 synchronous digital, 267 transition to 64-bit, 78 Tel, Gerard, 353 tell operation, 782, 787 temporal logic, 603 temporary failure, 739 term Erlang, 391 Oz, 833 Prolog, 664 termination detection, 276, 382 ping-pong example, 305 failure in declarative program, 245 partial, 243, 338, 804 proof, 449 total, 804 test-driven development, 452 testing declarative programs, 111, 407 dynamic typing, 105 programming in the small, 219 stateful programs, 407 text ﬁle, 210 Thalys high-speed train, 382 theorem binomial, 4 Church-Rosser, 331 Gödel’s completeness, 634 Gödel’s incompleteness, 634 halting problem, 681 theorem prover, 117, 634, 662 Therac-25 scandal, 21 thinking machine, 621 third-party independence, 335 32-bit address, 78 32-bit word, 74, 174 this, see self Thompson, D’Arcy Wentworth, 405 thread, 846 declarative model, 233 hanging, 399 interactive interface, 89 introduction, 15 Java, 615 monotonicity property, 239, 781, 782 priority, 253 ready, 239 runnable, 239 suspended, 239 synchronization, 333 thread statement, 241, 785 Thread class (in Java), 616 throughput, 263 thunk, 432 ticket, 480, 714 Connection module, 715 ticking, 307 time complexity, 11 time slice, 252–254 duration, 254 898 Index time-lease mechanism, 480, 734, 738 time-out, 740 Erlang, 391–394 system design, 460 timer protocol, 368 timestamp, 207, 602 timing measurement active object, 379 memory consumption, 173 palindrome product (constraint version), 758 palindrome product (naive version), 629 transitive closure, 471 word frequency, 201 token equality, 418, 714, 723 token passing, 579, 588, 591, 721 token syntax (of Oz), 833 tokenizer, 32, 162 top-down software development, 8, 451 total termination, 804 trade-oﬀ asynchronous communication vs. fault conﬁnement, 745 compilation time vs. execution eﬃciency, 457 compositional vs. noncompositional design, 461 dynamic vs. static scoping, 58 dynamic vs. static typing, 104 explicit state vs. implicit state, 315, 409 expressiveness vs. execution eﬃciency, 116 expressiveness vs. manipulability, 681 functional decomposition vs. type decomposition, 542 helper procedure placement, 120 indexed collections, 435 inheritance vs. component composition, 462, 492 kernel language design, 844 language design, 811 lazy vs. eager execution, 329 memory use vs. execution speed, 177 names vs. atoms, 510 nonstrictness vs. explicit state, 331, 344 objects vs.
The Personal MBA: A World-Class Business Education in a Single Volume by Josh Kaufman
Albert Einstein, Atul Gawande, Black Swan, business cycle, business process, buy low sell high, capital asset pricing model, Checklist Manifesto, cognitive bias, correlation does not imply causation, Credit Default Swap, Daniel Kahneman / Amos Tversky, David Heinemeier Hansson, David Ricardo: comparative advantage, Dean Kamen, delayed gratification, discounted cash flows, Donald Knuth, double entry bookkeeping, Douglas Hofstadter, en.wikipedia.org, Frederick Winslow Taylor, George Santayana, Gödel, Escher, Bach, high net worth, hindsight bias, index card, inventory management, iterative process, job satisfaction, Johann Wolfgang von Goethe, Kevin Kelly, Kickstarter, Lao Tzu, lateral thinking, loose coupling, loss aversion, Marc Andreessen, market bubble, Network effects, Parkinson's law, Paul Buchheit, Paul Graham, place-making, premature optimization, Ralph Waldo Emerson, rent control, side project, statistical model, stealth mode startup, Steve Jobs, Steve Wozniak, subscription business, telemarketer, the scientific method, time value of money, Toyota Production System, tulip mania, Upton Sinclair, Vilfredo Pareto, Walter Mischel, Y Combinator, Yogi Berra
The purpose of understanding and analyzing systems is to improve them, which is often tricky—changing systems can often create unintended consequences. In this chapter, you’ll learn the secrets of Optimization, how to remove unnecessary Friction from critical processes, and how to build Systems that can handle Uncertainty and Change. SHARE THIS CONCEPT: http://book.personalmba.com/improving-systems/ Optimization Premature optimization is the root of all evil. —DONALD KNUTH, COMPUTER SCIENTIST AND FORMER PROFESSOR AT STANFORD UNIVERSITY Optimization is the process of maximizing the output of a System or minimizing a specific input the system requires to operate. Optimization typically revolves around the systems and processes behind your Key Performance Indicators , which measure the critical elements of the system as a whole.
always be closing, domain-specific language, Donald Knuth, en.wikipedia.org, Firefox, hypertext link, job satisfaction, MITM: man-in-the-middle, premature optimization, slashdot, web application, WebSocket
ZeroMQ by Pieter Hintjens
AGPL, anti-pattern, carbon footprint, cloud computing, Debian, distributed revision control, domain-specific language, factory automation, fault tolerance, fear of failure, finite state, Internet of things, iterative process, premature optimization, profit motive, pull request, revision control, RFC: Request For Comment, Richard Stallman, Skype, smart transportation, software patent, Steve Jobs, Valgrind, WebSocket
The goal of MOPED is to define a process by which we can take a rough use case for a new distributed application, and go from “Hello World” to fully working prototype in any language in under a week. Using MOPED, you grow, more than build, a working ØMQ architecture from the ground up with minimal risk of failure. By focusing on the contracts rather than the implementations, you avoid the risk of premature optimization. By driving the design process through ultra-short test-based cycles, you can be more certain that what you have works before you add more. We can turn this into five real steps: Internalize the ØMQ semantics. Draw a rough architecture. Decide on the contracts. Make a minimal end-to-end solution. Solve one problem and repeat. Step 1: Internalize the Semantics You must learn and digest ØMQ’s “language,” that is, the socket patterns and how they work.
The C++ Programming Language by Bjarne Stroustrup
combinatorial explosion, conceptual framework, database schema, distributed generation, Donald Knuth, fault tolerance, general-purpose programming language, index card, iterative process, job-hopping, locality of reference, Menlo Park, Parkinson's law, premature optimization, sorting algorithm
All rights reserved. 107 ________________________________________ ________________________________________________________________________________________________________________________________________________________________ 6 ________________________________________ ________________________________________________________________________________________________________________________________________________________________ Expressions and Statements Premature optimization is the root of all evil. – D. Knuth On the other hand, we cannot ignore efficiency. – Jon Bentley Desk calculator example — input — command line arguments — expression summary — logical and relational operators — increment and decrement — free store — explicit type conversion — statement summary — declarations — selection statements — declarations in conditions — iteration statements — the infamous ggoottoo — comments and indentation — advice — exercises. 6.1 A Desk Calculator [expr.calculator] Statements and expressions are introduced by presenting a desk calculator program that provides the four standard arithmetic operations as infix operators on floating-point numbers.
If a ‘‘maintenance crew’’ is left guessing about the architecture of the system or must deduce the purpose of system components from their implementation, the structure of a system can deteriorate rapidly under the impact of local patches. Documentation is typically much better at conveying details than in helping new people to understand key ideas and principles. 23.4.7 Efficiency [design.efficiency] Donald Knuth observed that ‘‘premature optimization is the root of all evil.’’ Some people have learned that lesson all too well and consider all concern for efficiency evil. On the contrary, efficiency must be kept in mind throughout the design and implementation effort. However, that does not mean the designer should be concerned with micro-efficiencies, but that first-order efficiency issues must be considered. The best strategy for efficiency is to produce a clean and simple design.
Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty in Software Design by Diomidis Spinellis, Georgios Gousios
Albert Einstein, barriers to entry, business intelligence, business process, call centre, continuous integration, corporate governance, database schema, Debian, domain-specific language, don't repeat yourself, Donald Knuth, en.wikipedia.org, fault tolerance, Firefox, general-purpose programming language, iterative process, linked data, locality of reference, loose coupling, meta analysis, meta-analysis, MVC pattern, peer-to-peer, premature optimization, recommendation engine, Richard Stallman, Ruby on Rails, semantic web, smart cities, social graph, social web, SPARQL, Steve Jobs, Stewart Brand, traveling salesman, Turing complete, type inference, web application, zero-coupon bond
An interpreter for a smaller set will be smaller in code and footprint, and therefore will execute each of its operations much faster, but conversely it has a larger set to execute. So we are looking for a reasonable balance of set size against code length in order to get a near-optimal performance out of the interpreter. In finding the optimal point for both of these trade-offs, it is important to keep Hoare’s Dictum in the back of your mind: Premature optimization is the root of all evil. —C. A. R. Hoare The precise sweet spot for lots of these optimizations will be system-dependent. In a Java environment, the system includes not only the physical hardware but also the JVM. With the added factor that the Java component of the environment is invariably just-in-time compiled, small scoped performance benchmarks are notoriously unreliable. To this end we refrained from overusing such benchmarks to guide our coding choices, and instead relied on first principles and trusted benchmarks only when large shifts in performance occurred.
The Architecture of Open Source Applications by Amy Brown, Greg Wilson
8-hour work day, anti-pattern, bioinformatics, c2.com, cloud computing, collaborative editing, combinatorial explosion, computer vision, continuous integration, create, read, update, delete, David Heinemeier Hansson, Debian, domain-specific language, Donald Knuth, en.wikipedia.org, fault tolerance, finite state, Firefox, friendly fire, Guido van Rossum, linked data, load shedding, locality of reference, loose coupling, Mars Rover, MITM: man-in-the-middle, MVC pattern, peer-to-peer, Perl 6, premature optimization, recommendation engine, revision control, Ruby on Rails, side project, Skype, slashdot, social web, speech recognition, the scientific method, The Wisdom of Crowds, web application, WebSocket
Design Reflections My experience in working on Graphite has reaffirmed a belief of mine that scalability has very little to do with low-level performance but instead is a product of overall design. I have run into many bottlenecks along the way but each time I look for improvements in design rather than speed-ups in performance. I have been asked many times why I wrote Graphite in Python rather than Java or C++, and my response is always that I have yet to come across a true need for the performance that another language could offer. In [Knu74], Donald Knuth famously said that premature optimization is the root of all evil. As long as we assume that our code will continue to evolve in non-trivial ways then all optimization6 is in some sense premature. One of Graphite's greatest strengths and greatest weaknesses is the fact that very little of it was actually "designed" in the traditional sense. By and large Graphite evolved gradually, hurdle by hurdle, as problems arose. Many times the hurdles were foreseeable and various pre-emptive solutions seemed natural.
Pro AngularJS by Adam Freeman
business process, create, read, update, delete, en.wikipedia.org, Google Chrome, information retrieval, inventory management, MVC pattern, place-making, premature optimization, revision control, Ruby on Rails, single page application, web application
Finally, I would have used the $animate service, which I describe in Chapter 23, to display short, focused animations to ease the transition from one view to another when the URL path changes. 186 Chapter 8 ■ SportsStore: Orders and Administration AVOIDING OPTIMIZATION PITFALLS You will notice that I say that I could consider reusing the category and pagination data, not that I would definitely do so. That’s because any kind of optimization should be carefully assessed to ensure it is sensible and that it avoids two main pitfalls that dog optimization efforts. The first pitfall is premature optimization, which is where a developer sees an opportunity to optimize an operation or task before the current implementation causes any problems or breaks a contract in the nonfunctional specification. This kind of optimization tends to make code more specific in its nature that it would otherwise be, and that can kill the easy movement of functionality from one component to another that is typical of AngularJS (and is one of the most enjoyable aspects of AngularJS development).
Clojure Programming by Chas Emerick, Brian Carper, Christophe Grand
Amazon Web Services, Benoit Mandelbrot, cloud computing, continuous integration, database schema, domain-specific language, don't repeat yourself, en.wikipedia.org, failed state, finite state, Firefox, game design, general-purpose programming language, Guido van Rossum, Larry Wall, mandelbrot fractal, Paul Graham, platform as a service, premature optimization, random walk, Ruby on Rails, Schrödinger's Cat, semantic web, software as a service, sorting algorithm, Turing complete, type inference, web application
That’s an optimization and should only be taken on when absolutely necessary, especially given the costs associated with it: efficient field access ties code that uses it to a particular type, which often complicates the implementation of generic functionality and limits composability. * * *  The canonical and up-to-date version of this flowchart is maintained at https://github.com/cemerick/clojure-type-selection-flowchart along with a number of translations, including Dutch, German, Japanese, Portuguese, and Spanish so far.  Recall that “premature optimization is the root of all evil.” Thank you, Professor Knuth. Chapter 19. Introducing Clojure into Your Workplace (or, Sneaking Clojure Past the Boss) It is a sad fact that many programmers, if not the majority, use languages and tools every day that they begrudge. Either through historical accident, organizational inertia, or hard facts of the business, we often find ourselves stuck wishing we were using something, anything else to get our jobs done.
Tools of Titans: The Tactics, Routines, and Habits of Billionaires, Icons, and World-Class Performers by Timothy Ferriss
Airbnb, Alexander Shulgin, artificial general intelligence, asset allocation, Atul Gawande, augmented reality, back-to-the-land, Ben Horowitz, Bernie Madoff, Bertrand Russell: In Praise of Idleness, Black Swan, blue-collar work, Boris Johnson, Buckminster Fuller, business process, Cal Newport, call centre, Charles Lindbergh, Checklist Manifesto, cognitive bias, cognitive dissonance, Colonization of Mars, Columbine, commoditize, correlation does not imply causation, David Brooks, David Graeber, diversification, diversified portfolio, Donald Trump, effective altruism, Elon Musk, fault tolerance, fear of failure, Firefox, follow your passion, future of work, Google X / Alphabet X, Howard Zinn, Hugh Fearnley-Whittingstall, Jeff Bezos, job satisfaction, Johann Wolfgang von Goethe, John Markoff, Kevin Kelly, Kickstarter, Lao Tzu, lateral thinking, life extension, lifelogging, Mahatma Gandhi, Marc Andreessen, Mark Zuckerberg, Mason jar, Menlo Park, Mikhail Gorbachev, MITM: man-in-the-middle, Nelson Mandela, Nicholas Carr, optical character recognition, PageRank, passive income, pattern recognition, Paul Graham, peer-to-peer, Peter H. Diamandis: Planetary Resources, Peter Singer: altruism, Peter Thiel, phenotype, PIHKAL and TIHKAL, post scarcity, post-work, premature optimization, QWERTY keyboard, Ralph Waldo Emerson, Ray Kurzweil, recommendation engine, rent-seeking, Richard Feynman, risk tolerance, Ronald Reagan, selection bias, sharing economy, side project, Silicon Valley, skunkworks, Skype, Snapchat, social graph, software as a service, software is eating the world, stem cell, Stephen Hawking, Steve Jobs, Stewart Brand, superintelligent machines, Tesla Model S, The Wisdom of Crowds, Thomas L Friedman, Wall-E, Washington Consensus, Whole Earth Catalog, Y Combinator, zero-sum game
for each, brainstorming the ramifications. Can You Flip the Deferred-Life Plan and Make It Work? “Many, many people are working very hard, trying to save their money to retire so they can travel. Well, I decided to flip it around and travel when I was really young, when I had zero money. And I had experiences that, basically, even a billion dollars couldn’t have bought.” “You Don’t Want ‘Premature Optimization’” “I really recommend slack. ‘Productive’ is for your middle ages. When you’re young, you want to be prolific and make and do things, but you don’t want to measure them in terms of productivity. You want to measure them in terms of extreme performance, you want to measure them in extreme satisfaction.” The Ideas You Can’t Give Away or Kill . . . “I became a proponent of trying to give things away first.
Solr in Action by Trey Grainger, Timothy Potter
business intelligence, cloud computing, commoditize, conceptual framework, crowdsourcing, data acquisition, en.wikipedia.org, failed state, fault tolerance, finite state, full text search, glass ceiling, information retrieval, natural language processing, openstreetmap, performance metric, premature optimization, recommendation engine, web application
Technically an index-time boost is distributed (multiplied) into each term’s relevancy, which is somewhat different than using a function query against a popularity field, which is added to the overall score. Although it’s possible to construct your function queries in such a way as to mimic the index-time boost, in practice the additive boost will likely accomplish your desired outcome, so too much focus on this detail is likely a premature optimization until you discover a problem with this approach. Both the index-time document boost and the boosting of a document by a function on a popularity field are focused upon globally boosting a document’s relevancy versus all other documents. This might make sense for an e-commerce application in which certain products tend to sell better overall or for a news website where certain popular articles are trending.
The Singularity Is Near: When Humans Transcend Biology by Ray Kurzweil
additive manufacturing, AI winter, Alan Turing: On Computable Numbers, with an Application to the Entscheidungsproblem, Albert Einstein, anthropic principle, Any sufficiently advanced technology is indistinguishable from magic, artificial general intelligence, Asilomar, augmented reality, autonomous vehicles, Benoit Mandelbrot, Bill Joy: nanobots, bioinformatics, brain emulation, Brewster Kahle, Brownian motion, business cycle, business intelligence, c2.com, call centre, carbon-based life, cellular automata, Claude Shannon: information theory, complexity theory, conceptual framework, Conway's Game of Life, coronavirus, cosmological constant, cosmological principle, cuban missile crisis, data acquisition, Dava Sobel, David Brooks, Dean Kamen, disintermediation, double helix, Douglas Hofstadter, en.wikipedia.org, epigenetics, factory automation, friendly AI, George Gilder, Gödel, Escher, Bach, informal economy, information retrieval, invention of the telephone, invention of the telescope, invention of writing, iterative process, Jaron Lanier, Jeff Bezos, job automation, job satisfaction, John von Neumann, Kevin Kelly, Law of Accelerating Returns, life extension, lifelogging, linked data, Loebner Prize, Louis Pasteur, mandelbrot fractal, Marshall McLuhan, Mikhail Gorbachev, Mitch Kapor, mouse model, Murray Gell-Mann, mutually assured destruction, natural language processing, Network effects, new economy, Norbert Wiener, oil shale / tar sands, optical character recognition, pattern recognition, phenotype, premature optimization, randomized controlled trial, Ray Kurzweil, remote working, reversible computing, Richard Feynman, Robert Metcalfe, Rodney Brooks, scientific worldview, Search for Extraterrestrial Intelligence, selection bias, semantic web, Silicon Valley, Singularitarianism, speech recognition, statistical model, stem cell, Stephen Hawking, Stewart Brand, strong AI, superintelligent machines, technological singularity, Ted Kaczynski, telepresence, The Coming Technological Singularity, Thomas Bayes, transaction costs, Turing machine, Turing test, Vernor Vinge, Y2K, Yogi Berra
We saw this in the railroad frenzy of the nineteenth century, which was followed by widespread bankruptcies. (I have some of these early unpaid railroad bonds in my collection of historical documents.) And we are still feeling the effects of the e-commerce and telecommunications busts of several years ago, which helped fuel a recession from which we are now recovering. AI experienced a similar premature optimism in the wake of programs such as the 1957 General Problem Solver created by Allen Newell, J. C. Shaw, and Herbert Simon, which was able to find proofs for theorems that had stumped mathematicians such as Bertrand Russell, and early programs from the MIT Artificial Intelligence Laboratory, which could answer SAT questions (such as analogies and story problems) at the level of college students.163 A rash of AI companies occurred in the 1970s, but when profits did not materialize there was an AI "bust" in the 1980s, which has become known as the "AI winter."
EuroTragedy: A Drama in Nine Acts by Ashoka Mody
"Robert Solow", Andrei Shleifer, asset-backed security, availability heuristic, bank run, banking crisis, Basel III, Berlin Wall, book scanning, Bretton Woods, call centre, capital controls, Carmen Reinhart, Celtic Tiger, central bank independence, centre right, credit crunch, Daniel Kahneman / Amos Tversky, debt deflation, Donald Trump, eurozone crisis, Fall of the Berlin Wall, financial intermediation, floating exchange rates, forward guidance, George Akerlof, German hyperinflation, global supply chain, global value chain, hiring and firing, Home mortgage interest deduction, income inequality, inflation targeting, Irish property bubble, Isaac Newton, job automation, Johann Wolfgang von Goethe, Johannes Kepler, Kenneth Rogoff, Kickstarter, liberal capitalism, light touch regulation, liquidity trap, loadsamoney, London Interbank Offered Rate, Long Term Capital Management, low-wage service sector, Mikhail Gorbachev, mittelstand, money market fund, moral hazard, mortgage tax deduction, neoliberal agenda, offshore financial centre, oil shock, open borders, pension reform, premature optimization, price stability, purchasing power parity, quantitative easing, rent-seeking, Republic of Letters, Robert Gordon, Robert Shiller, Robert Shiller, short selling, Silicon Valley, The Great Moderation, The Rise and Fall of American Growth, too big to fail, total factor productivity, trade liberalization, transaction costs, urban renewal, working-age population, Yogi Berra
And the gains from mean reversion were blunted, in part, by hysteresis effects, the legacy of diminished skills and low investment due to extended underperformance during the long crisis.12 The recovery, therefore, was disappointing by historical standards. But it had been so long in coming and growth expectations had been set so low that it was easy for officials and commentators to hail the recovery as a significant step forward. The dangers of premature optimism were once again great, as was made clear with the unhelpful reaction of financial markets to comments by ECB President Mario Draghi. In June 2017, at the ECB’s annual conclave of central bankers in Sintra on the Portuguese Riviera, Draghi said, “All the signs now point to a strengthening and broadening recovery in the euro area.” And even though inflation was still stuck at undesirably low levels, Draghi insisted, “Deflationary forces have been replaced by reflationary ones.”