Thai Vo

Clean Code by Robert C. Martin - Code quality is your responsibility

Sat, 04 Apr 2020 00:00:00 GMT

If you care about quality of your software, happiness of your colleagues, and professionalism of yourself, you should read this book.

You will very soon pay for bad code, much sooner than you may expected. We spend most of our development time in reading code. The ratio of reading and writing is around 10:1. So please write clean code, that will help you and your colleagues a lot.

Clean Code - A Handbook of Agile Software Craftmanship, by Robert C. Martin. Image source: kobo.com

Texts in italic, bullet/numbered lists and source code examples are quotes from the book.

If you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read.

Working program is not enough. They must have readability, flexibility, maintainability, and reusability. Getting software to work and making software clean are two very different activities. Most of us have limited room in our heads, so we focus on getting our code to work more than organization and cleanliness. The problem is that too many of us think that we are done once the program works.

There are many recommendations and guidelines to help us make our code clean. They will be listed below, then summarized in Smells and Heuristics. However, there are some points that I have my own idea, they will be listed in the very last section: What do I not agree.

#1: Clean Code

Most managers may defend the schedule and requirements with passion; but that's their job. It's your job to defend the code with equal passion. It is programmer's responsibility to tell managers about the importance of code quality and the cost of owning a mess. Write clean code will save you time sooner than you can imagine.

You will not make the deadline by making the mess. Indeed, the mess will slow you down instantly, and will force you to miss the deadline. The only way to make the deadline - the only way to go fast - is to keep the code as clean as possible at all times.

Some people can "smell" bad code, but don't know how to write clean one, just like cooking.

Many definitions

There are many definitions and point of views about clean code. Based on perspective, background, experience...

Bjarne Stroustrup, inventor of C++ and author of "The C++ Programming Language":

I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.

Grady Booch, author of "Object Oriented Analysis and Design with Applications":

Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer's intent but rather is full of crisp abstractions and straightforward lines of control.

"Big" Dave Thomas, founder of OTI, godfather of the Eclipse strategy:

"Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. It has minimal dependencies, which are explicitly defined, and provides a clear and minimal API.

Michael Feathers, author of "Working Effectively with Legacy Code":

Clean code always looks like it was written by someone who cares.

Ron Jeffries, author of "Extreme Programming Installed" and "Extreme Programming Adventures in C#":

Reduced duplication, high expressiveness, and early building of simple abstractions. That's what makes clean code for me.

Leave this world a little better than you found it... Leave the code a little cleaner than you checked it out...

#2: Meaningful Names

Choosing good names takes time but saves more than it takes. So take care with your names and change them when you find better ones.

There are many simple rules for good names:

Use intention-revealing names
Avoid disinformation
Make meaningful distinctions: distinguish names in such a way that the reader knows what the differences offer
Use pronounceable names
Use searchable names
Avoid encodings
Avoid mental mapping
Classes and objects should have noun or noun phrase names
Methods should have verb or verb phrase names
Don't be cute
Pick one word for one abstract concept and stick with it
Avoid using the same word for two purposes
Use solution domain names: technical terms, computer science terms, algorithm names, pattern names, math terms...
Use problem domain names
Add meaningful context
Don't add gratuitous context: shorter names are generally better than longer ones, so long as they are clear

#3: Clean Functions

Should be small, but deep. Keeping functions small and deep is hard. Whatever they are, they should be clean. You can achieve this by refactoring and extracting functions.

Do one thing: Functions should do one thing. They should do it well. They should do it only.

Use descriptive names: You know you are working on clean code when each routine turns out to be pretty much what you expected. Don't be afraid to make a name long. A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment.

Arguments: Keep as less function arguments as possible. Because it introduces more detail, it also make testing harder. Consider instance variable or wrap arguments into a class.

Avoid output arguments: If a function is going to transform its input argument, the transformation should appear as the return value. If your function must change the state of something, have it change the state of its own object.

Avoid flag arguments: It immediately complicates the signature of the method, loudly proclaiming that this function does more than one thing.

Command query separation: Functions should either do something or answer something, but not both.

A function should have no side effects.

Anything that forces you to check the function signature is equivalent to a double-take. It's a cognitive break and should be avoided.

#4: Comments

Comment is excuse for bad code. The proper use of comments is to compensate for our failure tor express ourself in code.

When code evolves, it is hard to maintain correctness and up-to-date of its comments. Inaccurate comments are more dangerous than no comment at all. The only truly good comment is the comment that you found a way not to write.

We know it's a mess. So we say to ourselves, "Ooh, I'd better comment that!" No! You'd better clean it!

Try to make the self-explain. Instead of doing this:

// Check to see if the employee is eligible for full benefits
if ((employee.flags && HOURLY_FLAG) &&
    (employee.age > 65))

Do this:

if (employee.isEligibleForFullBenefits())

Bad comments

Mumbling. If you decide to write a comment, then spend the time necessary to make sure it is the best comment you can write.
Redundant: repeat, clutter, obscure code
Misleading
Mandated comments
Journal comments
Noise: restate the obvious and provide no new information. We learned to ignore them, our eyes simply skip over them. Eventually the comments begin to lie as the code around them changes. Bad examples:

/**
 * Returns the day of the month.
 *
 * @return the day of the month.
 */
 public int getDayOfMonth() {
   return dayOfMonth;
 }

/** The name. */
private String name;

/** The version. */
private String version;

Don't use a comment when you can use function names and variable names
Position markers. For example:

// Actions ///////////////////////////////////////

Closing brace comments: If you find yourself wanting to mark your closing braces, try to shorten your functions instead.
Attributions and bylines
Commented-out code: Just delete the code. We won't lose it. Promise.
HTML comments
Nonlocal information: Make sure a comment describes the code it appears near. Don't offer systemwide information in the context of a local comment.
Too much information
Inobvious connection between a comment and the code it describes. It is a pity when a comment needs its own explanation.
Function headers

Necessary comments

But in some cases, we need comments:

Legal, copyright, authorship
Informative

// format matched kk:mm:ss EEE, MMM dd, yyyy
Pattern timeMatcher = Pattern.compile(
  "\\d*:\\d*:\\d* \\w*, \\w* \\d*, \\d*");

Explanation of intent behind a decision
Clarification: make obscure thing more readable
Warning of consequences
//TODO
Amplify importance of something that may be missed
Docs for public APIs

#5: Code Formatting

Code formatting is important. It is about communication, and communication is the professional developer's first order of business.

The coding style and readability set precedents that continue to affect maintainability and extensibility long after the original code has been changed beyond recognition. Your style and discipline survives, even though your code does not.

There are many guidelines for keeping code format "natural" and easy to navigate:

Small files are usually easier to understand than large files.
Related concepts should be kept close to each other. We want to avoid forcing our readers to hop around through our source files and classes.
Keep lines short.

Variables

Variables should be declared as close to their usage as possible.
Instance variables should be declared at the top of the class, because in a well-designed class, they are used by many, if not all, of the methods of the class.

Functions

If one function calls another, they should be vertically close, and the caller should be above the callee, if possible. This gives the program a natural flow. This creates a nice flow down the source code module from high level to low level.

This is the exact opposite of languages like Pascal, C, and C++ that enforce functions to be defined, or at least declared, before they are used.

#6: Objects and Data Structures

Procedural code (code using data structures) makes it easy to add new functions without changing the existing data structures. OO code, on the other hand, makes it easy to add new classes without changing existing functions.

Procedural code makes it hard to add new data structures because all the functions must change. OO code makes it hard to add new functions because all the classes must change.

#7: Error Handling

Error handling is important, but if it obscures logic, it's wrong.

Some techniques and considerations for error handling:

Use exceptions rather than return codes
Write your try-catch-finally statement first
Use unchecked exceptions: stack trace, informative error messages
Define exception classes in terms of a caller's needs: concern about how exceptions are caught
Define the normal flow
Don't return null. Checking null after each function call is bad. If we don't check, what exactly should you do in response to a NullPointerException throw from the depths of your application?
Don't pass null. Avoid whenever possible.

#8: Boundaries

Learning the third-party code is hard. Integrating the third-party code is hard too. Doing both at the same time is doubly hard.

Learning/Boundary test: verify that the third-party packages we are using work the way we expect them to. If the third-party package changes in some way incompatible with our tests, we will find out right away.

#9: Unit Tests

It is unit tests that keep your code flexible, maintainable, and reusable.

Having dirty tests is equivalent to, if not worse than, having no tests. The problem is that tests must change as the production code evolves. Test code is as important as production code.

Only put expressive code to the test: build data, operate on that data, and check expected results. Other things are considered noise and should be refactored to helper methods.

FIRST rule

Fast
Independent
Repeatable: in any environment: production, QA, local without network
Self-validating: have boolean output: pass or fail
Timely

#10: Classes

Single responsibility: We regularly encounter classes that do far too many things. But, a class or module should have one, and only one, reason to change.
Organizing for change: Needs will change, therefore code will change. Change is continual. Change introduces risks, and must be retested.

This chapter focuses on making classes small. But I would prefer keeping them "deep", as stated in "A Philosophy of Software Design" post and "What do I not agree" section below. Sometimes, deep and small are 2 different directions. I also don't agree with some code improvement examples in this chapter because of the same reason.

#11: Systems

Software systems are unique compared to physical systems. Their architectures can grow incrementally.

It is a myth that we can get systems "right in the first time."

About design process: Big Design Up Front (BDUF) is harmful because it inhibits adapting to change, due to the psychological resistance to discarding prior effort and because of the way architecture choices influence subsequent thinking about design.

Whether you are designing systems or individual modules, never forget to use the simplest thing that can possibly work.

About decision making: It is also best to postpone decisions until the last possible moment. This isn't lazy or irresponsible; it lets us make informed choices with the best possible information. A premature decision is a decision made with suboptimal knowledge.

#12: Emergence

A design is "simple" if it follow these rules, in order of importance:

Runs all the tests
Contains no duplication
Expresses the intent of the programmer
Minimizes the number of classes and methods

#13: Concurrency

Concurrency is hard:

Concurrency incurs some overhead, both in performance as well as writing additional code.
Correct concurrency is hard, even for simple problems.
Concurrency bugs aren't usually repeatable, so they are often ignored as one-offs instead of the true defects they are.
Concurrency often requires a fundamental change in design strategy.

Concurrency myths and misconceptions:

Concurrency always improves performance
Design does not change when writing concurrent programs

Useful recommendations:

Keep your concurrency-related code separate from other code
Take data encapsulation to heart; severely limit the access of any data that may be shared
Attempt to partition data into independent subsets than can be operated on by independent threads, possibly in different processors
Keep your synchronized sections as small as possible
Do not ignore system failures as one-offs
Do not try to chase down nonthreading bugs and threading bugs at the same time. Make sure your code works outside of threads.
Make your thread-based code especially pluggable so that you can run it in various configurations
Run your threaded code on all target platforms early and often

Deadlock

This book has a very good part about deadlock: causes, how to avoid and how to test: on Appendix A, page 335.

#14: Successive Refinement

If we have learned anything over the last couple of decades, it is that programming is a craft more than it is a science. To write clean code, you must first write dirty code and then clean it.

It is not enough for code to work. Code that works is often badly broken. Programmers who satisfy themselves with merely working code are behaving unprofessionally. They may fear that they don't have time to improve the structure and design of their code, but I disagree. Nothing has a more profound and long-term degrading effect upon a development project than bad code. Bad schedules can be redone, bad requirements can be redefined. Bad team dynamics can be repaired. But bad code rots and ferments, becoming an inexorable weight that drags the team down. Time and time again I have seen teams grind to a crawl because, in their haste, they created a malignant morass of code that forever thereafter dominated their destiny.

Of course bad code can be cleaned up. But it's very expensive. As code rots, the modules insinuate themselves into each other, creating lots of hidden and tangled dependencies. Finding and breaking old dependencies is a long and arduous task. On the other hand, keeping code clean is relatively easy. If you made a mess in a module in the morning, it is easy to clean it up in the afternoon. Better yet, if you made a mess five minutes ago, it's very easy to clean it up right now.

So the solution is to continuously keep your code as clean and simple as it can be. Never let the rot get started.

Smells and Heuristics

Key points stated in previous chapters:

General:

Multiple languages in one source file
Obvious behavior is unimplemented
Incorrect behavior at the boundaries
Overridden safeties
Duplication
Code at wrong level of abstraction
Base classes depending on their derivatives
Too much information
Dead code
Vertical separation
Inconsistency
Clutter
Artificial coupling
Feature envy
Selector arguments
Obscured intent
Misplaces responsibility
Inappropriate static
Use explanatory variables
Function names should say what they do
Understand the algorithm
Make logical dependencies physical
Prefer polymorphism to if/else or switch/case
Follow standard conventions
Replace magic numbers with named constants
Be precise
Structure over convention
Encapsulate conditionals
Avoid negative conditionals
Functions should do one thing
Hidden temporal couplings
Don't be arbitrary
Encapsulate boundary conditions
Functions should descend only one level of abstraction
Keep configurable data at high levels
Avoid transitive navigation

Names:

Choose descriptive names
Choose names at the appropriate level of abstraction
Use standard nomenclature where possible
Unambiguous names
Use long names for long scopes
Avoid encodings
Names should describe side-effects

Functions:

Too many arguments
Output arguments
Flag arguments
Dead function

Tests:

Insufficient tests
Use a coverage tool
Don't skip trivial tests
An ignored test is a question about an ambiguity
Test boundary conditions
Exhaustively test near bugs
Patterns of failure are revealing
Test coverage patterns can be revealing
Tests should be fast

Comments:

Inappropriate information
Obsolete comment
Redundant comment
Poorly written comment
Commented-out code

Environment:

Build requires more than one step
Tests requires more than one step

Java:

Avoid long import lists by using wildcards
Don't inherit constants
Constants versus enums

What do I not agree

Small and deep

The small function/class rule of this book, in some specific cases, contradicts with the deep module principle of "A Philosophy of Software Design" by John Ousterhout. In cases that raise a contradiction, I would prefer the "deep module" principle. Deep does not mean unclean. With good skills, we can make deep modules/classes clean.

Listing 3-7

To make functions "do just one thing", the author break them into smaller ones. In my opinion, this increase reference cost, reader must read forward and backward go get the big picture. Each function is shallow. They just do "elemental" things, and doesn't provide any extra calculation except calling another function. They are just function forwarder. A lot of references to get one thing done make the code harder to read.

My proposed change: functions can do more than one thing. As long as they provide helpful calculation, keep themselves clean and easy to read. No need to do function references here and there in order to just keep them small.

Listing 9-4, 9-5

Reader must have knowledge about upper and lower case convention, or need to read many functions in production code, to understand what HBchL actually mean.

Final words

Reading the book is not enough. You must practice. Do code reviews in many years will make the most of it.

Happy coding. And make your colleagues happy coders, too.

A Philosophy of Software Design by John Ousterhout - All about complexity

Sun, 08 Dec 2019 00:00:00 GMT

Writing computer software is one of the purest creative activities in the history of the human race. Programmers aren't bound by practical limitations such as the laws of physics; we can create exciting virtual worlds with behaviors that could never exist in the real world. Programming doesn't require great physical skill or coordination, like ballet or basketball. All programming requires is a creative mind and the ability to organize your thoughts. If you can visualize a system, you can probably implement it in a computer program.

This book is must-read for programmers who want to improve design skill and build greater, long-lasting software. Its principles can be applied for both architectural level and code organization.

Contents are copied from the book and the author's talk at Google.

A Philosophy of Software Design, by John Ousterhout. Image source: ebook3000

The greatest limitation in writing software is our ability to understand the systems we are creating.

It's all about complexity

If we want to make it easier to write software, so that we can build more powerful systems more cheaply, we must find ways to make software simpler.

This book is about one thing: complexity. Dealing with complexity is the most important challenge in software design. It is what makes systems hard to build and maintain, and it often makes them slow as well.

Furthermore, the investments you make in good design will pay off quickly. The modules you defined carefully at the beginning of a project will save you time later as you reuse them over and over. The clear documentation that you wrote six months ago will save you time when you return to the code and add a new feature. The time you spent honing your design skills will also pay for itself: as your skills and experience grow, you will find that you can produce good designs more and more quickly. Good design doesn't really take much longer than quick-and-dirty design, once you know how.

Investment. Image source: Pixabay

The reward for being a good designer is that you get to spend a larger fraction of your time in the design phase, which is fun. Poor designers spent most of their time chasing bugs in complicated and brittle code. If you improve your design skills, not only will you produce higher quality software more quickly, but the software development process will be more enjoyable.

The nature of complexity

It is easier to tell whether a design is simple than it is to create a simple design, but once you can recognize that a system is too complicated, you can use that ability to guide your design philosophy towards simplicity.

Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.

Complexity is more apparent to readers and writers. If you write a piece of code and it seems simple to you, but other people think it is complex, then it is complex. Your job as a developer is not just to create code that you can work with easily, but to create code that others can also work with easily. Software should be designed for ease of reading, not ease of writing.

