Quickly designing Questionnaires

Mockup UI

Component

Code example:

https://dotnetfiddle.net/Sfbsyt

Công thức bánh trung thu

1. Bánh dẻo
* Nước đường: 60gram
* Bột: 33 gram
* Nhân: 50 gram

- Nước đường:
+ 250 gr đường
+ 250 gr nước nóng
+ 1 tý cream or tear
- Nhân đậu xanh
+ 100 gr đậu xanh
+ 45 gr đường
+ 40 -45 gr dầu ăn
+ 5gr bột mỳ
+ 2 gr trà xanh
+ 40ml nước

Dummy vs. Stub vs. Spy vs. Fake vs. Mock

a) Dummy is simple of all. It’s a placeholder required to pass the unit test. Unit in the context (SUT) doesn’t exercise this placeholder. Dummy can be something as simple as passing ‘null’ or a void implementation with exceptions to ensure it’s never leveraged.

[TestMethod] public void PlayerRollDieWithMaxFaceValue() { var dummyBoard = new Mock<IBoard>(); var player = new Player(dummyBoard.Object, new Die() ); //null too would have been just fine player.RollDie(); Assert.AreEqual(6, player.UnitsToMove); }

While the above test would work just fine, it won’t throw any exceptions if RollDie implementation is invoking Board Object. To ensure that Board object isn’t exercised at all you can leverage strict mock. Strict Mock with throw an exception if no expectation is set for member.

[TestMethod] public void PlayerRollDieWithMaxFaceValueStrictTest() { var dummyBoard = new Mock<IBoard>(MockBehavior.Strict); //Ensure Board class is never invoked var player = new Player( dummyBoard.Object, new Die() ); player.RollDie(); Assert.AreEqual( 6, player.UnitsToMove ); }

b) Fake is used to simplify a dependency so that unit test can pass easily. There is very thin line between Fake and Stub which is best described here as – “a Test Stub acts as a control point to inject indirect inputs into the SUT the Fake Object does not. It merely provides a way for the interactions to occur in a self-consistent manner. These interactions (between the SUT and the Fake Object) will typically be many and the values passed in as arguments of earlier method calls will often be returned as results of later method calls“. A common place where you would use fake is database access. Below sample shows the same by creating a FakeProductRepository instead of using live database.

public interface IProductRepository { void AddProduct(IProduct product); IProduct GetProduct(int productId); }

public class FakeProductRepository : IProductRepository { List<IProduct> _products = new List<IProduct>(); public void AddProduct(IProduct product) { //... } public IProduct GetProduct(int productId) { //... } }

[TestMethod] public void BillingManagerCalcuateTax() { var fakeProductRepository = new FakeProductRepository(); BillingManager billingManager = new BillingManager(fakeProductRepository); //... }

Fakes can be also be implemented by moq using callbacks.

c) Stub is used to provide indirect inputs to the SUT coming from its collaborators / dependencies. These inputs could be in form of objects, exceptions or primitive values. Unlike Fake, stubs are exercised by SUT. Going back to the Die example, we can use a Stub to return a fixed face value. This could simply our tests by taking out the randomness associated with rolling a Die.

[TestMethod] public void PlayerRollDieWithMaxFaceValue() { var stubDie = new Mock<IDie>(); stubDie.Setup(d => d.GetFaceValue()).Returns(6).Verifiable(); IDie die = stubDie.Object; Assert.AreEqual(6, die.GetFaceValue()); //Excercise the return value }

d) Mock – Like Indirect Inputs that flow back to SUT from its collaborators, there are also Indirect Outputs. Indirect outputs are tricky to test as they don’t return to SUT and are encapsulated by collaborator. Hence it becomes quite difficult to assert on them from a SUT standpoint. This is where behavior verification kicks in. Using behavior verification we can set expectations for SUT to exhibit the right behavior during its interactions with collaborators. Classic example of this is logging. When a SUT invokes logger it might quite difficult for us to assert on the actual log store (file, database, etc.). But what we can do is assert that logger is invoked by SUT. Below is an example that shows a typical mock in action

[TestMethod] public void ModuleThrowExceptionInvokesLogger() { var mock = new Mock<ILogger>(); Module module = new Module(); ILogger logger = mock.Object; module.SetLogger(logger); module.ThrowException("Catch me if you can"); mock.Verify( m => m.Log( "Catch me if you can" ) ); }

e) Spy – Spy is a variation of behavior verification. Instead of setting up behavior expectations, Spy records calls made to the collaborator. SUT then can later assert the recordings of Spy. Below is variation of Logger shown for Mock. Focus on this test is to count the number of times Log is invoked on Logger. It’s doesn’t care about the inputs passed to Log, it just records the Log calls and asserts them. Complex Spy objects can also leverage callback features of moq framework.

[TestMethod] public void ModuleThrowExceptionInvokesLoggerOnlyOnce() { var spyLogger = new Mock<ILogger>(); Module module = new Module(); ILogger logger = spyLogger.Object; module.SetLogger( logger ); module.ThrowException( "Catch me if you can" ); module.ThrowException( "Catch me if you can" ); spyLogger.Verify( m => m.Log( It.IsAny<string>()), Times.Exactly(2) ); }

Nguyên lý tạo thế cho cây cảnh

Nguyên tắc chung khi cắt tạo hình cho cây cảnh

– Quan sát tổng thể cây, chọn mặt tiền cho cây

– Hình dung cấu trúc cành theo hình dáng thân, tiến hành cắt ngắn các cành, tỉa bớt tán lá làm thân lộ ra.

– Trước hết xác định nhánh nào cần phải bỏ, chất lượng của Bonsai phụ thuộc vào việc này, dĩ nhiên là thế dáng đã gợi ý cho ta quan sát cây nguyên liệu. Nếu nhầm lẫn trong việc này sẽ làm cây mất giá, biến cây có thế đẹp thành cây tầm thường.

Cắt chuyển cây phôi thành cây dáng xiên

Công việc cắt tỉa phải tuân theo nguyên tắc:

+ Ở dưới là nhánh to, các nhánh nhỏ dần lên trên, nhánh để phải phân bố theo hình xoắn ốc quanh thân, tạo tán lá thành khối chóp.

+ Cắt bỏ những nhánh ở vị trí không đẹp hoặc nhánh vô ích.

Lô cuốn ống tưới cây

Tháo đầu ống nước gãy

Vòi tưới dài

Cưa xích 159K

Để có một cây cảnh dáng thế đẹp, ngay từ đầu chúng ta cần có kế hoạch dài lâu để thực hiện uốn tỉa tạo hình cho cây.

Trước hết chúng ta cần quan sát tổng thể cây một cách kỹ càng về : Loại cây, hướng mà dáng cây có vẻ đẹp nhất (mặt tiền), cấu trúc phân cành, hình dạng kích thước lá…Sau đó cân nhắc và xây dựng nên dáng thế cuối cùng cần đạt được. Từ đó tiến hành thực hiện uốn nắn cắt tỉa đã định.

Mỗi một cây đều có hình dáng nào đó song chưa rõ nét, cắt tỉa là việc tạo hình dáng cho cây dáng thế, cắt tỉa làm giảm sự phát triển của bộ rễ, sự phát triển của cành lá.

Chuẩn bị dụng cụ

Kéo cắt cành Kéo tỉa lá

Nguyên tắc chung khi cắt tạo hình cho cây cảnh

– Quan sát tổng thể cây, chọn mặt tiền cho cây

– Hình dung cấu trúc cành theo hình dáng thân, tiến hành cắt ngắn các cành, tỉa bớt tán lá làm thân lộ ra.

Cắt chuyển cây phôi thành cây dáng xiên

Công việc cắt tỉa phải tuân theo nguyên tắc:

+ Ở dưới là nhánh to, các nhánh nhỏ dần lên trên, nhánh để phải phân bố theo hình xoắn ốc quanh thân, tạo tán lá thành khối chóp.

+ Cắt bỏ những nhánh ở vị trí không đẹp hoặc nhánh vô ích.

+ Hai nhánh mọc đối nhau phải cắt bớt một nhánh, để cho các nhánh mọc xen nhau.

+ Bỏ các nhánh mọc chằng chịt làm cây rườm rà, nặng nề.

+ Cắt ngắn những cành nhánh lớn, quá dài.

+ Cắt những chồi mọc đứng từ cành để tạo dáng già nua cho cây. Vì cây già, cành cây thường oằn xuống.

+ Không chọn các chồi mảnh mai làm đầu của các cành lớn, làm mất vẻ tự nhiên.

+ Nhánh đã chết phải được cắt bỏ, đã héo trừ trường hợp nếu giữ nhánh đó sẽ tăng thêm vẻ đẹp, vẻ già nua của cây.

+ Vết cắt phải ngọt, chéo và lõm vào thân để mặt cắt mau lành sẹo và tạo thành sẹo trên thân.

Kỹ thuật cắt thân, ngọn

– Việc cắt tỉa cây cảnh chúng ta nên bắt đầu từ thân chính của cây, nó quyết định Dáng – Thế cây, trước khi cắt cần quan sát tỉ mỉ từ nhiều gốc độ khác nhau. Vì vậy, phải căn cứ vào hình dáng bên ngoài của thân cây cảnh, kết hợp với ý đồ sáng tạo của mình mà lựa chọn mặt ngắm đẹp nhất.

– Đồng thời phải xem xét tới quan hệ tương hỗ giữa thân chính và các chạc cây, để quyết định thế phát triển của cây. Trình tự cắt tỉa phải từ thân chính tới cành chính, rồi từ cành chính đến cành nhỏ.

Cắt chuyển cây phôi thành cây dáng hoành

Từ một cây nguyên liệu, tùy thuộc vào cách nhìn nhận của chúng ta mà ta có thể tạo thành cây cảnh có dáng thế khác nhau.

Từ cây phôi có thể tạo cây dáng thế khác nhau

Kỹ thuật cắt cành

Cành chính là khung giá đỡ cơ bản của cây cảnh, nó cũng làm phong phú sự biến hóa tạo hình chỉnh thể cây, vì thế sự phối hợp giữa nó với chạc mẹ bắt buộc phải phù hợp với chỉnh thể để đạt được sự thống nhất hài hòa của toàn cây.

Cành tán thứ nhất thông thường ở vào vị trí 1/3 thân chính, khoảng cách giữa các cành tán bên trên dày hơn khoảng cách cành tán bên dưới để đạt yêu cầu lùn hóa cây.

Cách bố trí cành tán

Đối với những cành không phù hợp với tạo hình tổng thể như cành đan nhau, mọc vòng, mọc gối, đối xứng và song song phải kịp thời cắt bỏ.

Các cành nên cắt khi tạo hình

Đối với một số dáng cây cụ thể như: Kiểu gió lùa, cành rũ, cành đối xứng ta nên vận dụng các cành có sẵn không cắt bỏ chúng.

Một số cành không cắt theo dáng thế cây

CSS in javascript

CSS-in-JavaScript Style Guide

A mostly reasonable approach to CSS-in-JavaScript

Naming
Ordering
Nesting
Inline
Themes

Naming

Use camelCase for object keys (i.e. "selectors").
Why? We access these keys as properties on the styles object in the component, so it is most convenient to use camelCase.
```
// bad
{
  'bermuda-triangle': {
    display: 'none',
  },
}

// good
{
  bermudaTriangle: {
    display: 'none',
  },
}
```

Use an underscore for modifiers to other styles.

Why? Similar to BEM, this naming convention makes it clear that the styles are intended to modify the element preceded by the underscore. Underscores do not need to be quoted, so they are preferred over other characters, such as dashes.

// bad
{
  bruceBanner: {
    color: 'pink',
    transition: 'color 10s',
  },

  bruceBannerTheHulk: {
    color: 'green',
  },
}

// good
{
  bruceBanner: {
    color: 'pink',
    transition: 'color 10s',
  },

  bruceBanner_theHulk: {
    color: 'green',
  },
}

Use selectorName_fallback for sets of fallback styles.

Why? Similar to modifiers, keeping the naming consistent helps reveal the relationship of these styles to the styles that override them in more adequate browsers.

// bad
{
  muscles: {
    display: 'flex',
  },

  muscles_sadBears: {
    width: '100%',
  },
}

// good
{
  muscles: {
    display: 'flex',
  },

  muscles_fallback: {
    width: '100%',
  },
}

Use a separate selector for sets of fallback styles.

Why? Keeping fallback styles contained in a separate object clarifies their purpose, which improves readability.

// bad
{
  muscles: {
    display: 'flex',
  },

  left: {
    flexGrow: 1,
    display: 'inline-block',
  },

  right: {
    display: 'inline-block',
  },
}

// good
{
  muscles: {
    display: 'flex',
  },

  left: {
    flexGrow: 1,
  },

  left_fallback: {
    display: 'inline-block',
  },

  right_fallback: {
    display: 'inline-block',
  },
}

Use device-agnostic names (e.g. "small", "medium", and "large") to name media query breakpoints.

Why? Commonly used names like "phone", "tablet", and "desktop" do not match the characteristics of the devices in the real world. Using these names sets the wrong expectations.

// bad
const breakpoints = {
  mobile: '@media (max-width: 639px)',
  tablet: '@media (max-width: 1047px)',
  desktop: '@media (min-width: 1048px)',
};

// good
const breakpoints = {
  small: '@media (max-width: 639px)',
  medium: '@media (max-width: 1047px)',
  large: '@media (min-width: 1048px)',
};

Ordering

Define styles after the component.

Why? We use a higher-order component to theme our styles, which is naturally used after the component definition. Passing the styles object directly to this function reduces indirection.

// bad
const styles = {
  container: {
    display: 'inline-block',
  },
};

function MyComponent({ styles }) {
  return (
    <div {...css(styles.container)}>
      Never doubt that a small group of thoughtful, committed citizens can
      change the world. Indeed, it’s the only thing that ever has.
    </div>
  );
}

export default withStyles(() => styles)(MyComponent);

// good
function MyComponent({ styles }) {
  return (
    <div {...css(styles.container)}>
      Never doubt that a small group of thoughtful, committed citizens can
      change the world. Indeed, it’s the only thing that ever has.
    </div>
  );
}

export default withStyles(() => ({
  container: {
    display: 'inline-block',
  },
}))(MyComponent);

Nesting

Leave a blank line between adjacent blocks at the same indentation level.

Why? The whitespace improves readability and reduces the likelihood of merge conflicts.

// bad
{
  bigBang: {
    display: 'inline-block',
    '::before': {
      content: "''",
    },
  },
  universe: {
    border: 'none',
  },
}

// good
{
  bigBang: {
    display: 'inline-block',

    '::before': {
      content: "''",
    },
  },

  universe: {
    border: 'none',
  },
}

Inline

Use inline styles for styles that have a high cardinality (e.g. uses the value of a prop) and not for styles that have a low cardinality.

Why? Generating themed stylesheets can be expensive, so they are best for discrete sets of styles.

// bad
export default function MyComponent({ spacing }) {
  return (
    <div style={{ display: 'table', margin: spacing }} />
  );
}

// good
function MyComponent({ styles, spacing }) {
  return (
    <div {...css(styles.periodic, { margin: spacing })} />
  );
}
export default withStyles(() => ({
  periodic: {
    display: 'table',
  },
}))(MyComponent);

Themes

Use an abstraction layer such as react-with-styles that enables theming. react-with-styles gives us things like withStyles(), ThemedStyleSheet, and css() which are used in some of the examples in this document.

Why? It is useful to have a set of shared variables for styling your components. Using an abstraction layer makes this more convenient. Additionally, this can help prevent your components from being tightly coupled to any particular underlying implementation, which gives you more freedom.

Define colors only in themes.

// bad
export default withStyles(() => ({
  chuckNorris: {
    color: '#bada55',
  },
}))(MyComponent);

// good
export default withStyles(({ color }) => ({
  chuckNorris: {
    color: color.badass,
  },
}))(MyComponent);

Define fonts only in themes.

// bad
export default withStyles(() => ({
  towerOfPisa: {
    fontStyle: 'italic',
  },
}))(MyComponent);

// good
export default withStyles(({ font }) => ({
  towerOfPisa: {
    fontStyle: font.italic,
  },
}))(MyComponent);

Define fonts as sets of related styles.

// bad
export default withStyles(() => ({
  towerOfPisa: {
    fontFamily: 'Italiana, "Times New Roman", serif',
    fontSize: '2em',
    fontStyle: 'italic',
    lineHeight: 1.5,
  },
}))(MyComponent);

// good
export default withStyles(({ font }) => ({
  towerOfPisa: {
    ...font.italian,
  },
}))(MyComponent);

Define base grid units in theme (either as a value or a function that takes a multiplier).

// bad
export default withStyles(() => ({
  rip: {
    bottom: '-6912px', // 6 feet
  },
}))(MyComponent);

// good
export default withStyles(({ units }) => ({
  rip: {
    bottom: units(864), // 6 feet, assuming our unit is 8px
  },
}))(MyComponent);

// good
export default withStyles(({ unit }) => ({
  rip: {
    bottom: 864 * unit, // 6 feet, assuming our unit is 8px
  },
}))(MyComponent);

Define media queries only in themes.

// bad
export default withStyles(() => ({
  container: {
    width: '100%',

    '@media (max-width: 1047px)': {
      width: '50%',
    },
  },
}))(MyComponent);

// good
export default withStyles(({ breakpoint }) => ({
  container: {
    width: '100%',

    [breakpoint.medium]: {
      width: '50%',
    },
  },
}))(MyComponent);

Define tricky fallback properties in themes.

Why? Many CSS-in-JavaScript implementations merge style objects together which makes specifying fallbacks for the same property (e.g. display) a little tricky. To keep the approach unified, put these fallbacks in the theme.

// bad
export default withStyles(() => ({
  .muscles {
    display: 'flex',
  },

  .muscles_fallback {
    'display ': 'table',
  },
}))(MyComponent);

// good
export default withStyles(({ fallbacks }) => ({
  .muscles {
    display: 'flex',
  },

  .muscles_fallback {
    [fallbacks.display]: 'table',
  },
}))(MyComponent);

// good
export default withStyles(({ fallback }) => ({
  .muscles {
    display: 'flex',
  },

  .muscles_fallback {
    [fallback('display')]: 'table',
  },
}))(MyComponent);

Create as few custom themes as possible. Many applications may only have one theme.

Namespace custom theme settings under a nested object with a unique and descriptive key.

// bad
ThemedStyleSheet.registerTheme('mySection', {
  mySectionPrimaryColor: 'green',
});

// good
ThemedStyleSheet.registerTheme('mySection', {
  mySection: {
    primaryColor: 'green',
  },
});

Lợi V. Nguyễn

Navbar-tab