Book Summary

What Books,... Did I Rereading, Start or Finish Reading This Year (2022)? Update September.2022

Books

  • How to take smart Notes (September 2022)

  • Introduction 4, The four underlying principles 4, the six steps to successful writing 6, afterword

  • introduction

    • write everything/ collect notes not related to any thing, organize notes, revirew, rewrite,

      • no reorganise no complex system, develop ideas by smart notes

      • 1 slip-box; 2 repeatable tasks that can become automatic and fit together seamlessly change routinges

      • overarching workflow "Getting Things Done" GTD

      • constantly have to ump back and forth between different tasks

      • 1- bibliographical slip-box: reference

      • 2- collected and generated ideas slip-box

      • 3- index: notes serve as entry point / thought/ topic

      • writing a paper step by step

        • 1 fleeting notes: it will delete within a day

          • I always have a slip of paper at hand, on which I note down the ideas of certain pages. on the backside I write down the bibliographic details. after finishing the book I go throught my notes and think how ehse notes might be relevant for already written notes in the slip-box. it means that I always read with an eye towards possible connections in the slip-box

        • 2 literature notes: contain the necessary information - in reference system or in the slip-box

          • I make a note with the bibliographic details. on the backside I would write "on page x is this, on page y is that" and then it goes into the bibliographic slib-box where I collect everything I read

          • read, think about its relevance

          • theoretical background, methodological approach or perspective of the text we read.

          • whether something adds to a discussion in the slip-box

          • we look at our slip-box for already existing lines of thought and think about the questions and problems already on our minds to which a new note might contribute. - assigning keywords is much more than just a bureaucratic act. it is a crucial part of the thinking process, which often leads to a deeper elaboration of the note itself and the connection to other notes.


        • 3 permanent notes: develop ideas/new/ - only relevant to one particular project - in project specific folder - can be discarded or archived after project finished

          • add to slip-box behind the note you dirctyly refer to or behind the last note in the slip-box

          • add links to other notes or links on other notes to your new note

          • make sure it can be found from the index (MOC) add an entry in the index if necessary or refer to it from a note that is connected to the index

          • build a latticework of mental models

        • 4 behind multiple notes (link backward) - link to related note - link to MOC

          • make sure it can be found again

          • keywords can easily be added to a note like tags and will then show up in the index



    • a day

      • read and take notes

      • build connections within the slip-box - new idea

      • you write on your paper, notice a hole in the argument and have another look in the file system for the missing link. you follow up on a footnote, go back to research and might add a fitting quote to one of your papers in the making.

  • The four underlying principles

    • writing

    • simplicity

    • not from scratch

    • let the work carry you forward

  • the six steps to successful writing

    • separate and interlocking tasks

      • we use memo techniques is to bundle items together in a meaningful way and remember the bundles

      • the brain doesn't distinguish between an actual finished task and one that is postponed by taking a note

      • the fist step is to break down the amprphous task of "writing" into smaller pieces of different tasks that can be finished in one go. the second step is to make sure we always write down the outcome of our thinking, including possible connections to further inquiries.

      • ego depletion

    • read for understanding

    • take smart notes

    • develp ideas (MOC)

      • 1 overview of a topic - referred to from the index and used as an entry point into a topic has already develped

      • 2 keeping tarck of all topic - index -

    • share your insight

    • make it a habit

  • afterword


  • 112

  • Writing Solid Code (September 2022)

Writing Solid Code (Microsoft Programming Series) by Trendelles Store

Note from Writing Solid Code Book

https://www.tiziran.com/describe/book-summary