Symptoms of complexity:

Change amplification: a seemingly simple change requires code modifications in many different places.
Cognitive load: how much a developer needs to know in order to complete a task. A higher cognitive load means that developers have to spend more time learning the required information, and there is a greater risk of bugs because they have missed something important. Sometimes an approach that requires more lines of code is actually simpler, because it reduces cognitive load.
Unknown unknowns: it is not obvious which pieces of code must be modified to complete a task, or what information a developer must have to carry out the task successfully.

Complexity is caused by two things: dependencies and obscurity. Complexity isn't caused by a single catastrophic error; it accumulates in lots of small chunks. Once complexity has accumulated, it is hard to eliminate, since fixing a single dependency or obscurity will not, by itself, make a big difference.

Strategic vs. tactical programming

If you want a good design, you must take a more strategic approach where you invest time to produce clean designs and fix problems. The strategic approach produces better designs and is actually cheaper than the tactical approach over the long run.

Once you start down the tactical path, it's difficult to change. Tactical programming makes it nearly impossible to produce a good system design. If you are in a company leaning in this direction, you should realize that once a code base turns to spaghetti, it is nearly impossible to fix. You will probably pay high development costs for the life of the product.

The first step towards becoming a good software designer is to realize that working code isn't enough. It's not acceptable to introduce unnecessary complexities in order to finish your current task faster. The most important thing is the long-term structure of the system. Most of the code in any system is written by extending the existing code base, so your most important job as a developer is to facilitate those future extensions. Thus, you should not think of "working code" as your primary goal, though of course your code must work. Your primary goal must be to produce a great design, which also happens to work. This is strategic programming.

At the beginning, a tactical approach to programming will make progress more quickly than a strategic approach. However, complexity accumulates more rapidly under the tactical approach, which reduces productivity. Over time, the strategic approach results in greater process. Image source: the author's talk at Google

Once you start delaying design improvements, it's easy for the delays to become permanent and for your culture to slip into the tactical approach. The longer you wait to address design problems, the bigger they become; the solutions become more intimidating, which makes it easy to put them off even more.

One of the most important factors for success of a company is the quality of its engineers. The best way to lower development costs is to hire great engineers: they don't cost much more than mediocre engineers but have tremendously higher productivity. However, the best engineers care deeply about good design. If your code base is a wreck, word will get out, and this will make it harder for you to recruit. As a result, you are likely to end up with mediocre engineers. This will increase your future costs and probably cause the system structure to degrade even more.

Modules should be deep

The best modules are those whose interfaces are much simpler than their implementations. Such modules have two advantages. First, a simple interface minimizes the complexity that a module imposes on the rest of the system. Second, if a module is modified in a way that does not change its interface, then no other module will be affected by the modification.

Deep classes are more efficient than shallow ones, because they get more work done for each method call. Shallow classes result in more layer crossings, and each layer crossing adds overhead.

Classes should be thick. Image source: Can great programmers be taught? - John Ousterhout, Stanford University

This maximizes the amount of complexity that is concealed.

Pull complexity downwards

It is more important for a module to have simple interface than a simple implementation.

When developing a module, look for opportunities to take a little bit of extra suffering upon yourself in order to reduce the suffering of your users.

General-purpose modules are deeper

The module's functionality should reflect your current needs, but its interface should not. Instead, the interface should be general enough to support multiple uses.

One of the most important elements of software design is determining who needs to know what, and when. When the details are important, it is better to make them explicit and as obvious as possible.

Avoid configuration parameters

You should avoid configuration parameters as much as possible. Before exporting a configuration parameter, ask yourself: "will users (or higher-level modules) be able to determine a better value than we can determine here?" When you do create configuration parameters, see if you can compute reasonable defaults automatically, so users will only need to provide values under exceptional conditions. Ideally, each module should solve a problem completely; configuration parameters result in an incomplete solution, which adds to system complexity.

Better together or better apart?

If the components are truly independent, then separation is good: it allows the developer to focus on a single component at a time, without being distracted by the other components. On the other hand, if there are dependencies between the components, then separation is bad: developers will end up flipping back and forth between the components. Even worse, they may not be aware of the dependencies, which can lead to bugs.

When designing methods, the most important goal is to provide clean and simple abstractions. Each method should do one thing and do it completely. The method should have a clean and simple interface, so that users don't need to have much information in their heads in order to use it correctly. The method should be deep: its interface should be much simpler that its implementations. If a method has all of these properties, then it probably doesn't matter whether it is long or not.

Define errors out of existence

The exceptions throw by a class are part of its interface; classes with lots of exceptions have complex interfaces, and they are shallower than classes with fewer exceptions. An exception is a particularly complex element of an interface.

Throwing exceptions is easy; handling them is hard. Thus, the complexity of exceptions comes from the exception handling code. The best way to reduce the complexity damage caused by exception handling is to reduce the number of places where exceptions have to be handled.

The best way to reduce bugs is to make software simpler.

Design special cases out of existence

Special cases should be eliminated wherever possible. The best way to do this is by designing the normal case in a way that automatically handles the special cases without any extra code.

Special cases of any form make code harder to understand and increase the likelihood of bugs.

Write comments

Developers should be able to understand the abstraction provided by a module without reading any code other than its externally visible declarations.

The process of writing comments, if done correctly, will actually improve a system's design. Conversely, a good software design loses much of its value if it is poorly documented.

The reason for writing comments is that statements in a programming language can't capture all of the important information that was in the mind of the developer when the code was written. The guiding principle for comments is that comments should describe things that aren't obvious from the code, it is to capture information that was in the mind of the designer but couldn't be represented in the code. Without documentation, future developers will have to re-derive or guess at the developer's original knowledge; this will take additional time, and there is a risk of bugs if the new developer misunderstands the original designer's intentions.

Comments augment the code by providing information at a different level of detail. Some comments provide information at a lower, more detailed, level than the code; these comments add precision by clarifying the exact meaning of the code. Other comments provide information at a higher, more abstract, level than the code; these comments offer intuition, such as the reasoning behind the code, or a simpler and more abstract way of thinking about the code.

Modify existing code

Ideally, when you have finished with each change, the system will have the structure it would have had if you had designed it from the start with that change in mind. To achieve this goal, you must resist the temptation to make a quick fix. Instead, think about whether the current system design is still the best one, in light of the desired change. If not, refactor the system so that you end up with the best possible design. With this approach, the system design improves with every modification. If you're not making the design better, you are probably making it worse.

Consistency

If a system is consistent, it means that similar things are done in similar ways, and dissimilar things are done in different ways. Consistency creates cognitive leverage: once you have learned how something is done in one place, you can use that knowledge to immediately understand other places that use the same approach. If a system is not implemented in a consistent fashion, developers must learn about each situation separately.

The more nit-picky that code reviewers are, the more quickly everyone on the team will learn the conventions, and the cleaner the code will be.

Consistency is another example of the investment mindset. It will take a bit of extra work to ensure consistency: work to decide on conventions, work to create automated checkers, work to look for similar situations to mimic in new code, and work in code reviews to educate the team. The return on this investment is that your code will be more obvious. Developers will be able to understand the code's behavior more quicky and accurately, and this will allow them to work faster, with fewer bugs.

Design for performance

It's tempting to rush off and start making performance tweaks, based on your intuitions about what is slow. Don't do this! Programmers' intuitions about performance are unreliable. This is true even for experienced developers. If you start making changes based on intuition, you'll waste time on things that don't actually improve performance, and you'll probably make the system more complicated in the process.

Design it twice

Designing software is hard, so it's unlikely that your first thoughts about how to structure a module or system will produce the best design. You'll end up with a much better result if you consider multiple options for each major design decision: design it twice.

Try to pick approaches that are radically different from each other; you'll learn more that way. Even if you are certain that there is only one reasonable approach, consider a second design anyway, no matter how bad you think it will be. It will be instructive to think about the weaknesses of that design and contrast them with the features of other designs. After you have roughed out the designs for the alternatives, make a list of the pros and cons of each one.

It is also worth considering other factors:

Does one alternative have a simpler interface than another?
Is one interface more general-purpose than another?
Does one interface enable a more efficient implementation than another?
Is one interface ease of use for higher level software?

Once you have compared alternative designs, you will be in a better position to identify the best design. The best choice may be one of the alternatives, or you may discover that you can combine features of multiple alternatives into a new design that is better than any of the original choices.

Smart people

The design-it-twice principle is sometimes hard for really smart people to embrace. When they are growing up, smart people discover that their first quick idea about any problem is sufficient for a good grade; there is no need to consider a second or third possibility. This makes it easy to develop bad work habits. However, as these people get older, they get promoted into environments with harder and harder problems. Eventually, everyone reaches a point where your first ideas are no longer good enough; if you want to get really great results, you have to consider a second possibility, or perhaps a third, no matter how smart you are. The design of large software systems falls in this category: no-one is good enough to get it right with their first try.

Unfortunately, I often see smart people who insist on implementing the first idea that comes to mind, and this causes them to underperform their true true potential (it also makes them frustrating to work with). Perhaps they subconsciously believe that "smart people get it right the first time," so if they try multiple designs it would mean they are not smart after all. This is not the case. It isn't that you aren't smart; it's that the problems are really hard! Furthermore, that's a good thing: it's much more fun to work on a difficult problem where you have to think carefully, rather than an easy problem where you don't have to think at all.

The design-it-twice approach not only improves your designs, but it also improves your design skills. The process of devising and comparing multiple approaches will teach you about the factors that make designs better or worse. Over time, this will make it easier for you to rule out bad designs and hone in on really great ones.

Process

Because software is so malleable, software design is a continuous process that spans the entire lifecycle of a software system; this makes software design different from the design of physical systems such as buildings, ships, or bridges.

The waterfall model rarely works well for software. Software systems are intrinsically more complex than physical systems; it isn't possible to visualize the design for a large software system well enough to understand all of its implications before building anything. As a result, the initial design will have many problems. The problems do not become apparent until implementations is well underway.

Incremental development means that software design is never done. Design happens continuously over the life of a system: developers should always be thinking about design issues. Incremental development also means continuous redesign. The initial design for a system or component is almost never the best one; experience inevitably shows better ways to do things. As a software developer, you should always be on the lookout for opportunities to improve the design of the system you are working on, and you should plan on spending some fraction of your time on design improvements.

It isn't possible to visualize a complex system well enough at the outset of a project to determine the best design. The best way to end up with a good design is to develop a system in increments, where each increment adds a few new abstractions and refactors existing abstractions based on experience.

Test-driven development (TDD)

The problem with test-driven development is that it focuses attention on getting specific features working, rather than finding the best design. This is tactical programming pure and simple, with all of its disadvantages. Test-driven development is to incremental: at any point in time, it's tempting to just hack in the next feature to make the next test pass. There's no obvious time to design, so it's easy to end up with a mess.

One place where it makes sense to write the tests first is when fixing bugs. Before fixing a bug, write a unit test that fails because of the bug. Then fix the bug and make sure that the unit test now passes. This is the best way to make sure you really have fixed the bug. If you fix the bug before writing the test, it's possible that the new unit test doesn't actually trigger the bug, in which case it won't tell you whether you really fixed the problem.

Summary

Here are the most important software design principles discussed in this book:

Complexity is incremental: you have to sweat the small stuff.
Working code isn't enough.
Make continual small investments to improve system design.
Modules should be deep.
Interfaces should be designed to make the most common usage as simple as possible.
It's more important for a module to have a simple interface than a simple implementation.
General-purpose modules are deeper.
Separate general-purpose and special-purpose code.
Different layers should have different abstractions.
Pull complexity downward.
Define errors (and special cases) out of existence.
Design it twice.
Comments should describe things that are not obvious from the code.
Software should be designed for ease of reading, not ease of writing.
The increments of software development should be abstractions, not features.

Here are a few of the most important red flags discussed in this book. The presence of any of these symptoms in a system suggests that there is a problem with the system's design:

Shallow module: the interface for a class or method isn't much simpler than its implementation.
Information leakage: a design decision is reflected in multiple modules.
Temporal decomposition: the code structure is based on the order in which operations are executed, not on information hiding.
Overexposure: an API forces callers to be aware of rarely used features in order to use commonly used features.
Pass-through method: a method does almost nothing except pass its arguments to another method with a similar signature.
Repetition: a nontrivial piece of code is repeated over and over.
Special-general mixture: special-purpose code is not cleanly separated from general purpose code.
Conjoined methods: two methods have so many dependencies that it is hard to understand the implementation of one without understanding the implementation of the other.
Comment repeats code: all of the information in a comment is immediately obvious from the code next to the comment.
Implementation documentation contaminates interface: an interface comment describes implementation details not needed by users of the thing being documented.
Vague name: the name of a variable or method is so imprecise that it doesn't convey much useful information.
Hard to pick name: it is difficult to come up with a precise and intuitive name for an entity.
Hard to describe: in order to be complete, the documentation for a variable or method must be long.
Nonobvious code: the behavior or meaning of a piece of code cannot be understood easily.

Other good notes

Every rule has its exceptions, and every principle has its limits. If you take any design idea to its extreme, you will probably end up in a bad place. Beautiful designs reflect a balance between competing ideas and approaches.

There is quite a bit of scientific evidence that outstanding performance in many fields is related more to high-quality practice than innate ability.

The author also had this talk at Google, which is good and worth watching.

Why I need a good laptop? And a good laptop only

Tue, 09 Jul 2019 00:00:00 GMT

In my life, beside sleep, maybe using computer is the most time-consuming and meaningful activity. That's why I choose it carefully, invest a lot in it, both hardware and software.

Hardware

Why to choose laptop over desktop: mobility. I can bring laptop almost everywhere in the world. In the weekend, if bored with staying in the same room, I can go to cafeteria, park, or mountain and continue to code. I cannot do so with a PC.

Why MacBook: comfortable. It is expensive. But if I use that laptop for 3 years, more than 1000 days, and it costs $3000, so $3 a day is not expensive at all for a device that can earn money and grow me to new level. I do not care if today I am having $5 fruit or not, so why I should bother if today I am spending $3 for such an important device? Laptop is an investment that make my life easier and happier.

Another important reason is most companies I work with provide employees MacBooks. So I can get familiar with working environment both at company and at home. If you use one tool set in company and another at home, that would cost you a lot of time and happiness.

Why chose to use a not-so-good laptop keyboard instead of mechanical one: again, mobility. I had a blue-switch mechanical keyboard, a split-layout ErgoDox EZ and used them for years. Mechanical keyboards provide far more good-feeling to fingers and mind than laptop keyboards. I always love the feeling when using it. But now I am more focus on working mobility, and have to sacrifice that good feeling. I would prefer coding on top of a mountain rather than stick with a favorite mechanical keyboard but stay in an air-conditioned room.

Same reason to a separate big monitor. I use a Dell UltraSharp at work, because I usually not bring company work to the jungle. But I do not use a monitor at home, because I sometimes code side project on the edge of a cliff. Where impractical to bring monitor or keyboard to.

Me on a mountain. That was a memorable experience

Getting familiar with a well-setup and many-device working space takes me to a strange environment if I want to move. And I often move. Right after changing environment, laptop's built-in keyboard can felt not good enough and typing speed reduces 10 percent compared to mechanical keyboard. My eyes are little painful after switching between different screen resolutions. Window arrangement has just filled for large screen now must be rearranged to fit in smaller space. These things have switching costs. Now I prefer easy movement to many types of environments, as long as my laptop can be brought there.

Similar with speaker. I used to have a good 2.1 one. But now, my laptop's built-in speaker is acceptable. And I have AirPods. They are good enough for almost all my current needs.

A good laptop fits 80 percent of my requirements at the beginning, and now 95 percent after weeks playing around. That is ok for me and I am still happy with my lovely device. Until I find a new interesting way to experience.

Software

Taking the chance of having new laptop, I would like to reinstall and research everything about tools which I want to install in it, for working, learning, and playing purposes. So I started with a terminal. Besides browser, terminal is my most active software.

If you are interested in how I setup working softwares, please continue on reading this post (will release soon). Hope you will get some useful information there.

Building Microservices by Sam Newman - Think about it carefully before using it

Mon, 06 May 2019 00:00:00 GMT

This post summarizes points that I feel interesting and worth remembering. Contents are copied from the book.

"The Microservices architecture has many appealing qualities, but the road towards it has painful traps for the unwary. This book will help you figure out if this path is for you, and how to avoid those traps on your journey." - Martin Fowler

Building Microservices - Designing Fine-Grained Systems, by Sam Newman. Image source: O'Reilly

1. Microservices

Microservices are small, autonomous services that work together.

Key benefits:

Technology heterogeneity
Resilience
Scaling
Ease of deployment
Organizational alignment
Composability
Optimizing for replaceability

Microservices are no free lunch or silver bullet and make for a bad choice as a golder hammer. They have all the associated complexity of distributed systems.

