Skip to main content

Weekly engineering meeting we meet at 10 on 1010

Ben Ross Unless otherwise noted on a ticket, now ok to do PM approval + code review in parallel New point scoring system (1,2,3,5,8,13 - aka fibonacci)

Aigul Imadildayeva After removing a lot of ABs I figured out that we need to change our way of creating ABs, maybe it’s better to create new files rather than add more logic into existing scripts, so that if AB is unsuccessful we can just remove calls on files and remove files as well (same thing for their css, let’s create new css files for each AB) new messages

kz team come up with following questions/suggestions on our CSS: 1 CSS class names are not helpful, like $color-7 - maybe better rename it to $color-dark-grey?

  • needed for themes for various platforms - $color-7 may be grey in POWr but yellow in webydo. 2 separate CSS files for ABs - so that they will be just deleted if not needed
  • 3 Some css files are loaded several times (pict 1) - Yevgeniy suggests to research our webpack builder and general sass files where import was duplicated
  • Praneeta will create a ticket. 4 Themes css files. There are a lot of common things that can be moved out into separate file like base_theme (pict 2) And currently, if eng wanna add some styles, he/she should add it into all css files.
  • Check various platforms - when adding new variables 5 We have same css class names that have different values: powr.css we have $border-radius: 3px (Pict 3)
  • themes And same class in shopify.css with 5px (Pict 4) There are collisions between color vars as well 6 loading all css with React load:
  • Valeriy thinks that we can try to use CSS Modules to import 1 scss file per 1 React component Yevgeniy thinks it’s not a good idea because we have server-side rendering on ruby templates, it’s good idea for full SPA applications What do you guys think? Currently loading CSS takes long ass time
  1. how to avoid nesting in CSS => that’s the way people will stop using !important; without it nesting makes hard to overwrite css (Yevgeniy proposes:)
  • Exactly stop using the nightmare random naming on css 🙂
  • Using BEM, pretty good articles is there - https://en.bem.info/methodology/
  • It might start to refactor from some of more easest sass components. Be careful around it because certain classes use in javascript en.bem.infoen.bem.info Methodology / BEM Methodology pict 1 from standalone Screen Shot 2019-10-10 at 5.24.16 PM.png Screen Shot 2019-10-10 at 5.24.16 PM.png

pict 2 image.png image.png

pict 3 image (1).png image (1).png pict 4 image (2).png image (2).png

Abay Ibrayev I have also a questions about CI testing processes. Main Question to discuss: How to Deal with Test Automation Process on CI for Integration Tests (in isolation): How we will launch Integration Tests (Small sets of the tests that will rough and fast check main features before pushing to master branch) Variant 1: Run on localhost Before Merge With Master (Each developer before pushing branch to master should check that tests passed successfully) Variant 2: Before\After Merge Request (after build, deploy, on staging\Alpha) Also Questions: Does anyone have ideas how to deal With Test Automation Process on our CI? If someone has ideas, let’s discuss! What are u thinking about working with extra checks with integration tests? Do u think will it help to u workflow for the future? Or will it be just an unnecessary stuff? Or cause some troubles for developing process? (edited)