There are 999 reasons to become levi niner. Find yours at levi9.com/jobs
×Закрыть

Материалы по теме «приоритизация»

RSS

6 подходов к приоритизации задач. Опыт Readdle, MacPaw, Grammarly и EduNav 6 подходов к приоритизации задач. Опыт Readdle, MacPaw, Grammarly и EduNav

Ruslan Doronichev 17534

Руслан Дороничев, проектный менеджер в Relevant Software, дает выжимку самых популярных методологий и рассматривает, как в действительности приоритизируют задачи в украинских продуктовых компаниях на примере Readdle, MacPaw, EduNav и Grammarly. 9

Заблуждения и ошибки приоритизации Заблуждения и ошибки приоритизации

Serhiy Berezhnyy 10413

Процессы приоритизации —сложный многофакторный анализ. Чтобы хоть как-то упростить его упростить, мы создаем систему, в которой простые решения станут очевидными, а для обсуждения сложных появится почва. При этом создание идеальной системы — далеко не всегда самоцель, и обсуждение — важнее, чем система сама по себе. 12

Приоритизация задач: высшая математика или легкая разминка перед завтраком? Приоритизация задач: высшая математика или легкая разминка перед завтраком?

Serhiy Berezhnyy 14594

Это первая статья из цикла об основах, методиках и ошибках приоритизации. Сейчас поговорим о сложностях приоритизации. А в следующей статье разберем, какие ошибки подкидывает нам наш мозг, когда дело касается сложного выбора... 34

Комментарии

А вот нормальный путь не курильщика — это через инструменты подобные Nix, но они почти не развиваются. Удобство работы с ними застряло где-то в начале 90-х (странно, что еще не предлагают перфокарты).
Да да, а потом постик настрочить, как автор сабжа, типа ребята бля, знаю как вам помочь, значит слушайте .... ну и дальше как всегда, оно то из-за за угла виднее .
А какое отношение имеют неэкспортируемые поля к инкапсуляции?)
Потому что есть возможность свалить на тракторе.
Одни айтишники как терпилы, молча сидят. И только коменты строчат. А каждая отрасль по своему с новой властью решает проблемы. А тут даже петицию набрать мы не можем, а про митинги и шантажи так и по давно.
Да он просто бредил. Просто написал что-то, даже не читая то, на что он отвечал.
Ось те що писав: type Server struct { mu sync.RWMutex data []*recipes.Recipe } ще тести, інше кодогенерація все делают поля структур экспортируемыми Якщо DTO структура то всі поля відкриті, без getter-ів та setter-ів В сервісах поля закривають
Вообще, ДОУ далеко не самый токсичный. Есть еще один сайт...
ну да а потом микросервисы )) если динамическая загрузка shared objects (а по-другому видимо никак ну разве что снова вариант микросервисов) то зачем не сделать объекты .so уже конфигурируемыми на этапе загрузки что именно грузить? а стоп так они уже!
Сколько я не видел кодешников людей на go, все делают поля структур экспортируемыми. Это для облегчения примера или go программисты забивают на инкапсуляцию?
При чем тут это?
За що таке упереджене ставлення до «аплікації»? :(
Статическая линковка — это прошлый век. Используй динамическую загрузку, и сам решай что загружать.
Варіанти: println(cmp.Diff( mainRecipes.Recipes, recipesBy625.Recipes, )) та println(cmp.Diff( mainRecipes.Recipes, recipesBy625.Recipes, cmpopts.IgnoreFields(recipes.Recipe{}), cmpopts.IgnoreFields(recipes.Ingredient{}), )) дають однаковий результат:...
А теперь попробуйте без ignoreFields с темже результатом для protobuf