2. The evolutionary architect

Architects can have a direct impact on the quality of the systems built, on the working conditions of their colleagues, and on their organization's ability to respond to change.

Our architects need to shift their thinking away from creating the perfect end product, and instead focus on helping create a framework in which the right systems can emerge, and continue to grow as we learn more.

Making decisions in system design is all about trade-offs, and microservice architecture give us lots of trade-offs to make.

Great software comes from great people. If you worry only about the technology side of the equation, you're missing way more than half of the picture.

3. How to model services

We want to find boundaries within our problem domain that help ensure that related behavior is in one place, and that communicate with other boundaries as loosely as possible.

Loose coupling: A change to one service should not require a change to another. A loosely coupled service knows as little as it needs to about the services with which it collaborates.
High cohesion: We want related behavior to sit together, and unrelated behavior to sit elsewhere.

Premature decomposition

When starting out, however, keep the new system on the more monolithic side; getting service boundaries wrong can be costly, so waiting for things to stabilize as you get to grips with a new domain is sensible.

Premature decomposing a system into microservices can be costly, especially if you are new to the domain. In many ways, having an existing codebase you want to decompose into microservices is much easier than trying to go to microservices from the beginning.

4. Integration

Build if it is unique to what you do, and can be considered a strategic asset; buy if your use of the tool isn't that special.

Keep your APIs technology-agnostic: Avoid integration technology that dictates what technology stacks we can use.

Avoid shared database at (nearly) all costs.

Two different idiomatic styles of collaboration

Request/Response: a client initiates a request and waits for the response.
Event-based: says thing happened and expects other parties to know what to do.
Highly decoupled: the client that emits an event doesn't have any way of knowing who or what will react to it.

Don't Repeat Yourself (DRY)

DRY more accurately means that we want to avoid duplicating our system behavior and knowledge.

Don't violate DRY within a microservice, but be relaxed about violating DRY across all services. The evils of too much coupling between services are far worse than the problems caused by code duplication.

5. Splitting the monolith

Seam is a portion of the code that can be treated in isolation and worked on without impacting the rest of the codebase. Identify seams that can become service boundaries.

There is no need for this to be a big-bang approach. It is something that can be done bit by bit, day by day.

We can - and will - make mistakes, and we should embrace that. What we should also do, though, is understand how best to mitigate the costs of those mistakes.

6. Deployment

CI/CD

With Continuous Integration (CI), the core goal is to keep everyone in sync with each other, which we achieve by making sure that newly checked-in code properly integrates with existing code.

Build pipeline: having different stages in our build. We build our artifact, and that artifact is used throughout the pipeline. As our artifact moves through these stages, we feel more confident that the software will work in production.

Continuous Delivery (CD) is the approach whereby we get constant feedback on the production readiness of each and every check-in, and furthermore treat each and every check-in as a release candidate.

CI builds artifacts, CD validates artifacts.

Automation

Embracing a culture of automation is key if you want to keep the complexities of microservices architectures in check.

Automate everything, and if the technology you have doesn't allow this, get some new technology!

7. Testing

Optimize for fast feedback, and separate types of tests accordingly.

Avoid the need for end-to-end tests wherever possible. Focus on a small (very low double digits even for complex system) number of core journeys to test for the whole system. Any functionality not covered in these core journeys needs to be covered in tests that analyze services in isolation from each other.

8. Monitoring

Monitor the small things, and use aggregation to see the bigger picture.

We can never know what data will be useful.

Monitoring is one area where standardization is incredibly important:

Write your logs out in a standard format
Have all your metrics in one place
Have a list of standard names for your metrics

Use correlation IDs to track call chains across multiple services. With the right log aggregation tooling, you'll then be able to trace that event all the way through your system. You can picture the whole cascade of calls.

9. Security

Authentication is the process by which we confirm that a party is who she says she is.

Type in username and password.
Use fingerprint to confirm.
Use face to confirm (Face ID)

When we are talking abstractly about who or what is being authenticated, we refer to that party as the principal.

Authorization is the mechanism by which we map from a principal to the action we are allowing her to do.

Go with the well known: The easiest way you can mess up data encryption is try to implement your own encryption algorithms, or even try to implement someone else's. Badly implemented encryption could be worse than having none, as the false sense of security can lead you to take your eye off the ball.

Don't write your own crypto. Don't invent your own security protocols. Unless you are a cryptographic expert with years of experience, if you try inventing your own encoding or elaborate cryptographic protections, you will get it wrong. And even if you are a cryptographic expert, you may still get it wrong. Reinventing the wheel in many cases is often just a waste of time, but when it comes to security it can be outright dangerous.

10. Conway's law and system design

Melwin Conway's law:

Any organization that design a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure.

Eric S. Raymond summarized:

If you have four groups working on a compiler, you'll get a 4-pass compiler.

11. Microservices at scale

Systems that just act slow are much harder to deal with than systems that just fail fast. In a distributed system, latency kills.

A planned outage is much easier to deal with than an unplanned one.

At scale, even if you buy the best kit, the most expensive hardware, you cannot avoid the fact that things can and will fail.

Scaling

The architecture that get you started may not be the architecture that keeps you going when your system has to handle very different volumes of load ^[11]. You should "design for ~10x growth, but plan to rewrite before ~100x." You need to do something pretty radical to support the next level of growth.

There is a danger that people will see the need to rearchitect when certain scaling thresholds are reached as a reason to build for massive scale from beginning. This can be disastrous. At the start of a new project, we often don't know exactly what we want to build, nor do we know if it will be successful. We need to be able to rapidly experiment, and understand what capabilities we need to build. If we tried building for massive scale up front, we'd end up front-loading a huge amount of work to prepare for load that may never come, while diverting effort away from more important activities, like understanding if anyone will want to actually use our product.

The need to change our systems to deal with scale isn't a sign of failure. It is a sign of success.

CAP theorem

In a distributed system, we have three things we can trade off against each other: consistency, availability, and partition tolerance. Specifically, the theorem tells us that we get to keep two in a failure mode.

Consistency is the system characteristic by which I will get the same answer if I go to multiple nodes.

Availability means that every request receives a response.

Partition tolerance is the system's ability to handle the fact that communication between its parts is sometimes impossible.

If our system has no partition tolerance, it can't run over a network. In other words, it needs to be a single process operating locally. CA (Consistency and Availability) systems don't exist in distributed systems.

Getting multinode consistency right is so hard that I would strongly, strongly suggest that if you need it, don't try to invent it yourself. Instead, pick a data store or lock service that offers these characteristics.

References

How Google Works - An inspirational journey

Sun, 03 Feb 2019 00:00:00 GMT

This book have a lot of "ah", "oh", which I cannot do anything else but agree. So I will mostly quote statements from it that would best demonstrate my thoughts.

How Google Works by Eric Schmidt & Jonathan Rosenberg, with Alan Eagle. Image source: howgoogleworks.net

Convention

Regular texts are my words, which is not many. Italic texts and blockquotes are citations from the book. Some of them are cited by the authors.

How Google Works

The only way to succeed in business in the twenty-first century is to continually create great products, and the only way to do that is to attract smart creatives and put them in an environment where they can succeed at scale.

The smart creative. (Illustration in the book)

We have long felt that the start-up model, with small, autonomous teams located in one office led by passionate founders, is the most effective way to achieve remarkable new things (or fail quickly in the effort).

Dependence on process, no matter how well intentioned, squelches start-ups and the start-up spirit.

Introduction

In the old world, you devoted 30 percent of your time to building a great service and 70 percent of your time to shouting about it. In the new world, that inverts.

Product development has become a faster, more flexible process, where radically better products don't stand on the shoulders of giants, but on the shoulders of lots of iterations. The basis for success then, and for continual product excellence, is speed.

If you can't tell someone how to think, then you have to learn to manage the environment where they think. And make it a place where they want to come every day.

Hire enough great people, and the resulting intellectual mixture will inevitably combust into creativity and success.

Culture

Believe your own slogans

Believe your own slogans. (Illustration in the book)

Google's culture focuses on people.

Smart creatives, though, place culture at the top of the list. To be effective, they need to care about the place they work. This is why, when starting a new company or initiative, culture is the most important thing to consider.

Once established, company culture is very difficult to change, because early on in a company's life a self-selection tendency sets in.

At Google "it doesn't matter who you are, just what you do."

You want to invest in the people who are going to do what they think is right, whether or not you give them permission.

Dissent must be an obligation, not an option.

There is no perfect organizational design, don't try to find one.

About knaves:

The character of a company is the sum of the characters of its people, so if you strive for a company of sterling character, that is the standard you must set for your employees. There is no room for knaves. And generally, in our experience, one a knave, always a knave. (Tom Peters: "There is no such thing as a minor lapse of integrity.")

There are tipping points in knave density. It approaches a critical mass - which is smaller than you think - and people start to believe they need to be knave-like to succeed, which only exacerbates the problem. Smart creatives may have a lot of good traits, but they aren't saints, so it's important to watch your knave quotient.

About work-life balance:

For many people, work is an important part of life, not something to be separated.

Give your smart creatives control, and they will usually make their own best decisions about how to balance their lives.

We encourage people to take real vacations, although not to promote "work-life balance." If someone is so critical to the company's success that he believes he can't unplug for a week or two without things crashing down, then there is a larger problem that must be addressed.

Strategy

Businesses should be built on a strong set of strategic principles, not an MBA-style plan that’s bound to fail.

Your plan is wrong. (Illustration in the book)

A technical insight is a new way of applying technology or design that either drives down the cost or increases the functions and usability of the product by a significant factor. The result is something that is better than the competition in a fundamental way. The improvement is often obvious; it doesn't take a lot of marketing for customers to figure out that this product is different from everything else.

^ I like that approach.

Most of Google's successful products have been based on strong technical insights, while most of the less successful ones lacked them.

Giving the customer what he wants is less important than giving him what he doesn't yet know he wants.

About competition:

Don't follow competition.

If you focus on your competition, you will never deliver anything truly innovative. While you and your competitors are busy fighting over fractions of a market-share point, someone else who doesn't care will come in and build a new platform that completely changes the game.

In general I think there's a tendency for people to think about the things that exist. Our job is to think of the thing you haven't though of yet that you really need.

As Nietzche wrote in "Thus Spake Zarathustra": "You must be proud of your enemy; then your enemy's successes are also your successes." Be proud of your competitors. Just don't follow them.

Talent

Hiring is the most important thing you do.

We want to hire the best minds available, because we believe there is a big difference between people who are great and those who are good, and we will do everything we can to separate the two.

A workforce of great people not only does great work, it attracts more great people. The best workers are like a herd: They tend to follow each other. Get a few of them, and you're guaranteed that a bunch more will follow.

Favoring specialization over intelligence is exactly wrong, especially in high tech.

When considering candidates for a role, favor the ones with a track record of learning new things over the ones with a track record in that particular role.

Hire learning animals. (Illustration in the book)

In a peer-based hiring process, the emphasis is on people, not organization. The smart creatives matter more than the role; the company matters more than the manager.

The urgency of the role isn't sufficiently important to compromise quality in hiring. In the inevitable showdown between speed and quality, quality must prevail.

We would rather our hiring process generate more false negatives (people we should have hired but didn't) than false positives (we shouldn't have hired, but did).

Hire them not for the knowledge they possess, but for the things they don't yet know.

If you think your abilities are fixed, you'll set for yourself what she calls "performance goals" to maintain that self-image, but if you have a growth mindset, you'll set "learning goals" - goals that'll drive you to take risks without worrying so much about how, for example, a dumb question or a wrong answer will make you look. You won't care because you're a learning animal, and in the long run you'll learn more and scale greater heights.

About passion:

Passionate people don't wear their passion on their sleeves; they have it in their hearts. They live it.

If someone is truly passionate about something, they'll do it for a long time even if they aren't at first successful. Failure is often part of the deal.

About recruitment:

Recruiting is everyone's job.

Recruiters can manage the process, but everyone should be recruited for recruiting.

The interview is where you truly learn about a person - it is far more important than the résumé.

About promotion:

Promotions have a company-wide impact, so they are too important to be left in the hands of individual managers.

Google's hiring dos and don'ts

Hire people who are smarter and more knowledgeable than you are.
Don't hire people you can't learn from or be challenged by.

Hire people who will add value to the product and our culture.
Don't hire people who won't contribute well to both.

Hire people who will get things done.
Don't hire people who just think about problems.

Hire people who are enthusiastic self-motivated, and passionate.
Don't hire people who just want a job.

Hire people who inspire and work well with others.
Don't hire people who prefer to work alone.

Hire people who will grow with your team and with the company.
Don't hire people will narrow skill sets or interests.

Hire people who are well rounded, with unique interests and talents.
Don't hire people who only live to work.

Hire people who are ethical and who communicate openly.
Don't hire people who are political or manipulative.

Hire only when you've found a great candidate.
Don't settle for anything else.

Decisions

The process by which you reach the decision, the timing of when you reach it, and the way it is implemented are just as important as the decision itself.

We don't seek to convince bay saying "I think." We convince bay saying "Let me show you."

Decide with data. (Illustration in the book)

Most conference room at Google have two projectors. One of them is for videoconferencing with other offices or for projecting meeting notes. The other is for data.

Slides should not be used to run a meeting or argue a point. They should just contain the data, so that everyone has the same facts. If the data is wrong or not relevant, you can't fix it with fancy slides.

The right decision is the best decision, not the lowest common denominator decision upon which everyone agrees. And it's not always your solution.

About consensus and dissent:

To achieve true consensus, you need dissent.

If everyone is thinking alike, then somebody isn't thinking.

The job is to make sure everyone's voice is heard, regardless of their functional role.

If someone truly have nothing to say, in which case maybe they shouldn't be at the meeting in the first place.

Do your best to surface all potential dissent early in the process; there is a natural (and valid) bias toward rejecting dissent the later it surfaces in the decision-making process.

Ensure that everyone who was involved does one of two things: disagree but commit, or escalate publicly.

About meeting:

Meeting should have a single decision-maker/owner.

Even if a meeting is not a decision-making meeting - for example it's designed to share information or brainstorm solutions - it should have a clear owner.

The decision-maker should be hands on. He or she should call the meeting, ensure that the content is good, set the objectives, determine the participants, and share the agenda (if possible) at least twenty-four hours in advance. After the meeting, the decision-make (and no one else) should summarize decisions taken and action items by email to at least every participant - as well as any others who need to know - within forty-eight hours.

Meetings should be easy to kill.

Meetings should be manageable in size. No more than eight people, ten at stretch. Everyone in the room should be able to give their input. If more people need to know the result of the meeting, make sure you have a process for communicating it rather than bringing them in as observers, which lowers the quality of the meeting and people's ability to talk openly.

Attendance at the meeting is not a badge of importance. If you aren't needed, leave, or better yet, excuse yourself ahead of time. Fewer people is almost always better.

Timekeeping matters. Begin meetings on time. End them on time. Leave enough time at the end to summarize findings and action items.

If you attend a meeting, attend the meeting. Multitasking doesn't work. If you are in a meeting and using your laptop or phone for something not related to the meeting, it's obvious your time is better spent elsewhere. Everyone attending a meeting should focus on the meeting, not other work. And if people have so many meetings that they can't got work done, then there is a simple solution: Prioritize and go to fewer meetings.

When you are considering something that is fundamental to the existence of the company, you should meet everyday.

About action:

If you're not sure if a course of action is right, the best thing you can do is try it out and then correct course.

Exhibit to bias for action, to cut off debate and analysis that is no longer valuable, and start moving the team to rally around the decision. But don't be a slave to a sense of urgency. Maintain flexibility until the last possible moment.

Communications

Default to open.

Default to open. (Illustration in the book)

A parsimonious approach to spreading information may have been successful when people were hired to work, in the Internet Century you hire people to think.

We trust our employees with all sorts of vital information, and they honor that trust.

No matter what a person's job is, they should be encouraged to have opinions about the business, industry, customers and partners, and different cultures.

It must be safe to tell the truth

Good news will be just as good tomorrow, but bad news will be worse. That's why you must make it safe to ask the tough questions and to tell the truth at all times, even when the truth hurts.

Know the details

If someone is in charge of a business and can't rattle off the key issues she faces in a matter of ten seconds, then she's not up to the job. A hands-off approach to leadership doesn't cut it anymore. You need to know the details.

Review yourself

Make sure you would work for yourself. If you are so bad as a manager that you as a worker would hate working for you, then you have some work to do. The best tool we have found for this is the self-review: At least once per year, write a review of your own performance, then read it and see if you would work for you. And then, share it with the people who do in fact work for you.

Others

It's easier to summarize something in black and white vs in shades of gray.

To be a thought leader, you have to have a thought.

When you start a new position, for the first three weeks don't do anything. Listen to people, understand their issues and priorities, get to know and care about them, and earn their trust. So in fact, you are doing something: You are establishing a healthy relationship.