#SolidCode #C++ #Python #tiziran


  • Chapter 1

  • Chapter 2

    • introduction assert page 16; assert.h

    • assert is nothing more than a repackaged form of the #ifdef code we saw before, but when you use

    • the macro, it takes one line instead of seven

    • That's why assert is a macro and not a function; if it were a function, calling

    • it could cause unexpected memory or code swapping.

    • Use assertions to validate function arguments .

    • Strip undefined behavior from your code, or use assertions to catch illegal uses of undefined behavior .

    • Don't waste people's time. Document unclear assertions .

    • Either remove implicit assumptions, or assert that they are valid .

    • Use assertions to detect impossible conditions.

    • Don't hide bugs when you program defensively.

    • Use a second algorithm to validate your results.

    • Don't wait for bugs to happen; use startup checks.

  • Chapter 3

    • Maintain shipping and debugging versions of your program. Shrink-wrap the shipping version, but use the debugging ver­sion as much as possible to catch bugs quickly.

    • Assertions are a shorthand way to write debugging checks. Use them to catch illegal conditions that should never arise. Don't confuse such conditions with error conditions, which you must handle in the final product.

    • Use assertions to validate function arguments and to alert pro­ grammars when they do something undefined. The more rigidly you define your functions, the easier it will be to validate the arguments.

    • Once you've written a function, review it and ask yourself, 'What am I assuming?" If you find an assumption, either assert that your assumption is always valid, or rewrite the code to re­ move the assumption. Also ask, 'What is most likely to be wrong in this code, and how can I automatically detect the prob­lem?" Strive to implement tests that catch bugs at the earliest possible moment. Textbooks encourage programmers to program defensively, but remember that this coding style hides bugs. When you write de­fensive code, use assertions to alert you if the "can't happen" cases do happen.

    • Eliminate random behavior. Force bugs to be reproducible .

    • Destroy your garbage so that it's not misused .

    • Not only did reallocate have to move the block of memory as it was expanding it, but the old memory had to be reallocated and filled with new data. In the assembler, both happened rarely.

    • This brings up another guideline for writing bug-free code: You don't want anything to happen rarely. You need to isolate those behaviors in your subsystems that may happen and make sure that they do happen. And of­ ten. If you find rare behavior in your subsystems, be sure to do something­ anything-to stir things up.

    • The assembler bug could have been found within hours, instead of years, if reallocate hadn't so rarely moved blocks when it expanded them.

    • If something happens rarely, force it to happen often.

    • Keep debug information to allow stronger error checking.

    • There is no question that the debug code will create differences be­ tween the ship and the debug versions of your code, but as long as you're careful not to change the underlying behavior of the code, those differences shouldn't matter.

    • Create thorough subsystem checks, and use them often.

    • Design your tests carefully. Nothing should be arbitrary.

    • Strive to implement transparent integrity checks.

    • Don't apply ship version constraints to the debug version. Trade size and speed for error detection.

  • Chapter 4

    • Don't wait until you have a bug to step through your code.

    • Step through every code path.

    • What About Sweeping Changes? In the past, programmers have asked, "What if I add a feature that touches code in many places? Stepping through all that new code is going to be time consuming." Let me answer that question with another: Can you make such sweeping changes without introducing any bugs? The habit of stepping through your code creates an interesting negative feedback loop. Programmers who step through their code soon learn to write small, easily testable functions because stepping through large func­tions is so painful. Programmers also spend more time thinking about how they can localize the changes they need to make-again, so that they can more easily test their code. And isn't this exactly what you want? No project lead likes it when programmers touch a lot of code; it's too destabilizing. Nor do leads like large, unmanageable functions; they're often unmaintainable. Try hard to localize your changes. If you find that you must make per­vasive changes, think twice before you decide not to step through all the new code.

    • Overflow and underflow bugs

    • Data conversion bugs

    • Off-by-one bugs

    • NULL pointer bugs

    • Bugs using garbage memory (0xA3 bugs)

    • Assignment bugs in which you've used = instead of ==

    • Precedence bugs

    • Logic bugs

    • As you step through code, focus on data flow. Source level debuggers can hide execution details. Step through critical code at the instruction level .

  • Chapter 5

    • Make it hard to ignore error conditions. Don't bury error codes in return values.

    • Always look for, and eliminate, flaws in your interfaces.

    • Don't write multipurpose functions. Write separate functions to allow stronger argument validation.

    • Don't be wishy-washy. Define explicit function arguments.

    • Write functions that, given valid inputs, cannot fail.

    • Make the code intelligible at the point of call. Avoid Boolean arguments.

    • Write comments that emphasize potential hazards.

  • Chapter 6

    • Use well-defined data types.

    • Always ask ,"Can this variable or expression over- or underflow?"

    • Implement your designs as accurately as possible. Being kind a close is being kind a buggy.

    • these principles already: Don't accept special purpose arguments such as the NULL pointer, and Implement your design, not something that approximates it. The third principle is new: Strive to make every function perform its task exactly one time.

    • Implement "the task" just once.

    • Get rid of extraneous if statements.

    • Avoid using nested ?: operators .

    • Handle your special cases just once.

    • Avoid risky language idioms.

    • Don't needlessly mix operator types. If you must mix operators, use parentheses to isolate the operations.

    • Avoid calling functions that return errors.

  • Chapter 7

    • Don't reference memory that you don't own.

    • Don't reference memory that you have freed.