Email wisdom

Respond quickly.

When writing an email, every word matters, and useless prose doesn't. Be crisp in your delivery.

Clean out your inbox constantly.

Handle email in LIFO order (Last In First Out). Sometimes the older stuff gets taken care of by someone else.

When you get a note with useful information, consider who else would find it useful.

When you use the bcc (blind copy) feature, ask yourself why.

Don't yell. If you need to yell, do it in person. It is FAR TOO EASY to do it electronically.

Make it easy to follow up on requests.

Help your future self search for stuff.

Innovation

What is innovation?

Innovation: It's the next big thing.

For something to be innovative it needs to offer new functionality, but it also has to be surprising. If your customers are asking for it, you aren't being innovative when you give them what they want; you are just being responsive. That's a good thing, but it's not innovative.

Think 10X, not 10%. Global scale is available to just about everyone. But too many people are stuck in the old, limited mindset.

Think 10X, not 10 percent. (Illustration in the book)

Perhaps it's human nature, or just corporate nature, but most people tend to think incrementally rather than transformationally or galactically.

We aren't trying to improve on an existing way of doing something, rather we want to start over.

About building product

New ideas are never perfect right out of the chute, and you don't have time to wait until they get there. Create a product, ship it, see how it does, design and implement improvements, and push it back out. Ship and iterate. The companies that are the fastest at this process will win.

Iterate very quickly and to establish metrics that help you judge if, with each iteration, you are getting closer to success.

Focus on the user...

User trust is just as important as dollars, euros, pounds, yen, or any other currency. Product excellence is the only way for a company to be consistently successful, so our prime directive when it comes to product strategy is to focus on the user.

Users are more empowered than ever, and won't tolerate crummy products.

We will always do what's right for the user, and we trust that our smart creatives will figure out how to make money from it. It could take a while, so sticking it out requires a lot of confidence.

About limitations

When you want to spur innovation, the worst thing you can do is overfund it.

The human race built most nobly when limitations were greatest.

About people

Innovative people do not need to be told to do it, they need to be allowed to do it. In other words, innovation has to evolve organically.

If you want to hire great people and have them stay working for you, you have to let them make a lot of decisions, and you have to be run by ideas, not hierarchy. The best ideas have to win, otherwise good people don't stay.

Fail well

Any failed project should yield valuable technical, user, and market insights that can help inform the next effort.

It’s very hard to completely fail when you think big, since you can always salvage something of value from a project with big goals.

It helps to see failure as a road and not a wall.

Good judgment comes from experience; experience comes from bad judgment.

Management's job is not to mitigate risks or prevent failures, but to create an environment resilient enough to take on those risks and tolerate the inevitable missteps.

Some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty.

Conclusion

Imagine the unimaginable.

Most companies fail because they get too comfortable doing what they have always done, making only incremental changes. And that is especially fatal today, when technology-driven change is rampant. So the question to ask isn't what will be true, but what could be true.

Any company that wants to build a new venture needs to ask itself the question: Do I go to the smart creatives, or find a way to get them to come to me?

Big problems are information problems

With enough data and the ability to crunch it, virtually any challenge facing humanity today can be solved.

Infinite data and infinite computing power create an amazing playground for the world's smart creatives to solve big problems.

The role of government

If data empirically show that a new way of doing things is better than the old way, then the role of government isn't to prevent change but to allow the disruption to occur.

The next smart creative

Given that no business wins forever, it is inevitable.

The next smart creative. (Illustration in the book)

50 Ideas ^[1]

Just summary the highlights:

What’s different now?

Three converging technology platforms - Internet, mobile, and cloud - are transforming virtually every business sector.

This transformation is happening at an unprecedented speed, and it is accelerating.

The tools of innovation have been democratized.

The balance of power has shifted from companies to customers, and expectations are skyrocketing.

Individuals and small teams can have a huge impact.

Product people are more valuable than business people.

Most companies today are designed and run to minimize risk, not maximize speed.

The only way for businesses to consistently succeed is to attract the best smart creatives and create an environment where they can thrive at scale.

Company culture

Define your culture early.

Build around small teams.

Keep them crowded.

Working from home kills innovation.

Listen to the best ideas, not the hippos. (A hippo is the highest paid person’s opinion)

Organize the company around the people whose impact is the highest.

Do all re-orgs in a day.

Exile knaves but fight for divas.

Overwork people in a good way.

Cultivate fun, even if (especially if) it comes at management’s expense.

Smart strategy, built for long-term success

Businesses should be built on a strong set of strategic principles, not an MBA-style plan.

Superior products start with unique technical insights.

Optimize for growth.

Know your competition, but don't copy it.

Ask the hardest questions.

Hiring

Hiring is the most important thing you do.

Interviewing is the most important skill you can develop.

Hire learning animals, not specialists.

Check your biases at the door.

Make hiring and promotion decisions by committee, based on data.

Reward top performers disproportionately.

Force the best people to rotate.

Making decision

Consensus isn't about getting everyone to agree; it’s about making the best decision for the company and getting everyone to rally about it.

Make all decisions with data.

For the most important decisions, meet every day.

You’re both right.

Every meeting needs an owner.

Everyone needs a coach.

Communication

Default to open.

Be an effective router.

Start conversations. A leader’s job isn't to hoard information, it is to route it as quickly and efficiently as possible.

Repetition doesn't spoil the prayer. When in doubt, over-communicate.

Value relationships over process and hierarchy.

Innovation

The CEO should be the CIO (Chief Innovation Officer). The CIO position usually fails because it doesn't have enough power to create an innovative culture and environment. The CEO is the only person with this power.

Think 10X, not 10%.

Empower smart creatives over managers.

Set unattainable goals and share them widely.

Optimize for speed.

Fail well.

Imagine the unimaginable.

We are technology optimists.

2004 Founders’ IPO Letter ^[2]

Google is not a conventional company.

About public ownership

The standard structure of public ownership may jeopardize the independence and focused objectivity that have been most important in Google’s past success and that we consider most fundamental for its future.

As a private company, we have concentrated on the long term, and this has served us well. As a public company, we will do the same.

In the transition to public ownership, we have set up a corporate structure that will make it harder for outside parties to take over or influence Google. This structure will also make it easier for our management team to follow the long term, innovative approach emphasized earlier.

New investors will fully share in Google’s long term economic future but will have little ability to influence its strategic decisions through their voting rights.

About short and long term

Our goal is to develop services that significantly improve the lives of as many people as possible. In pursuing this goal, we may do things that we believe have a positive impact on the world, even if the near term financial returns are not obvious.

If opportunities arise that might cause us to sacrifice short term results but are in the best long term interest of our shareholders, we will take those opportunities.

We will not shy away from high-risk, high-reward projects because of short term earnings pressure.

We will optimize for the long term rather than trying to produce smooth earnings for each quarter.

A management team distracted by a series of short term targets is as pointless as a dieter stepping on a scale every half hour.

Serving our end users is at the heart of what we do and remains our number one priority.

Google's Larry Page on why moon shots matter ^[3]

Thousand-percent improvement requires rethinking problems entirely, exploring the edges of what's technically possible, and having a lot more fun in the process.

If you're not doing some things that are crazy, then you're doing the wrong things.

There are all these opportunities to make people’s lives better. Tech companies are attacking 1 percent of them. That leaves 99 percent virgin territory.

References

I highly recommend that you read these articles in detail. There are great information in them related to the book.

Sapiens by Harari - Enlightened and interesting viewpoint about history

Tue, 22 Jan 2019 00:00:00 GMT

Sapiens by Harari draws a big and beautiful picture about our history. It tells us how small and powerless we are as individuals by the flow of time.

Sapiens - A Brief History of Humankind, by Yuval Noah Harari. Image source: James Clear

Advancement

This book states a new and open view about our agricultural revolution. It discusses benefits of individuals and species. Sometimes, advantage of individuals does not mean advantage of species, and vice versa. Seeking for early advantages seems first beneficial. But after a long time (years or decades for individuals, many generations for species), those advantages would become huge disadvantages. Traps were activated, situation was accepted. There was no way to come back. That was a comfortable, easy-going and dangerous trap.

Agricultural revolution, the biggest trap in history. Image source: Stravaganza

Lesson learned

Before starting an improvement, as you may it is beneficial, try to think in long term. Whether it still be beneficial after many improvement round or not, or it will change into other forms? Usually re-evaluate first approach and solution, alter it, update it, look back, look forward. Never accept situation as it is. In many cases, acceptance of current situation, procrastination and lack of re-evaluation led to disasters. With a rational mind, we human should carefully think about easy movements in long term, for avoiding paying a huge price in the future.

Organization

All humans have the same origin. Nation and ethnicity difference are just imaginations. There are many things that only exist in our mind: human right, law, company and money. Their roles are to make large groups of people pursuing common targets, instead of fighting each other. Need to note that in some cases, such "common" target is not for majority of people, but only benefit a small elite, minority group. Humans are different from other animals that we can form and organize in large communities. After millenniums, we have religion, culture, governments and banks. What make us stronger and evolve is the ability to live, work and support each other.

Myths

There are some myths - which I mean unreal - should not publicly confirm or deny, even though you may know the truth. Keeping them secret and lie to the public would more beneficial for all of us. Religions, human rights and law are some of which Harari stated.

Our society is built on beliefs: God, honor, nation. People are persuaded to believe that rules come from these sources, not from other people. The purpose is quite clear: to make majority of people fit into structured societies. This method applied in many aspects of life: education, media, news, and lifestyle. The common belief method was made to secure and maintain society orders. In turn, these society orders enforce and consolidate its people's mind.

A "real" natural rule (for example: gravity) never collapses. But an "imagined" natural rule (for example: social orders) is more vulnerable and easier to be replaced. People fight each other for these "imagined" rules, and discuss in peace the "real" ones.

There is no God, but don't tell that to my servant, lest he murder me at night. - Voltaire

Image source: Fewer Lacunae

Myths in economics

This idea also applies in economics. Merchandisers make you think in the way that most benefit them, not you. They use advertisement, social media and marketing tools to do this. What you think may come from someone's mind and for their interest. Not only that, they also tried and succeeded making you think that you though from inside yourself. They made you think that you are the supreme controller of your mind, your decision and your life. But you aren't. They create societies that most financial benefit them. Societies that buy the most products and services from them; and give them not only money, but also labor, page view and personal data.

Image source: Pinterest

Benefit-oriented

Our belief is for satisfying our needs and making us feel comfortable. We believe in things that we want to believe and can get benefit from. We do not believe in things just because of the way they are.

There is a close relation between politics and economy. Between government, army, war, revolution and capital, money, job, food. People start a revolution or declare war when their government or companies (or both) do not satisfy their needs, or touch their money/food. People choose peace not because ethics or they love peace. Nowadays, people choose peace because cost of war is high and profit of winning is low.

Contradiction

Freedom and equality are two accepted basic human rights. But not many people know that these two rights contradicts each other. Equality is guaranteed by reducing freedom of more successful people. While maximizing freedom of everybody will bring inequality to unlucky ones. Politics history from 1789 to present full of attempts to solve this problem. And it seems not solved yet.

Image source: Flickr

However, contradictions have positive points. They are motivation of improvement and source of development. They encourage people to continue thinking, re-evaluating and criticizing. When something become stable, other questions will arise. A stable mind is the source of degeneration.

If you want to understand a person or country, looking at and trying to understand their internal contradictions is a good way.

Unification

Human history is a flow of unifications and separations. But starting from industrial era, unification has become the mainstream direction. Using religions, politics, and money, countries are affecting each other more than ever before. A "pure" original civilization seems no longer exist. So is "definitely" independent country. Despite of many countries are claiming so. Nowadays, there is no way to eliminate these effects without an isolation and collapse.

Notes from "Hints for Computer System Design" by Butler W. Lampson

Wed, 14 Nov 2018 00:00:00 GMT

Disclaimer: This post is a reflection of my mind after reading this paper, it is not a summary or review, and should not be used for reference. But for fun is ok. Besides what mentioned here, this paper has a lot of other wonderful ideas.

Designing a computer system is very different from designing an algorithm.

The overall idea that I get is "simplify". Simplicity ensures functionality and enhance performance.

Defining scope of each sub-system and their interface are the most important - and most difficult - part of system design. Try to keep it simple and minimal, and don't generalize.

Each interface is a small programming language: it defines a set of objects and the operations that can be used to manipulate the objects.

The well-known KISS principle (stands for Keep It Simple, Stupid) demonstrates this idea.

A simple system is faster, more accurate, and has easier-to-predict behaviors comparing to a general one. Usually, general means slower. And users have to pay for extra cost, although they do not need those extra power. However, a fast and general solution is always the best, if you can find it.

If complicated functionalities are needed, try to delegate to client. Your system should provide basic functions, with wide range of usage that user can create. Rather than trying to cover all the things by yourself and make your system heavy and slow, potentially introduce many bugs, and hard to maintain.

Do one thing at a time, and do it well.

With hard problems, divide and conquer maybe a good approach. Transform big problem into smaller and simpler ones. Handle normal and worst case separately may save time, instead of solving them together (over-generalize). If a simple and general solution exists, choose it.

If a straightforward, brute-force solution exists, and its speed is acceptable comparing to an optimized version, or input data is relatively small, use the brute-force one.

Besides of main idea of simplify, this paper also notice about safety. System designer should avoid choosing a terrible way, rather than finding an optimum. They also need to have clear vision among sub-systems.