181


  • To sum up

    • Charles Simonyi in the early 1970s. https://en.wikipedia.org/wiki/Hungarian_notation

    • char ch;

    • byte b;

    • flag f;/* flags that are always TRUE or FALSE*/

    • symbol sym;/* some sort of symbol structure*/

    • char byte flag symbol

    • *pch:/* character pointer*/

    • *pb;

    • *pf:

    • *psym:







    • Shape Up: Stop Running in Circles and Ship Work that Matters (February 2021) 176 pages

    • Six-week cycles: Our decisions are based on moving the product forward in the next six weeks, not micromanaging time. We don’t count hours or question how individual days are spent. We don’t have daily meetings. We don’t rethink our roadmap every two weeks. Our focus is at a higher level. We say to ourselves: “If this project ships after six weeks, we’ll be really happy. We’ll feel our time was well spent.” Then we commit the six weeks and leave the team alone to get it done

    • Shaping the work: key elements of a solution, appetite

  • part one shaping:

    • two separate tracks: one for shaping, one for building.

    • Steps to shaping

    • 1. Set boundaries.

    • 2. Rough out the elements: idea that solves the problem within the appetite but without all the fine details worked out

    • 3. Address risks and rabbit holes.

    • 4. Write the pitch.

    • fixed time, variable scope,

    • Where in the current system does the new thing fit? How do you get to it? What are the key components or interactions? Where does it take you?

    • five ingredients that we always want to include in a pitch: 1. Problem — The raw idea, a use case, or something we’ve seen that motivates us to work on this 2. Appetite — How much time we want to spend and how that constrains the solution 3. Solution — The core elements we came up with, presented in a form that’s easy for people to immediately understand 4. Rabbit holes — Details about the solution worth calling out to avoid problems 5. No-gos — Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the appetite or make the problem tractable

  • part two : Betting

    • Some companies use two-week cycles (aka “sprints”). We learned that two weeks is too short to get anything meaningful done. Worse than that, two-week cycles are extremely costly due to the planning overhead. The amount of work you get out of two weeks isn’t worth the collective hours around the table to “sprint plan” or the opportunity cost of breaking everyone’s momentum to re-group.

    • after each six-week cycle, we schedule two weeks for cool-down.

    • bugs: Use cool-down. Bring it to the betting table. Schedule a bug smash.

    • We’ve noticed three phases of work when we build a new product from scratch. R&D mode (bet the time on spiking some key pieces of the new product idea. CEO and designer, we don’t expect to ship anything at the end of an R&D cycle) , Production mode (Shaping is deliberate again. bet multiple teams in parallel , Shipping is the goal) , Cleanup mode (There’s no shaping. There aren’t clear team boundaries. Work is “shipped”) [Cleanup shouldn’t last longer than two cycles]

    • Example: two years of development, R&D mode for the first year, a year of production mode cycles followed, two cycles of cleanup and significantly cut back the feature set, some overlap between R&D and production mode after that first year,

  • Part three: Building

    • We don’t start by assigning tasks to anyone.

    • we define and track the scopes as to-do lists. Each scope corresponds to a list name. Then any tasks for that scope go in that list.

    • image 1, 2, 3,

    • Mark nice-to-haves with ~

    • First there’s the uphill phase of figuring out what our approach is and what we’re going to do. Then, once we can see all the work involved, there’s the downhill phase of execution

  • image 4, 5,

  • Disciplined entrepreneurship 24 steps to a successful startup by Bill Aulet (January 2021) 290 pages

    • getting start: idea, technology, passion; What can I do well that I would love to do for an extended period of time? P: 19, 21

    • 1 market segmentation: The single necessary and sufficient condition for a business is a paying customer. ; technological enthusiasts=early adopters=early majority ; P: 31,

    • 2 select a beachhead market: P: 44,

    • 3 build an end user profile: P: 52,

    • 4 Calculate the Total Addressable Market (TAM) Size for the Beachhead Market; $200 <TAM < $100 million per year;

    • 5 The process of developing a Persona provides specific details about the primary customer within your beachhead market.

    • 6 Creating a visual representation of the full life cycle of your product enables you to see how the product will fit into the customer’s value chain and what barriers to adoption might arise. P: 86,

    • 7 High-Level Product Specification;

    • 8 Quantify the Value Proposition:

    • 9 Identify Your Next 10 Customers: P: 115,

    • 10 Define Your Core: First-mover advantage can help a company with a well-defined Core, but it cannot win the market by simply by being first; this must be translated into something else like locking in key customers, achieving positive networking effects for your company, recruiting the best talent in a certain area, and so on. ;

    • 11 Chart Your Competitive Position: The goal is to show that your Competitive Position both leverages your Core and that your product satisfies your Persona’s priorities far better than existing or logical future products. ; P:134,

    • 12 Determine the Customer’s Decision-Making Unit (DMU):

    • 13 Map the Process to Acquire a Paying Customer: Okta; P:151, 152,

    • 14 Calculate the Total Addressable Market Size for Follow-on Markets: If you want to attract venture capital and/or build a big business, the general rule is that the broader TAM (for 10 or less follow-on markets), plus your beachhead market TAM, should add up to over $1B. ;

    • *15 Design a Business Model: A business model is a framework by which you extract from your customers some portion of the value your product creates for them. ; GENERALIZED CATEGORIES OF BUSINESS MODELS= P: 167-171; two key entrepreneurship variables: the Lifetime Value of an Acquired Customer (LTV) and Cost of Customer Acquisition (COCA). Do not focus on pricing in this step, as your choice of business model has a far larger influence on profitability than your pricing decisions.

      • Licensing: your royalty rate will generally be equivalent to one-twentieth or less of the revenue per sale; and hence the TAM will as well, because a five percent royalty rate is about the best you can hope for.

    • *16 Set Your Pricing Framework:

    • *17 Calculate the Lifetime Value (LTV) of an Acquired Customer: P 184,

    • 18 Map the Sales Process to Acquire a Customer: P 199,

    • 19 Calculate the Cost of Customer Acquisition (COCA): P 209, 210, 211,

    • 20 Identify Key Assumptions: “Minimum Viable Business Product” (MVBP)—a different concept than the MVP ;

    • 21 Test Key Assumptions: P: 227,

    • 22 Define the Minimum Viable Business Product (MVBP): P: 237,

    • 23 Show That “The Dogs Will Eat the Dog Food”:

    • 24 Develop a Product Plan:

  • you will also need to learn about many other things including the following:

      • • Building a Company Culture

      • • Selecting a Founding Team

      • • Growing and Building the Team (HR Processes)

      • • Developing the Product

      • • Selling and Sales Execution

      • • Servicing the Customer and Building Customer Service Processes

      • • Building Your Financials and Managing Cash Flow

      • • Raising Money to Scale the Business

      • • Entrepreneurial Leadership and Scaling the Business

      • • Building and Utilizing Good Company Governance

      • • And much more

Cracking the coding interview 189 programming questions and solutions (700 pages)

Cracking the Tech Career: Insider Advice on Landing a Job at Google, Microsoft, Apple, Or Any Top Tech Company (288 pages)


Magazine

Link Groups

Books

Magazine

Books

Videos

Papers

  • CALTag: High Precision Fiducial Markers for Camera

  • Diatom Autofocusing in Brightfield Microscopy: a Comparative Study

  • Analysis of focus measure operators in shape-from-focus

  • Optical flow modeling and computation: A survey

  • Toward general type 2 fuzzy logic systems based on zSlices

Site

Reference in Computer vision and Deep Learning


Papers

Documents

Websites and links

YouTube

  • DRANBLEIBEN, 6/5 minutes journal,

  • List

    • Disrupted: My Misadventure in the Start-Up Bubble | Dan Lyons | Talks at Google; YouTube;

Language :