It also gives some advises on improving performance, some of them I feel interesting (the others I don't understand):

Caching. Result of time-consuming operations should be cached. Be aware of cache invalidation.
Use hints. Time can be saved, and calculation can be executed before it is clearly stated. Note that hints can be wrong, and should check against "truths". But checking correctness in many cases are faster than finding answer. Hints can be found by:
- Guessing
- Occurred events
- Statistical/historical data
Compute heavy tasks in background.

Some ideas to enhance fault-tolerance of a system:

Use appended logs. Current state can be re-produced from a series of append-only modification logs. Logs should be well-formatted.
Use transactions.
Operations should be idempotent.

Examples are quite old (1970s, 1980s) and maybe unfamiliar with current computing. However, basic concepts live long.

Plato and a Platypus Walk into a Bar: Funny, easy to catch philosophy ideas

Thu, 17 May 2018 00:00:00 GMT

For Asian readers, those jokes may seem not culture-fit. They would be more relevant to Western society. I did not get the point of some jokes. But the good point is Asian readers can learn philosophy and Western culture at the same time. However, knowing some basic philosophy ideas before reading would be better than knowing nothing. If you do not know anything about philosophy before, I suggest Sophie’s World.

Plato and a Platypus Walk into a Bar. Source: Kobo.com

In the language perspective, we have different understanding while reading the same word in different languages. Our brain's reactions are not the same while reading a word in one language, to the translated version of that word in another one. While reading this book, I realized that language is an important part of philosophy studying. Wanting to know more about philosophy, I will need to proficient at academic English. Wanting to learn more about some philosophers, I will have to know German. Using Vietnamese for these purposes is easy for beginning steps. But to go further, I will face a wall which is hard to overcome. And language proficiency is the key to go to next taller walls.

The Three-Body Problem - beautiful imagination about ourselves

Mon, 14 May 2018 00:00:00 GMT

As material for story telling, this book uses Eastern and Western cultures. The story is thrilling, attractive from beginning to end.

Via thoughts of some individuals, this book represents breaths of a country. Via breaths of countries, it represents a civilization. Via rise and fall of civilizations, it shines and guides human's thoughts. Human's thoughts then inherit and evolve, as individual and as a whole, to reform destiny of worlds.

The Three-Body Problem. Image source: Medium

There was questions in my mind: What we can learn from the past? What we can learn from the fallen and existing civilizations? What we can learn from our current situation? Based on what we learnt, is it possible to know what we should do? Let's put our thoughts above all things, above our existence, above the world that we are in. Then what we see and imagine can give us some helps, and then to our world.

The Three-Body Problem strengthen love for science. It beautify the endless curiosity of seeking secrets. It shows painful parts of human being, from physical to psychological, from science to love and life. It looks back to the past and question about present. It looks to the universe and question about our existence. In the end, I believe it questions about our direction.

The story tells that science is motivation of civilization evolution. The curiosity to try, fail and explore the planet we are living and the universe we are a part of, should be kept in our generation and transferred to all our descendants. People can die, civilizations can fall. But scientific and historical knowledge must be kept, then inherited, spread and evolved. If we stop our curious mind and pleased with what we knew, what we are, we will let ourselves corrupted and terminated, no need other forces coming here to destroy us.

A must read for science(-fiction) lovers.

Overview of blockchain and bitcoin

Thu, 04 Jan 2018 00:00:00 GMT

Disclaimer

Articles in this series use contents from many resources in the internet, whose roots are hard to trace. Majority of ideas are from secondary research.

I also do not provide any financial information, such as which cryptocurrency to invest, when to buy or sell, or price prediction. I am only taking a look on technology and application viewpoint.

First, let's start with what blockchain and bitcoin are.

What is it

Blockchain is a technology. It is proposed by an anonymous person/group named Satoshi Nakamoto.

Bitcoin is an application of blockchain, among many others.

Bitcoin's purpose is to improve current payment system. It is decentralized, persistence, anonymous, auditable...

Payment process: current vs bitcoin

When using bitcoin, you do not need an intermediate organization to validate your account and transfer money. Everything is done inside itself. Bitcoin system is incorporated and self-operated by its participants. Everything is ready to work after you join.

To achieve these goals, bitcoin has employed some techniques.

Architecture

Blockchain's stacked architecture

At the bottom of a blockchain architecture is blockchain. It acts like a data structure and works as a database. This database is stored in every full nodes in bitcoin system. On top of the blockchain is bitcoin protocol, which is bitcoin core project. With that protocol, coin (bitcoin, specifically) is created and transferred.

Difference between token and coin:

Tokens are used to bind physical to digital world. Token can bind money (in case of coin), a company's share, a physical product, a song, an idea... anything.

Coin (any kind of it: bitcoin, ether, litecoin...) is a special token, which is used like money.

On the top of bitcoin are applications like wallets, exchange platform, merchants accepting bitcoin... We usually interact with applications at this level while not interacting with lower stuffs.

There are many other types of coin systems (altcoins), which also have similar architecture like bitcoin.

Ethereum has another story, with different philosophy, design and algorithm. Ethereum is platform, Ether is cryptocurrency developed based on that platform. It has many useful application which I will research about.

That is overall architecture. Let's go to detailed design of bitcoin.

Design

Coin

Any digital currency must solve double spending problem.

Double spending is when a digital currency is replicated and spent more than once.

This problem becomes harder on a decentralized environment, without any central authority. To avoid it, every smallest piece of coins are traced from their creation, through every transaction, to recent status. Any coin is authenticated before spending.

Coin flow

After joining this flow, a coin have to be an output of a transaction before becoming input of another one. Total number of output is always less than or equal to number of input. Coin can just be transferred from transaction to transaction, cannot be validly replicated. Origin of every coins are traceable. Mining is the only way to create coins from nothing.

In case there are many transactions using the same output, the first transaction with earliest timestamp will take effect, others will be discarded.

Many output is when someone transfer money to more than one address.

Many input is when amount required for a transaction is not enough and need to be gathered from many transactions, of the same source address.

Unspent transaction output (UTXO) is output amount which is not spent in any transaction. In other words, that amount is not used as input of any transaction.

Transaction fee is the difference between total input and total output. Which is paid to miners for validating a transaction.

Transaction

Every transaction includes sender address, receiver address, bitcoin amount (input-output), signature of sender, and other ton of things. They are chained together by input-output mechanism. Output of previous transaction is input of next one. If someone modifies amount of a transaction, he/she must modify all transactions subsequent to that one, every one of them. And must somehow make whole network accept that modification. This is theoretical impossible.

Bitcoin transaction

Every address (address is a public key) has a private key to prove ownership of that address. Sender provides transaction with that private key to authorize a transaction. This private key is used to sign information attached with transaction. If owner lost that private key, or it is stolen, everything stored in that address will be lost forever, non-refundable.

Signed data

Not only addresses (public keys), and transfer amount, private key is used to sign many information related to transaction: previous transaction id, output index number, amount... If someone modify a transaction, he/she not only need to modify all subsequent transactions, but also need private key of everybody receiving that coin. Getting private key of that large amount of people, who is anonymous, is extremely hard, needs huge effort, and somehow impossible.

Coinbase transaction is the first transaction in all blocks (transaction 0). It is the only place where bitcoins are created from nothing, as reward for validating transactions, putting them into blocks, and solving hard hashing problems. Coinbase transaction also includes fees of all transactions that are included in this block.

Rewarded bitcoins starting from 50 bitcoins each block in 2009, halved every 4 years. This will limit total number of bitcoins to 21 millions.

Block

Block is where transactions are grouped, sealed and stored. Transactions grouped together by a mechanism called Merkle tree. Computer will hash all transactions in a block, to find Merkle root. Merkle root hash is stored in block header.

Transactions hashed in a Merkle tree

If a transaction cannot find another one to form a pair, it is hashed with itself.

Hash transactions

Merkle root is the final hash, after hashing every transactions in a block.

To save storage, some blocks may not store all transactions, but keep only intermediate hashed results. Reducing storage by skipping transactions like this will decrease security of whole system. Because these lightweight node cannot verify transactions and therefore vulnerable to attacks.

After pruning transactions 0-2 from block

If any transaction in block is altered, Merkel root must be updated. If Merkle root of a block is updated, that block's data is updated. Hence that block must be re-hashed, which process we call proof-of-work.

Proof-of-work

After having all required data to store in block header, block is ready for calculating block hash.

Calculating block hash from block header data is super easy, a regular computer can finish that job in less than one second. What if everybody can easily rewrite blockchain, modify some blocks, insert invalid transactions, then say that the modified version is the valid one? Process of calculating block hash must be harder, cost huge amount of compute power, which will make brute force attack longer and more costly.

The method used is target threshold. Calculated block hash must be below a pre-defined threshold. This make block hash starts with some zeros. If you look into a block in bitcoin blockchain, you can see block hashes like this:

Block hashes

The hashing process is one-way. Nobody can find original data from hashed result. The only way to check whether one piece of data will hash to a specific string is do hashing. This is brute force. Because data in block header have already specified, one way to hash to some specific string (which are below target threshold), is adding a piece of data. That piece of data is called nonce:

Nonce as proof-of-work

When changing nonce, block header data is changed, hash result will change. The process is: Add a nonce to block data -> hash block -> check if hash result is below target threshold. If so, notify network that a new block is found and built. Otherwise, try a new nonce. Repeat until finding one valid hash result, or get notification from another computer that they found before you.

Block generating and hash calculating is controlled to be about 10 minutes each block. But sometimes computers in network can do that faster or slower. After every 2016 blocks (about 2 weeks), difficulty (target threshold) is adjusted up to 300% harder if the last 2016 blocks are generated faster than 2 weeks; or adjusted down to 75% easier if they are generated longer than 2 weeks. This make proof-of-work always hard enough despite of total compute power. So nobody can invest into power and gain control of bitcoin system.

Chain

After calculating block hash as proof-of-work, blocks are chained together. Every blocks (except the first one) stores previous block's hash in its header. If any transaction or block is changed, every subsequent blocks must be changed, too. So whole costly proof-of-work hashing process of every dependent blocks must be re-done. This mechanism strengthen blockchain and reinforce confirmation of transactions. If someone want to change a transaction, that person must rewrite blockchain from the block holding that transaction, and must do all hashing process faster than whole honest network combined, to form a longer chain. This is considered extremely hard if attacker does not have majority (51%) compute power.

Chain of blocks

Number of confirmations is number of blocks after a transaction. The more confirmation, the more secure that transaction is. With small transactions like buying coffee, merchant only require 1 confirmation after bitcoin is transferred, to make it fast and convenience. But with larger transactions like buying a phone, merchant may ask for 6 confirmations. More confirmations, harder to rewrite blockchain and undo bitcoin transfer.

Blockchain will collapse if someone or group control 51% compute power of whole system. With that compute power, that person/group can rewrite blockchain data and insert any transaction that benefit themselves, so damage the society.

Consensus rule

What if there are many chains coexist at one time? (This usually happens)

Consensus rule: the longest chain is the honest one.

If someone want to cheat system, that person must produce a valid (proof-of-work) chain longer than the chain that all honest people are creating, at faster speed. To do so, that person must control 51% computing power. This is called 51% attack. Currently, there is no computer system (including governments) has such computing power.

But we also need to know that the 5 largest mining organizations own more than 75% of total mining capacity; and 58% of hashing power is from China. Therefore, bitcoin mining pools are monitored closely by community.

Bitcoin system is created to be more profit when honestly generating blocks than cheating. Generating blocks earns bitcoin rewards, which is better than use compute power to start a race with all honest computers. But in the future, when bitcoin reward decreases (halved every 4 years), or bitcoin to USD price decreases, while number of miners are huge, then nobody can guarantee kindness will win.

Because of those design principals, number of transactions growth and bitcoin price booming, bitcoin system has just uncovered a lot of limitations.

Limitations

1. Time

Bitcoin blocks size are limited to 1MB. This rule limits number of transactions can be stored in each block. Blocks are added to blockchain every 10 minutes. So this allows only 7 transactions added to bitcoin blockchain every second.

Number of bitcoin transactions per second, compared to Visa

But that's not the only story about speed. Some transactions, like transfer bitcoin for buying a phone, requires 6 confirmations to be valid. 6 confirmations requirement means that after transaction is added to a block, confirmed, broadcasted to network, there must be at least 6 subsequent blocks added to blockchain after that block. This requirement restricts possibility that an attacker can change transaction after receiving product. The more confirmations, the more secure (hard to alter) transaction is. Now maybe you see the problem. To get that kind of transaction trustworthy confirmed, buyer must wait at least 60 minutes to buy a phone. But that is the happiest case. When bitcoin price is increasing, if transaction fee buyer added to transaction is not attractive enough, miners would not add that transaction into blocks soon. Then waiting days for the first confirmation is usual. Transferring money, then pay high fee or wait for some days? What do you choose? That maybe not convenience enough for any financing system.

There were some tries to increase block size. The most famous one is Bitcoin Cash, which increased block size from 1MB to 8MB. That was a hard fork. But increasing block size also increase delay in block broadcasting. That's why bitcoin developer team did not agree with the 8MB proposal. Increasing block size can improve transaction handling speed (more transactions stored in blocks), but slow down block broadcasting, leading to multiple branches existing in blockchain at every moment. Then take time to correct, waste many blocks in not-longest chains. Increasing block size is a tradeoff.

Hard fork is is a method for developers to update bitcoin’s software.

Decreasing difficulty of hashing algorithm may increase hashing (in other words: mining, validation, confirmation) speed, but will decrease system's security.

When bitcoin price is increasing nowadays (20 times from beginning of the year), 1MB every 10 minutes is not enough for storing huge amount of transactions. That’s why bitcoin transfers are taking too much time, and expensive.

2. Cost

For those 7 transactions/second, bitcoin is already estimated to use 35 times as much energy as Visa. If you brought bitcoin’s transaction volume up to Visa’s it would be using as much electricity as the rest of the world put together. Because bitcoin system consumes tremendous compute power, billion dollars of electricity and network bandwidth, storage capacity, it becomes not as cheap as planned. Miners want to make their money payback and profitable, in the form of transaction fee (while rewarding bitcoin is halving every 4 years and only equal to 1/4 of the first days). So mining investors are always attracted by high-fee transactions.

Let's look back to the first far days, when transactions only cost a small portion, some percents of a bitcoin. But recently, that "small portion" worth about $20 to $50. Which has not cheap anymore. If I want to transfer a small amount of bitcoin, which worth about $2 to my friend, and do not accept to pay tens of dollars for fee, my transaction would wait for days in prioritized-by-fee queue to be confirmed. My friend has no way to receive that money until that transaction is confirmed, 2 days later.

More people are joining, more transactions are generated. Along with increment of bitcoin price, transaction processing time and cost are increasing too. This makes people harder to do normal financing activities. This is a paradox.

3. Privacy

Bitcoin originally promotes privacy, since it is not possible to know who is behind an address by just reading it. But blockchain system is not transactional private. Values of all transactions and balances are publicly visible. Give anyone an address, he/she can get all transaction in and out of that address from the beginning of time, and that address's balance. If I transferred bitcoin to a friend, then I know his bitcoin address, so I can see all his transactions, and his balance. Solution for this problem is using one-off addresses. But it is not easy for normal people to use such an annoying method. Because lastly, all your coins should me transferred to some few addresses. It does not make sense if today I have 1000 addresses, next year I will have 5000 ones.

Another privacy leaking is user’s transactions can be linked to reveal user’s information. Your financial status can be linked to your identity. If you want to hide, you should hide your payments and income also. But bitcoin is not transactional private. So you should keep your address private (!), or one-off.

Bitcoin employs peer-to-peer network, on top of the internet. Every communication in bitcoin system goes through the internet, which use IP addresses. And IP addresses are linked to real-world addresses, by Internet Service Provider. Knowing an IP, everybody can easily query for location of that IP. Knowing real-world address to personal identity is not a long way. So bitcoin users need to hide IP. How? Using Virtual Private Network, or Tor. I am thinking about teaching my non-tech girl friend using VPN...

But in this real world, many people are making transactions with the same address frequently. I know a lot of my friends, who are software engineers, using only 1 or 2 bitcoin addresses for trading online. After sending them some coins, I can query transaction history of their address, and I know how many money they are having. Asking people to use multiple bitcoin address is just like convincing them to change bank account after each activity. That does not make sense at all.

4. Security

Everybody must keep their private key(s) secret, as secure as ATM card PIN. If they lose those keys to bad people, they will lose all things protected by them. People are relying on single-point encryption, the private keys, rather than a more sophisticated mechanism that might involve.

If people lost their house's door key, worthy properties in their house may gone away. But they can get money back by insurance. If people want to transfer a big amount of money to someone, they have to sign in some pieces of paper. If someone steal your money, they can be caught by police. These methods exists to keep people safe. These methods do not exist in bitcoin world. You have to protect yourself, with all risks acknowledged.

Bitcoin private key is hard/impossible to remember. They are just sequence of meaningless characters like: e9873d79c6d87dc0fb6a... Can you remember it? Mini private keys exist, but they do not help much. Not only impossible to remember, but another problem to private key is how to keep them secret, and able to find when needed. There are several ways: online, offline, printed copy... Online: you must trust the online service. Offline: save it in some hard drive, but must keep that computer virus-free and protect its login password. Printed copy: keeping it more secret than your house's key. Hence, bitcoin keys are harder to keep than physical keys. There are people who printed private key to paper, cut that paper into pieces and kept in multiple bank vaults.

What if you have many one-off addresses (along with many private keys), one for each transaction? How to manage these addresses and private keys, keeping them all secret? This is where wallet software take place. But you have to put all your bitcoins into trust of the software. Not only the software, how about malware, virus, trojan, hardware failure... There were people whose bitcoin accounts drained because their email had been hacked and their password was stolen. They were stunned to have no recourse.

If everybody have to do all above things to protect their anonymity and security, the usability of bitcoin would severely decrease.

5. Usability

Bitcoin is easy for people to use, but very hard for them to be protected. Best practice is a long list. Researchers are working on finding new ways to attack and protect blockchain, while keeping it convenience. In the meantime, people are trading bitcoins, try to keep balance between usability and other benefits.

6. Storage

At the beginning days, bitcoin was expected to only use waste storages, which are very cheap. But recent years while bitcoin price is booming, people are putting their money into bitcoin. Transactions occurs every second. Storage is becoming big and expensive. Moore law has not worked at the same pace like bitcoin's growth. Not only that, in bitcoin world, all miners must download whole chain, which is now 150GB. And it is growing.

Bitcoin blockchain size until January 2018

With 1MB per block for every 10 minutes, bitcoin blockchain uses 52.5 GB a year. Assume that blocks increase 25% annually, so the chain will be 52.5 * 1.25^10 ~ 3TB after 10 years.

Before 2014, bitcoin blockchain size was only 20MB, which is tiny, nearly free, and can be stored in any personal computer. But nowadays, it is big enough to be carefully considered. Total number of storage bitcoin system using would be million times bigger when more people are joining, and the chain is cloning everywhere in the world.

People can use lightweight node to save disk storage, but that will decrease security of system as a whole and make it more vulnerable to attacks. People are recommended to use full node, with full blockchain downloaded to support decentralized system's security. So, bitcoin is not cheap any more.

7. Scalability

Combining other problems of bitcoin, we got this big one. Storage is increasing to infinity, people are waiting days for transaction confirmation if they don't want to put tens of dollars into transaction fee... These roadblocks are slowing down bitcoin on the way to be widely accepted.

There were some proposals. One of which is increasing block size from 1MB to 8MB (as mentioned above). Or periodically removing old transactions, only store balance of non-empty addresses in a distributed database. Sharding hashing process: not all nodes validate all transactions but assign to a subset of nodes. This method will sacrifices security for benefits of scalability. With sharding, bitcoin will be more vulnerable to 51% attack, because now attacker only need to control half of subset instead of whole network.

More proposals are in research and applying to improve bitcoin security and scalability. If you have an idea, please put it at Bitcoin Improvement Proposals. If a proposal is not approved by bitcoin development team, it can be implemented by separate team, which will form a hard fork, then create a new coin "branch": Bitcoin Cash, Bitcoin Gold, Super Bitcoin... Or that separate team will give birth to a fully new cryptocurrency. There are thousands of them: Cryptocurrency Market Capitalizations.

8. Vulnerability

Bitcoin is vulnerable to news. When good news or bad news occur, especially from government, bitcoin price go up or down very quickly. If a government ban bitcoin usage, it will fall. If blockchain technology is in consideration of governments, it will rise. Bitcoin to USD price is dominated by news, not law of supply and demand. And because bitcoin does not represent any physical or real asset, it only exist in the internet and in human's mind, so it is vulnerable.

When price decreases, it is tremendous. Let's see what happened when Mt. Gox exchange went down:

Latest transactions at Mt. Gox

Bitcoin system as a whole is also vulnerable to security attacks. If an attack succeeds, nothing is returned. Everything go to somewhere, but nobody know where it is.

Those limitations must be fixed, if bitcoin want to compete with current financing system, other cryptocurrencies and move to next milestone.

Threats

Bitcoin protocol is not stable yet, its version is now just 0.15.1. The first stable version usually starts at 1. Bitcoin developers say that "Bitcoin is an experimental digital currency..." Bitcoin price is going up nowadays, people are putting their money into it. They should know that in case of security leak, or technological failure, their assets may disappear.

For being able to trade at cryptocurrency exchange platform, people must give bitcoins to them, immediately give up their ownership. They own only a non-contractual IOU (I Owe You). If something unexpected happen, they will lose everything they deposited. IOU does not have any legal constraint. When Mt. Gox was hacked, traders lost $400mil bitcoin (which is several billions now).Mt. Gox just bankrupted, closed. Nobody can found their money back. This year, similar situation happened to Youbit, a South Korean cryptocurrency exchange. They lost 17% total assets after being hacked, and cannot make anything of it returned.

Although blockchain itself has never been hacked successfully, but applications and services around it have. Someone may say that blockchain is secure. It is. But attackers usually intend to hack people and applications, because doing so is easier and cheaper than attacking blockchain. So you must trust services you are using. Chose them very carefully.

Bitcoin wealth distribution

A big minus point to bitcoin community is its wealth distribution. Small number of holders are owning majority of market. This is because great mining rewards paid out in early days to a few people. In that time, constructing a block get 50BTC reward. Very few miners joined the game. Those people at that time, now have assets which worth billions of dollars.

Distribution of bitcoin wealth

Cryptocurrency wealth distribution is not transparent. Owners and their transactions are hidden to public. That is not good for small traders. When whales do something, everybody affected. When these whales cooperate, they can drive direction of market without restrictions.

95% bitcoin are owned by about 4%; 1% control half the entire market

Whales are holders of large amounts of bitcoin.

Real life have similar wealth distribution model but with more control and restrictions. Big shareholders and managers of a company must public their buying/selling deals. In stock market, if someone use internal information for trading; or use many accounts (of one or many people) to manipulate stock price, that person can be arrested. These activities are illegal in real world. But in cryptocurrency exchanges, these illegal-in-real-world methods are not considered carefully, they are still valid, and there is nothing out there to protect small traders. People must aware and protect themselves.

Trade at your own risk.

Protect yourself

Cryptocurrency world is unsafe, but there are several methods that people can use to protect their money. Although these methods are not easy to adapt, but helpful at the moment. Some of them are:

Choose service provider carefully. You totally depend on them. All your assets are in their wallet. If they are hacked, or they intentionally steal your money, or just accidents, you have no way to get your money back. An apologize from service provider is all what you get. Similar to applications and wallet softwares.
Keep only small portion of asset on computer/mobile for daily use. If that computer is hacked, or mobile phone is lost, remaining money still safe elsewhere.
Backup wallet regularly, and encrypt it. If losing computer or getting hard drive failure, data is still recoverable. There was a person who threw hard drive, which stores hundred-million-dollar bitcoin, to garbage. He is trying to get government acceptance to find that drive in city landfills.
Remember to encrypt. Without encryption, anyone has data can get money. Make sure to remember strong, hard-to-remember passwords, even after years without using. If you lose that password, you will lose everything. Someone printed that password, split it, and keep in vaults.
Use cold storage. It is a computer which is reseted to manufacturer configuration, always disconnected from network, and only store sensitive information. You can use it like this: create a transaction on online computer, copy that transaction to a USB, put that USB to cold storage, sign transaction, put USB back to online computer, and proceed transaction.
Use hardware wallet. These devices only have one functionality: signing transactions. They are safe to virus because no software can be installed on them. But keeping them like keeping physical keys.
Have a backup plan for family, in case of death or disability. In real world, law can help. But in cryptocurrency world, without private key, your relatives cannot do anything. Your asset will still there forever. But nobody can access it, forever.
Get updated with your softwares. Newer versions fix security problems. Bitcoin environment is not stable, there are many things to examine, and improvements are announced regularly.
Get updated with news. Cryptocurrency world is vulnerable to news.
Get updated with new new methods and techniques. Bitcoin and blockchain are now researched by many organizations.

Not only bitcoin

Many people think bitcoin is the only application of blockchain, but it is not. Cryptocurrency is one of thousands application that blockchain can bring. Let's take a look, and see what blockchain can do:

The most famous one is smart contract. Every rules are put clearly inside source code. Any modification related to contract is recorded in blockchain, publicly visible and irreversible. Contract is coded, run by computer, so it cannot be cheated (assumes code is correct). That kind of contract forces participants to comply, without intermediate organization - like government, or law. Rules in contract are self-executed, fast, and trustworthy. Examples are:

When a car drive onto a space, it can automatically purchase that parking slot.
A licensed song is delivered to blockchain. If someone want to listen or remix it, they have to pay a specified amount. Payment conditions are coded and executed right after action occurred.
When a package arrived, system will automatically send 1BTC to merchant, and 0.1 BTC to shipper.

Another application is supply chain. Blockchain can be used to track position and status of containers all around the world, using IoT (Internet of Things). Not only containers, it can be used to verify origin of products, checking status of packages, and customs services.

Blockchain can be used in healthcare. Health records are stored in blockchain, accessible everywhere, synchronized. It becomes the single source of truth. It is public, but anonymous. Health data can only accessed by patient and doctor. Anonymous data in blockchain can be used for medical researches.

Blockchain can be used by government for citizen records; or in schools as student scoreboards. It can be used for reputation system of people (for small loans), products, or services.

Data in blockchain is responsive, updated in real time. It is open, but keeps anonymity. It is useful for small startups and large enterprises. The most imaginative mind cannot think what people can do with these data.

Blockchain is not only digital coin, it can be any kind of digital asset, or any digital representation of any physical asset.

Real world maps into blockchain\ Blockchain represents real world

What is next

Blockchain has grown to version 2.0, 3.0. Besides bitcoin, thousands of cryptocurrencies are in market, each solve some specific problems. There are many blockchain frameworks are published to the society, some are in development. Bringing huge number of applications, solving several real-world problems, making our lives easier. Some limitations of blockchain first version have been solved, leading to new era of technology.

Lần đầu thấy trăng - khi cơ hội không đồng đều và cái nhìn về giáo dục

Tue, 14 Nov 2017 00:00:00 GMT

Giọng văn châm biếm, đầy nước mắt và bi ai, sách nói về những người đã vì trường lớp mà mù chữ, phải làm mọi thứ để mưu sinh. Cuộc đời của họ sẽ không như vậy, nếu như chúng ta có một hệ thống giáo dục tốt hơn, nhân văn hơn, và hướng đến từng cá thể hơn.

Tôi chưa thấy được hy vọng hay tia sáng nào trong cuộc đời của những con người trong góc nhỏ này, nơi bi kịch chất chồng và số phận trôi nổi. Những người đức độ, tài năng, đáng được tôn kính nhất thì lại có cuộc sống bi đát nhất. Những kẻ kém tài, làm mọi thủ đoạn đê hèn, thì bản thân và gia đình được sống đầy đủ, được xã hội xum xuê. Sách nói về giáo dục, về số phận thảm thương của nghề giáo, nghề đáng lẽ ra phải được trân trọng và đền đáp xứng đáng, lại phải chịu cảnh sống tận cùng nghèo khó, gia đình bất hạnh… Đó là nghịch lý, cũng là bi kịch cho bất kỳ xã hội nào, đã để điều đó diễn ra.

Người chăm lo học sinh từ giỏi đến yếu nhất, thì hay bị trễ bài, không được giáo viên dạy giỏi. Họ còn phải đối mặt với nguy cơ bị đuổi khỏi ngành vì thành tích của nhà trường, của địa phương. Còn người dạy theo đúng chương trình, chỉ dạy học sinh đã giỏi sẵn giỏi hơn nữa, trong khi bỏ mặc học sinh yếu, sống chết mặc chúng, thì được đi thi, được giải thưởng… Đạo đức nghề giáo được đặt ở đâu trong tình cảnh đó? Tương lai của những học sinh bị bỏ lại sau thành tích của giáo viên sẽ ra sao? Chính bệnh thành tích trong giáo dục đã ép buộc nhà giáo phải trở nên vô lương, và học sinh kém phải ra đường.

Những người truyền dạy kiến thức, và lối sống, đạo đức cho học trò, bị buộc phải gian manh để tồn tại trong ngôi trường mà họ dạy học. Tôi tự hỏi một khi trở nên như thế, đã làm những chuyện như thế, thì họ có còn đủ phẩm chất và năng lực để dạy, để cho học trò tôn trọng và noi theo? Còn những ai không tự biến mình thành một phần của hệ thống, sẽ bị loại ra khỏi hệ thống. Người tốt, chính trực bị loại khỏi ngành giáo dục, trong khi người biết gian xảo thì được đề bạt, để rồi họ lại truyền đạt, đào tạo thế hệ tương lai. Nghề giáo bị buộc trở thành nghề để kiếm tiền, để tồn tại, hơn là nghề cao quý, để ươm những mầm xanh. Làm sao cao quý cho được, khi những người trong ngành còn phải tranh đấu với cuộc sống và tranh đấu với nhau? Rồi họ đang từng ngày từng giờ biến đổi xa rời bản chất của nghề giáo.

Khi mà số phận đen đuổi của học sinh không được cải thiện nhờ giáo dục mà còn bị nền giáo dục đó tước đi cơ hội bước vào xã hội. Rồi những đứa trẻ không biết chữ, dần rơi vào đáy không thấy đường ra. Tôi tự hỏi là vì chúng không có khả năng, hay vì những người dạy chữ cho chúng không có khả năng, hoặc vì những người đã đào tạo ra thầy giáo cho chúng không có khả năng? Vì sao chúng phải trả giá cuộc đời mình, vì sai lầm của những người ở tít trên cao vời vợi? Bao nhiêu học sinh bất hạnh và gia đình họ đã phải hy sinh tương lai, cuộc đời của mình để tô diểm cho những tờ giấy khen của giáo viên, những bằng khen của nhà trường, và bảng thành tích của giáo dục địa phương?

Phổ cập giáo dục là chương trình nhân đạo, nhưng làm bằng mọi cách là bất nhân. Tôi nhớ báo chí từng viết có học sinh lên lớp Sáu không biết đánh vần tên mình, rồi em bị trả về cấp Một… Học sinh ấy lên lớp Năm bằng cách nào, chỉ bị trả về khi đã qua trường khác? Và có bao nhiêu đứa trẻ như em không được báo chí nhắc đến, và bao nhiêu người như em cầm tấm bằng cấp Một rồi bỏ học, mù chữ?

Lần đầu thấy trăng, Võ Diệu Thanh. Nguồn: Nhà xuất bản Phụ Nữ

Nhìn rộng ra, những vấn đề rất lớn mà ta bắt gặp, không chỉ xuất hiện trong giáo dục mà trong mọi mặt của đời sống, như nghề y, nghề quản lý… Chúng không thể được giải quyết chỉ bằng loại bỏ những triệu chứng đang từng ngày xảy ra nhiều hơn, nghiêm trọng hơn, mà cần phải truy căn nguyên cội rễ. Con người không có lỗi, cái có lỗi là cái hoàn cảnh đã làm cho họ phải lỗi lầm. Nếu muốn họ không bị tha hoá, biến chất, ta cần phải thay đổi hoàn cảnh xã hội mà trong đó họ đã được đào tạo, lớn lên. Chỉ có như vậy, những con người với số phận bi ai, mà tôi đang thấy đầy rẫy trong xã hội bây giờ, mới không lặp lại ở thế hệ tương lai. Để con cháu chúng ta có thể vui vẻ mà sống, không phải chịu đời khổ đau vì những lỗi lầm không phải của chúng gây ra.

Xã hội vốn không công bằng, nhưng mọi phận đời đều đáng được nhắc đến như nhau.

Cảm ơn cô Võ Diệu Thanh. Những dòng trong truyện này của cô một ngày nào đó nên được đưa vào sách giáo khoa, không chỉ để dạy cho học sinh, mà còn để dạy những người sẽ dạy học sinh.

Trích sách:

Từ hồi trước chưa từng nghĩ tới nhục. À vô tình nó có xài tới một lần. Thầy Mãi biểu tôi đọc bài. Tôi không thuộc. Duy nhất bữa đó thằng Dị, con Hậu thuộc bài. Ông thầy đánh vô tay tôi một roi. Thấy muốn độn thổ. Dù tôi trước giờ đã bị đánh không biết bao nhiêu roi. Sao tôi không thấy xấu hổ với ba mươi lăm đứa khác cùng lớp, mấy trăm đứa khác cùng trường mà chỉ câu mâu với mỗi thằng Dị, con Hậu. Thằng Dị con Hậu là những đứa ngang với tôi. Nó hơn tôi dù chỉ một cái cười cũng là điều nhục. Trong khi nhóm ba đứa chúng tôi thua mấy chục đứa kia là điều rất bình thường.

Thầy Độ nói rất rất nhiều người nghĩ như vậy, làm như vậy. Ví dụ như nước mình nghèo hơn nước khác họ thấy bình thường. Người ta làm được những công trình siêu mơ ước họ cũng không để bụng xấu hổ. Nhưng hễ những người trong xóm cất một cái nhà đẹp, sắm một chiếc xe mới họ thấy nhục, phải cày xới để có tiền sắm cho kỳ hơn. Cho dẫu việc làm đó có khiến cho đất nước này nghèo hơn hiện tại hay là nghèo nhất thế giới cũng không nhằm nhe gì. Nhục của quốc gia là nhục của mấy chục triệu người chớ đâu phải của riêng ta. Và gần hết mấy chục triệu người đều nghĩ vậy.

Ông còn kể chuyện má thầy Minh. Bán cá lở kẽ tay nuôi thầy đi học. Về không còn chỗ dạy phải đi tuốt trong núi. Chừng xin được về xứ thì bà già chỉ còn lại bộ xương. Vay tạm trị bệnh cho bà mẹ. Nghèo nên cưới vợ không đàng hoàng. Con vợ cũng bỏ.

Thầy giáo Minh hiền lành lắm, rất thích nghề dạy học. Người mẹ bán cá lở tay chân để nuôi thầy đi học.

Thằng Đực, đáng lẽ nằm trong danh sách của cô Tài Ba. Nhưng rồi cô kéo nó vào góc lớp nói nhỏ:

- Em nói với thầy hiệu trưởng em thích học lớp thầy Minh.

- Em không thích lớp thầy Minh. Ổng bắt học bài thấy ông bà ông vải. Mà em không thích học.

- Cô cũng bắt học bài vậy.

- Nhưng em không thích học thầy, em thích học cô. Giống như em không thích ba, thích má hà.

- Em học thầy cô cho em mười ngàn.

- Hông.

- Hai chục.

- Hông.

- Em hông nghe lời cô, khi vô lớp cô đánh em tơi bời luôn

- Hông sợ. Cô đánh sao dữ bằng ba em. Cô yếu xìu.

- Cô méc ba em. Không học bài, méc, không viết bài méc, xé tập bạn, méc, đón đường bạn chia phe đánh lộn méc.

- Thôi, thôi. Tôi khoái học thầy Minh.

Rồi sau đó, với sự quậy phá của thằng Đực, và sự can thiệp của cô Tài Ba, thầy Minh bị đuổi khỏi ngành, mẹ thầy chết.

Cô Đẹp rất thông minh. Rốt cuộc học trò cô cũng không được hưởng hương thơm từ trí tuệ của cô bao nhiêu.

Người ta đòi bằng cấp thì cô mua bằng cấp, người ta đòi chất lượng thì cô phù phép chất lượng. Khi mà người ta không đủ sức để đánh giá con người bằng quá trình, bằng hiệu quả mà chỉ bằng cách bung ra những cái khuôn, thì những người như cô còn đất để tung hoành. Cô biết uốn mình cho vừa khuôn. Nếu không vừa cô dùng bơm để thổi, dùng rác rến để chèn. Mặc kệ là xương mình có gãy, là lương tâm mình có bị móp méo, vặn vẹo. Cô tiến hoá tài ba giữa cái thời bằng cấp và khuôn khổ.

Kiểu dạy qua loa của thầy cô trên lớp là hợp với quy định. Họ đuổi theo những kiến thức cao siêu đâu đó. Họ nghiên cứu tâm lý học trò trên sách vở, trên giáo trình một cách nhuần nhuyễn. Khi cần thuyết trình họ nói thao thao bất tuyệt. Khi đứng giảng bài đọc vanh vách những khái niệm đã ăn sâu vào đầu óc họ từ năm này qua tháng kia. Giống như một tín đồ ngoan đạo thuộc làu làu kinh kệ. Nhưng chữ vô di chẳng đọng lại chút gì trong lòng.

...

The Google Story – impressions about an innovative, technology-driven company

Mon, 30 Oct 2017 00:00:00 GMT

Google started from an Ph.D. thesis, in 10 yearns, has grown to an Internet giant, which affects billion people’s daily life. There are many aspect of the story that I was curious.

Vision

I impressed, loved the vision of Google

A perfect search engine will process and understand all the information in the world.

They stated it, and worked well to achieve it.

Sometimes, maybe they did not achieved it fully. This possibly is one of the reasons why Page and Brin said they was not satisfied and Google does not meet their expectation. That goes further to what Google is trying to do:

“The ultimate search engine,” says Pages, “would understand exactly what you mean and give back exactly what you want.”

Investment

Technology alone is not enough. New-born companies need capital. And the way that Google, in their first days, sought for investments while keeping long-term vision, attracted me. They planned to seek for investments from multiple investors, instead of only one solely, because they believe that might risk control in their company. But not much capital firms agree with such a thing. They want to take control, influence in the company where their money is put in. But in the end, both firms chose to split the investment, fifty percent each. Google might walk away if they did not agree. To do so, Google Guys had to convince investors about their vision, and their ability. So that investors can trustworthy give control of the company into their hand. Nobody want to put money to someone they do not trust, or just trust without control. But this is not impossible. If you and what you are doing can be used to convince them. This is rarely happen, but possible, as in the case of Google.

At some important moments, words from right people can make huge difference, which are more persuasive than all the things you presented. Entrepreneurs need strong relationships.

The Google story. Source: Amazon.com

Execution

In case you are just technologist, it is recommended to have somebody who master at business administration to help running your company. Hence you can focus on what you are good at: product and user. Investors will help with consulting and coaching. They do not want their money to go in wrong direction. And what they give your company is not just but more worthy than money.

Building good product is fundamental, but not enough. You need to work with partners to boost your business to larger scale, instead of depending only on organic users. This will also help you earning big packages, and relationships.

There are many aspect to deal in a new-born and ambitious business. Good product, along with talented team, is just the fist step. Then problems will occur. You will have to find a way to sell your “best” product. Although it is not bad, but finding people want to buy it is a different story, requiring different skills. You will have to manage your company. You will have to scale but not burn all cash that investors put in. You will need to deal with big corporations and newcomers copying your product. You should register your patents. And you will find more source of money and gifted people.

Risk does not mean just losing money, or user, but maybe the whole business. Taking risk is a part of the game. It is unavoidable, so do not try to avoid it, but cleverly taking it.

Environment

Looking in that small world in Silicon Valley and top tech companies, there are things that people grew up and graduated from developing country, like where I am from, Vietnam, not recognized. A person should change mindset or being outstanding in order to be a part of it. They operates at a different level of knowledge, management skills, working styles and environment. Different kinds of education creates different kind of people and society. If you don’t like the way you educated, the way your society currently is, and want to change, you need to update what you were taught, deeply from inside. If you would like to be a part of it, you should find some way to participate in the lifestyle, the way of thinking and the way of working. Natural intelligence, to me, is equally for human kind. But as we can see, current result of nations and communities are different. That is because of the way people living, cooperating, and teaching each other. Silicon Valley cannot be copied from outside in, it should be be done inside out. Not top down, but bottom up.

Culture

What I like most about Google after reading this book? That is “20 percent of time.” Employees have 20 percent of their paid time, which means one day a week, to do whatever they want. This can be pooled. So they can spend a whole month in anything. They can chase ideas, researches, to please themselves but not their bosses. A tech company can benefit from its employees doing what they are deeply care about. They are better, and then the company will get more. In Google some ideas was funded and brought profit. Google is operated like university campus, where two founders came from.

The second thing is free meals. I heart this before but was totally surprised. I though that just free meals from food providers around, like McDonald’s or something alike. But Google did it differently. They seriously hired chefs, with stock options, to do all the planning, cooking and presentation. They considered organic ingredients and really care about their employees’ health. That is like a restaurant inside the company. And that is impressive.

One quote from the book that summarize the story of Google:

Youth + freedom + transparency + new model + the general public’s benefit + belief in trust = The Miracle of Google

In my words: “Follow the people and money will follow you.”

More imagination

It is my dream to imagine whole computer system in my brain, to illustrate its workflow mechanism inside my brain, to know all the things of the system, with just one imagination. I am trying with systems I am working on at my current company. And I would like to do that with a system at scale like the Google search engine, software and hardware. After that, I want to be able to imagine the mechanism, the workflow, the principal of bigger things, like universe and philosophical existence.

Who Am I? And If So, How Many?: Answering life’s questions via self cognition

Tue, 17 Oct 2017 00:00:00 GMT

The author does not represent specific ideas of any school or people, but multiple achievements in many sectors. And what perspective is right, what is wrong? What is the most persuasible? I think that is not his intention. He only wants to give us a multi-perspective point of view.

Diverse point of views

When studying science, considering in many perspectives is important. Any point of view seams to be reasonable in this perspective possibly seeming reasonable in the opposite perspective also. At that time, you might think: “Believing totally, and stop continuing from the first point of view is impatient and somehow stupid.” Then you would know that if two philosophers with definitely opposite/anti-each-other opinions are equally smart and respectful. And in many cases, they are both reasonable, too.

If you find something which is reasonable, acceptable and sounds good, that is great. But such finding should not stop you from finding different ideas, should not stop you in your path to truths. You need to study supporting, similar, and opposite ideas to strengthen your thoughts, to correct your doubts, and to justify your conclusion. Truth is not unique, it survives.

More generally, looking at other sciences, for example in this book is psychology and biology, is recommended. To many questions, philosophy alone is one-sided. Philosophy should not and never is the single source of truth.

Stopping thinking, concreting ideas is a dead end. Philosophy itself has not ended.

Who Am I? And If So, How Many? by Richard David Precht. Source: Scribe Publications

Note from the book

You think “To be is to do”

Or “To do is to be”

Oh, that might be “Do be do be do”

The Thorn Birds – a story about unavoidable destiny

Thu, 11 May 2017 00:00:00 GMT

Tragedy

This book is a tragedy. Love can totally destroy people but they cannot do anything to avoid or change. What is destroying they is very powerful: destiny, or God. The tragedy is not only happen with one couple, it happened to 3 generations: grandmother, mother, and daughter. Year after year, decade after decade, every people experienced hurt, but tragedies did not have an end. People loved much, was hurt much; people loved less, hurt less; people who tried to fight against destiny, hurt more. They wanted to change, but God always won.

I wonder many times: “How can these people live their life with all their pains? How can they stand with all the events that happened?” This book has a lot of strong woman. I feel so weak comparing to them.

Spoiler: There is a bright spot at the end of the book is happily at the end, the daughter found her true love and happiness.

The Thorn Birds by Colleen McCullough. Image source: Amazon.com

Dreams

This story is about love, chasing dreams, and the fight against God. A man usually has desires. And these desires may kill that man’s love, and the person they love too. When a man goes out for dreams, he is leaving his woman behind, with all the pains, broken heart, and loneliness. Men can think about staying at home, for their lover’s satisfaction. But actually they should not, because they will day-by-day thinking about their dreams, about what they did not do. And that, in turn, will break the relationship. This is an unavoidable situation. People can try their best; things can come good or bad. And at the final end, destiny will win them all. This is one of a few stories, which I did not find any solution for the people.

Description

This book, like Gone with the wind, described thought of woman in specific, and human in general, very well. They helped me much in understanding what are in woman’s minds, that are the special points of their though compared to man, what is the flow of thoughts in their brain… In man’s point of view, woman is hard to understand, in every circumstances. And if a men want to understand woman around him, I suggest these books.

Description techniques is impressive and extremely beautiful. I can imagine large fields in Australia, flowers, animals, buildings, life styles… as they appear in front of me. While going near to the end, I read slower and slower. I was afraid that it will terminate and I would have to stop reading.

Conclusion

I did not understand the intention, the idea of Colleen McCullough when writing this book. What did she want to state? Was her intention is just that human cannot win God, or life is suffer and being a human is painful? I am sure that I missed something deep in the novel and re-read will be a must.

Experiments when reading The Art of Computer Programming

Tue, 04 Apr 2017 00:00:00 GMT

Think beyond what is written. The text is concise. Perhaps the author did it this way to encourage reader thinking.

Skim when needed, and get back when necessary.

It is probably preferable, for motivation, to skim over this section lightly at first, and (after seeing numerous applications of the techniques in future chapters) return to it later for more intensive study. If too much time is spent studying this material when first reading the book, a person might never get on to the computer programming topics!

The Art of Computer Programming – a new beginning

Mon, 03 Apr 2017 00:00:00 GMT

Based on some online courses, and references on the Internet, I believe that this set of books is a good point to start studying computer science. (2018 update: I was wrong)

However, I will face a lot of difficulties: this study will not help me much in short time; I will not have opportunities to use these knowledges in applicable works until I master; the investment of time is huge but I will not get explicit return in years, I still have to work, while contributing in deep learning. Despite of all of these reasons, I also decided to do. I always question about basic principles behind technologies. I don’t want to be somebody only use someone else’s result blindly. The road ahead is long and hard, but I want to experience. The biggest benefit in short term is the fun of making my brain working in pressure, and through its limit. Nothing satisfy me more than the feeling of today I am better than yesterday, and I will not stop.

I studied algorithms at high school. When I was in college, I studied more about software engineering. At that time, I was thinking engineering is the practical part, and algorithms are old-fashioned. But after 10 years studying and working as an engineer, I also feel that I like science more.

About

The Art of Computer Programming series by Donald E. Knuth. Source: Vec.com

This set of books is a monograph written by Donald E. Knuth. He attracted me when declaring the purpose of his work as:

Differs from that taken in most contemporary books about computer programming. I am not trying to teach the reader how to use somebody else’s software. I am concerned rather with teaching people how to write better softwares themselves.

And to deal with fast-moving computing industry, Knuth wrote:

My new goal has been to concentrate all “classic” techniques that are likely to remain important for many more decades. I am trying to emphasize concepts that are timeless.

I did not expect anything else.

How I will read

This is the first time I read The Art of Computer Programming. And surely I will read again many times. Therefore, to keep it suitable with my current level and background, make it maximum valuable for me, and make me most pleasure and joyful while reading, I decided to:

With time:

Have time limit to everything: read a chapter, a section, do exercises.
Determine if a section is should-read at specific time, based on what I will gain. Remember I will not read only once, and will not read exactly from begin to end.
Following regular progress is not required.
If a section is decided to read, read thoroughly.

With exercises:

Don’t try to solve all the exercises.
Don’t try to fulling understand all the deep mathematical issues.
But it is recommended to read through and notice about their existence.

With interesting problems:

If I choose to solve a problem, and see that it is interesting, I will write to describe its solution.

While reading this series, I have noted my experiments. You can find them at Experiments when reading The Art of Computer Programming

Death Note – A good manga for practicing rational thinking

Thu, 23 Mar 2017 00:00:00 GMT

When I was reading, I tried to think like the characters, tried to understand their arguments and evidences. I put myself into their situation, of both sides. And by trying to thinking like that, I intended to practice my brain logical thinking and study from the characters.

Some actions that I think characters used to drive them to success:

Get other people’s help.
Gain as much information, knowledge as possible.
Hide information to enemy. Provide false information.
Find patterns among events. Finding patters is a good starting point. After finding something, you will have information to get further.
If information stream is stuck, try to action to make information appear: make enemy action, make allies action…
If yourself need to take action, try to hide as much information as possible in your actions.
Give assumptions. And try to confirm or negate it.
Predict what could happen future, guess that would the enemy do, and get ready for them.
Thinking about thinking about thinking. Planning about a plan about a plan.
Keep mind calm in every situations. Minimize effect of feelings.
Never think that you are right. Never think that you win.
Behave in the way that you feel most comfortable while not disturbing others.

Characters in this manga have some specific ways to keep them concentrate that I think might be helpful:

Eat sweet foods to provide energy to your brain. But keep thinking while/after eating in order to not get fat.
Be in any style you feel most comfortable: squat, sit in the floor…
Do anything that make your mind feel most relaxing, productive: eat, play toys, walk…

These are personalized behaviors. Do not try if you do not feel definitely comfortable with them.

The manga also taught me to put aside feelings when trying to solve hard problems. Feelings can make you think in a personal, inappropriate, and wrong way. Feelings can make you find evidences to prove what you feel, but not finding conclusion from strong evidences. These are two opposite processes. Feelings sometimes help somebody finding correct answers of some problems. But with really hard problems at most of the time, it will drive people far wrong away. Feelings are different from intuition.

Every important thing need a detail plan, with predefined alternatives to make it go to success. The result is defined before combat begin. That is the power of planning. But do not underestimate the meaning of execution. Bad execution can destroy good plan. And good execution can contribute to not-so-good plan.

Somebody think this manga is a story about combat. But I think this manga is about ideals, philosophy, intelligence, and how to think.

A recommend manga for anybody who are interested in blowing your mind. For those extremely intelligence, this manga is for relaxing.

If you think you are not smart enough, keep practicing. Brain is trainable, intelligence is gainable.

The Code Book – technical history of secrecy

Mon, 30 Jan 2017 00:00:00 GMT

Concealing messages

From the ancient of time, concealing message is a critical survival factor of people, armies and organizations. People wrote letter by a type of ink that only readable after heated; they wrote on someone’s head and wait for their hair to grow to hide information; they wrote on a piece of wood and wax it; or even swallow the letter to hide it in the postman’s stomach. But this kind of secrecy has a fatal weakness: if the message is detected, the information is exposed. That is why people need cryptography to continue hiding information, in case the message is somehow detected.

The code book by Simon Singh. Image source: Books Come First

Early cryptography

Cryptography has 2 major branches: transposition and replacement. Transposition is re-ordering characters in the message. Replacement is converting one character to another. With replacement, people can use the same character set as the original message or introduce a whole new set.

Character replacement cryptography is strong and worked for centuries until it was broken by frequency analysis. This method analyzes documents of original message’s language (if known) to determine the frequency of its characters, or consecutive sequence of characters. Based on this result, and frequency of encrypted message’s characters, people can form a one-to-one mapping. This method is based on probability, its accuracy would reduce if message is short (less than 100 characters). Frequency analysis works but it would be harder if people use following tricks:

Remove all white spaces to make language analysis more difficult. For example with English, a character has two white spaces before and after it, that character would be “A” or “I”.
Use null characters: add characters which have no meaning.
Use special character for specific meaning. For example: ∆ character for indicating the previous character is duplicated.
Intentionally write incorrect-spelling words.
Use word encryption (encode): encode one word by another word or a special character. This trick can also be broken by guessing from context.

After centuries, these kinds of cryptography were broken by language analyzing. They also became easier to be broken if one character is decrypted correctly, later characters can be decrypted one after another, faster and faster. So we need a stronger encryption.

Multiple mapping tables

This method instead of using only one, it uses multiple mapping tables and switch among them for every character. For example: use table 8 for encrypting first character, table 5 for second character, table 37 for third character and so on. Which table is used for which position is determined by a predefined key. The same character that is placed at different position in the message will be encrypted by different characters. This make this method somehow invulnerable for language analyzing.

Although this method is more secure, but it is harder to use and take longer time for encryption and decryption. That’s why it is not as commonly used as single mapping table, which is less secure.

This method is strong. But it, in turn, is broken if someone (1) Find character groups’ repetitions, then can guess the length of the key. (2) After guessing the length of the key, we can use frequency analysis.

There are some tricks for making this method stronger:

Use long key.
Use a book or a paragraph in a book as the key. You can also use a song, a letter, or invent a whole new document, and agree it with the receiver. Because the key is very long, therefore encryption overcomes finding repetition method. If the length of the key is as same as the message’s, encrypted message is very strong.
Use a random meaningless character sequence as the key. This will helpful defend against language analysis and guesses. However, this will make the key harder to remember, or must write it somewhere to transfer to the receiver.
To improve the meaningless approach, people used one-time keys, which were written in a thick notebook and agreed between sender and receiver. This will help if: (1) One message is broken and the key used for encrypting that message is discovered, enemy cannot use that key for other messages. (2) If 2 encrypted messages – which were encrypted by the same key – are captured, they cannot be used as references for breaking. One-time key approach has disadvantages: the physical notebook can be stolen and copied; and high quality randomness is hard to produce. So it is only used in top-secret and expensive channels, until today.
Do not use the same key to encrypt too many messages or a message which is too long. You will give breaker many clues. However, this is hard to achieve, because in the past, a key is intended to be used as many as possible.

From handwork to a machinery: Enigma

Using paper and pen is slow and error-prone. Many of these methods are broken. People need a faster, more accurate, and secure method. That’s why Enigma was born. The design of Enigma machine is complicated, it is made from many parts, and there are several tricks to improve possible keys and security. It is not necessary if I describe all the design of Enigma in this article.

Enigma machine. Image source: Wikipedia

A security system not only includes cryptography method, but also infrastructure, equipments and people to operate. Enigma is strong, but like any other security systems, it was broken by cooperation of countries, intelligence, scientists, philologists and mathematicians.

Some lessons I derived from the broken of Enigma:

Increase the number of possibility of keys.
Avoid repetition. Repetition is enemy of secrecy.
Avoid language patterns (big repetition of popular words, document formats…) Patterns are also enemy of secrecy. They are clues for breakers.
Customize security system occasionally to give more difficulties to breakers.
Do not use any material to keep keys. Keeping it in mind is better, but harder.
Minimize the role of human. Enigma machine itself was very strong. But the system that operated around it was not. People found clues for breaking Enigma mostly from human mistakes.

Use local language

Encryption is only hide information in a known language. Security is increased very much if using a language that enemy don’t know, or a language that very little people know. People will also need some enhancements to fix weaknesses of that language, and make it close to describe every words in their language. Somebody can invent a whole new language, if have enough time, money and craziness.

Computer era

After years using machines for encryption, decryption and breaking, these machines’s design were updated and their power grew fast. That leaded to the birth of another machine – computer. While previous machines can only solve one specific problem, computers are faster and can be programmed to solve multiple problems. Breaker can brute force the key set to find the correct key. In turn, encryptors tried to use computer power to enhance complication and strength of encryption.

One major different of computer compare to previous machines is: it represents data in digital form of 0/1 bits. Then original message, encrypted message, and the key are in the form of bits. There are many encryption methods invented for computer, which are too long to describe here.

Computer is powerful, flexible, but delivering the key from sender to receiver is costly and insecure, that may become the weakest factor in the system. People have to think about resolving this. If they success, computing encryption is applicable in commercial and in daily life, not only in government and military as before. People believed that such a solution does not exist. But after several years many people’s effort, some of them are mathematicians, a solution for key agreeing was published. This is an evidence of perseverance, faith and knowledge will pay off, no matter what the society think.

The first solution was a big success at that time. However, it need improvement. The process of agreeing encryption key requires communication between sender and receiver. What if the sender want to send a message but receiver is sleeping? Does she have to wait? Researchers introduced asymmetric cryptography, or public-key cryptography. Then after years of cooperation, trials and errors, people invented RSA. With RSA, security will be improved significantly, if the public key used to encrypt message is big enough, about 10^300. Until a faster way for prime factorization is found, RSA stays secure. But nobody can predict future.

Later, people continued researching, and they published a software, called PGP (Pretty Good Privacy). This software increase the speed, usability and add digital signature into RSA. Using PGP, people can encrypt their message and add digital signature into it easily and fast. This software is made for every people. At the time of this book is written, if all computers in the world cooperate, it will take billion years to break just one message encrypted by PGP.

An interesting thing is that if you programmed a strong cryptography software, do not deliver it on the Internet. Some nations, including United States, treats strong cryptography software as weapon, because it is difficult for them to break it. Therefore, you will be arrested because of exporting a dangerous weapon.

Another significant advantage of digital data is it can represent anything, not only text and numbers, but also image, audio and video. Using a computer, someone can encrypt their phone calls, as same as encrypting their message.

In the future, superpower computer systems can simply use brute force to find the correct key. Nobody can be confident if currently there are some of these computers out there or not.

Computing technology introduced new threats to secrecy beside cryptography, including:

Tempest attack

If you use a strong encryption method like RSA or a tool like PGP, you are also vulnerable for leaking your private data. When you are typing something on your keyboard, or when your computer’s CPU are processing, electromagnetic waves are produced and get into the air. Some people can use devices to collect those waves and analyze it, give them information about what you are typing, what your CPU is processing. Your private data is leaked before it is encrypted. To prevent this, you can equip your room with devices to prevent electromagnetic waves from getting outside. But in United States, government permission is required for buying those devices. Because it restricts the capability of government.

Cybersecurity

When people use computer to encrypt, and network to transfer their data, virus, malware, and many types of cyber attacks are threatening privacy. The cryptography algorithm is secure, but the system around it is not. In the scope of this article, you only need to know that if a cryptography cannot be broken, others factors like computer, network, human error will be the target.

Quantum technology

Currently, mathematicians did not find a faster way to do prime factorization (but did they? Who know). So RSA stays secure. If the algorithm is not breakable, people need more powerful computers to do the job. And they are developing one, quantum computer.

In turn, physicians and mathematicians are researching a method to apply quantum technology, which will create the strongest cryptography in history. They published and theoretically proved that it is unbreakable. Some experiments with new method succeed within short distance. In the future, quantum cryptography will be practical.

The race never ends.

Quotes from this book

In this book, there are some quotes that I think interesting:

Keeping the key is more important than keeping the cryptography mechanism. – Kerchhoffs

A cryptography which is not strong enough is more dangerous than not encrypting at all.

Cryptography inventors are always thinking about the worst case, that there are world-level plots to break their cryptography.

Quotes from myself

If you broke someone’s encryption, try your best to keep that secret, don’t let anybody know that you broke it. So you can digest information from other messages.
Never think that your encryption is secure. It can be broken already by someone. Trust something which is not strong will result in totally defeat. Nothing is strong.
Be aware of supercomputers, and networks of computers, they can brute force anything. Who know a giant computer system is operating somewhere, or somebody can order all computers in the world to do some job?

Conclusion

The Code Book is an interesting book about information hiding, the continuous race between security system creators and breakers, between cryptography inventor and governments. It describes tools, machines, technologies and algorithms used in cryptography systems. It honors people with knowledge, logical thinking, mistakes, intuition, passion, and silent sacrifice.

Gone With the Wind – when the world is up-side-down and reactions

Sat, 28 Jan 2017 00:00:00 GMT

Scenery, lifestyle is described lively. The thinking, concerns and point of view of people are detail. Farms, horse wagons, houses, foods, parties exist in front of me. I am like a spirit flying around to see people living. My imagination was triggered at its most active mode. Surely I will read this book again.

Gone with the wind by Margaret Mitchell. Image source: Publishers Weekly

(Warning: spoiler ahead)

Description

This book is split into 3 parts:

Pre-war: wealth with talks, parties, farms, horses and love stories. Gentlemen discussed about the coming war. They were strongly confident in victory. Ladies didn’t care.
Mid-war: the falling of the society, diseases, captured and death gentlemen. Confederate States was up-side-down. Men were died, women were left lonely. But they kept faith in their justice, their culture, and the love to their land. People gathered to achieve what they believe, but failed.
Post-war: reconstruction from starveling and conflicts: conflicts between the the old and the new, among groups of people, among people who loving and are loved. People who were on the top now in the bottom. People who were in the bottom now aware their rights. Outsiders came to the top. Scarlett was very strong to take care of her family. But that definitely changed her life. She was blowed by the wind.

The author also had strong understanding of woman psychology, from a baby to an old lady. Woman’s needs, cares, rivalry were well described. A lot of thoughts that I was unable imagine that exist now came to real in Margaret’s words, they are so real that I cannot decline. Scarlett is one of the best described character I have ever read.

Love

This book is about love and hurt. I appreciate Rhett’s silent love to Scarlett and Melanie’s faithful love for Ashley. Melanie is the strongest woman in the novel, I think.

Scarlett was an attractive, sweet rose. The more beautiful the rose is, the sharper thorn it has. She was a horrible fire which injured any man who intended to touch, damaged, destroyed who succeed. Her husbands are injured most and one were indirectly killed. Rhett though that he can control that sacred fire, but he failed and his love for Scarlett was vanished.

I realize loving someone but marry another will hurt oneself, the person loved, and the person married. Do not know who are actually loved, or know too late, will result in pains. The later, the more pain. Loves in this book are complicated and they are only disclosed in the last chapter. Scarlett though she loved Ashley, but married three others then definitely hurt all of them. Scarlett loved Rhett but only realize after continuously erased his love for her. Throughout the book, she though she loved Ashley. But if there was a time Ashley told her that he loves her, Scarlett would stop thinking that she love him anymore. Ashley loved his wife but quietly chased Scarlett and only discovered his love for Melanie before her death.

It is not easy to figure out real love, for whom, and how much. Life is complicated, love is the most complicated factor. Love is not a game, so is marriage. Don’t play with fire or you will burn everything to nothing. Or play with care if you can.

Flexibility

Everybody have their viewpoint, and in a perspective, they are all right. Do not judge other people’s thinking based on your experiment but should on theirs. Before reading this book, I thought that the Confederate States are absolutely wrong because they protect the slavery. I evaluated that period based on this century’s standards. Everything has its own history. Everything has bright side and dark side. Everything has its arguments. Judging from outside is alway easier. Research, listen, and negotiate are more difficult but alternatives to resolve conflicts. But they are not always help.

History proved that violence works. Not the right side will win, but the stronger. The Southern army fought well, but lost. The Southern army is confident, but lost. The Southern society lack of practical mind, and they were loser. Be the winner to protect your belief and drive the flow of history to your side. If you lost, your faith and society will disappear along with your army. Protecting things will be easier with victory. Therefore try your best to win.

But if defeat is coming to clear, what should people react? This book appreciate people who have strength and are flexible enough to overcome difficulties. In a rapidly changing world, there are always alternatives for one to keep their living, care their relatives, and thrive. Ashley was not the man who didn’t dare enough. “He is only not flexible enough, tried to apply principles of non-existing society to current one. – said Rhett”. And he totally failed.

“Gone with the wind” is a skill. Foreseeing the flow of history is a skill. Choose the right side to stand and change when required is a skill. The book described people who are damaged by the tornado of history, and people who followed its wind. Life moves on. History moves on. What currently existing will disappear in the next couple years. What not existing now will be the dominating factor. “Raise the flag, and you are sinked, or hide the flag, and you are alive. What is your choice? Is there other answers?”

Going with the wind with a wise mind will return. But if going with the wind blindly, you will lose all: wealth, honor, and trust. But what is “wise”, that is based on each individual, family, and the society that they belong to. On the way to victory, everybody should be equipped with wealth, relationships, flexible mind, knowledge, and love.

Don’t forget, instead of judging other choices, it would be better to make your choices right.

The future

The novel made me to think about this question: “Is it appropriate to stably follow my ideals at huge costs. Or should I be flexible in doing required actions to seek for wealth and happiness of my caring people?

I think of my girlfriend.

"Right" – Vietnamese "Đúng việc" - lessons about life

Mon, 09 Jan 2017 00:00:00 GMT

Đúng việc by Giản Tư Trung. Source: giantutrung.vn

A book that are quite difficult to quote for me. If I want to share something, that is nearly quoting the whole book. It is difficult to rewrite what I favorite, what I fully agree from the book in my style. Because my ideas are almost the same, but my writing is not that good.

A book sometimes make me to reflect myself, correct my thinkings. It also give me extra motivation to strive for truth, follow what are right. The road is long and difficult, but I feel that it is meaningful and deserved.

A book teach me about ways to organize chaotic ideas in mind into sentences and paragraphs, into a way that readers may feel more comfortable.

A book that I want to read again in the future.

Gone Girl and perception on shared life

Sun, 18 Dec 2016 00:00:00 GMT

Gone Girl story is told by two interleaving flows: viewpoints of the wife – Amy, and the husband – Nick.

Gone girl by Gillian Flynn.

This book discloses different aspect of the story after each part. There are 3 of them.

Part I

Naturally and generally: Human are different

There are differences among every people in the world, and these differences are wider between woman and man. Woman need attention and care, man need respect and admiration. Care from other people is very important to women, while some men think this is small and they do not pay enough attention. Some actions that man think small are very important to woman. This is a big problem in every serious relationship.

Concerns of this person might or might not be other person’s concerns. Priority in life, set of values are different also. So never judge other people’s values and concerns based on yours. Human is diverge and unique in general. Differences are natural.

But talking is always easy, and reality is hard to accomplish, especially with who you care: your lover, your husband, wife or children – who you want to be better at every aspect of their living. And inappropriate judging and expectations are where problems come from.

Problem solving approach

The way of solving a problem is more important than the problem itself.

Some people choose to temporary hide their personal though for common sense in living, for saving relationships. They believe that talking about disagreements later on would be better than saying it immediately. The urgent task is calming both down.

Other people apply principles on their family life, after discussion for agreement from their partner. But life change from time to time, and it’s forceful to persist these principles. Multiple times in daily life, somebody will feel uncomfortable to follow, but because of the agreement, they are forced to not telling. This is bad. Trying to understand and being sympathy would be better. But better is always more difficult. And hard work pays off. The question is: How hard you can try? How difficult you can overcome?

Career

Both people need their own professional life and independence on career path to help their relationship better. Dependence on whatever is not good. Economically or mentally depends on your partner is even worse. Love is more consistent between two confident and successful people.

Be best at job, then compromising or choosing between job and personal life are not needed. Hold control of business as much as possible is the key for family happiness. However, choosing is necessary sometimes, but nothing beside you can force you, that is totally a personal choice. So work hard and minimize unwelcome effects of business to personal life. If you are not good at work, your career would affect your personal life, or even destroy it.

This comes to a dilemma: If I try hard, invest more time at work and studying to be best and independent, how can I pay enough time to maintain a relationship? How to balance? How to keep career not in turn destroy personal life? These are good questions.

Work-life balance. Image source: African Leadership magazine

Part II

Adaptation

Changing personality to satisfy partner’s need is not good. But what if each personality is not fitted with the other? How can you two do? Accept or change? Good questions.

If you become another person who is not actually you – a person with different characteristic, a person with personalities that you partner expect but not who you truly are – then at a specific time in the future, you will return back to who you naturally are, who you were before. This time surely will come. This is when problems begin. You partner might be not love you anymore.

Be yourself, whatever, always, even if your partner doesn’t like. Don’t become who else because other person want you to do so. Never permit your lover to love somebody who is not actually you. He/she will not love you, in the future, if you do so.

But if you realize something is not good, change it. Remember that change must come from you, not anyone else. Everything come from inside out is more persistent than outside in.

Basic standards

There are standards of each person, many of them are basic: which was built when people grew up, sensed and felt when they were a child and enforced when they went to school; which were taught by their parents and relatives. These standards are very hard to change, because they defines who people basically are, and differentiate each person among the others.

That’s why people usually should live their life together with common basic standards. This is also told by parents to their children as a criteria for choosing partners. And why it is good to have a partner with similar childhood and development environment.

That is hurt, but that is also reality. And sometimes reality wins.

Part III

This part, as my opinion, is just closing of what was opened in the first 2 parts.

Conclusion

This book gave me many knowledge about woman and man and how they live their life together. A open-minded book.

Never conclude after first reading - what I learned from Sophie’s World

Wed, 14 Dec 2016 00:00:00 GMT

“Do we actually exist?”
“Are time and space exist, or they just exist in human’s mind?”
“Do we see the world as-is, or they are just images in our brain?”

Those questions and more are asked during the book, and some philosopher try to answer them, while Sophie is learning philosophy from 4000 years ago until today.

Sophie’s world by Jostein Gaarder. Image source: Amazon.com

Following Sophie’s footprint through multiple philosophers’ though, I told myself to keep in mind “Even if everything looks clear, I should never conclude fast.” In other words, “Never lose sense of wonder.” When reading about philosopher A, I had a feeling that philosopher A is reasonable. Most of the time I would conclude that philosopher A is right, and other people who against A is wrong. But after a few chapters, I read about other philosophers who do not agree with A, partially or completely. I had a feeling that these philosophers are reasonable, too.

Multiple times I thought that keeping an open mind, never concluding at first time, and researching similar and opposite opinions are needed while studying philosophy. I remind myself not to try to find a “absolutely right” answer. Usually such answer does not exist. And what are right, what are wrong depends on circumstance and history. Keeping a “perfect” mindset while reading philosophy might harm knowledge exploration. Philosophy is a journey of thinking, so keep brain thinking as much as possible. Conclude what is right or wrong might close this process. That is not good, is it?

Whenever I wonder if an idea is right, I try to calm down my heed and keep reading. Someone’s mind will be improving from time to time, as long as they keep studying. If my idea at a specific time is wrong, that is normal. Just keep discovering knowledge. Strict myself, easy others, and keep learning.

Philosophy is a hard trip, but after finding out something (right or wrong, who knows), I had a good mood of knowing more. I am climbing up the rabbit fur.

This book is highly recommended for young girls and boys, and people who are new to and interested in philosophy. It is easy to read, easy to adapt, and funny.

Happy reading!