факт "в скраме нет ни слова" прям очень кайфово резонирует с фактом "ни разу за 15 лет не видел чтобы было иначе".. )) в лучшем случае, мудрое руководство просто дает возможность команде периодически "расслабиться" в стиле "ну, давайте, ладно, этот спринт на рефакторинг".. (только роадмап рефакторинга не забудьте подготовить))))
"возьми и прилети".. вот это какая-то глупость. мне даже кажется, что он специально это сделал. чето-там, например, "просчитал" и решил ввязаться в публичный/судебный спор с правительством. ну никто так не протупил бы -- это надо просто забыть или решить что "на денёк обойдется"!) я только поем и все, чесслово..
2 млн -- это ничто. надо иметь возможность подать туда, например, всю актуальную нормативную базу какой-нибудь страны, чтоб,ы получить юриста. или любое подобное применение. так что 2млн -- это, как раз, чтобы хоть компании смогли пользоваться как-то.
думаю, для начала они обеспечили все-таки технологическое преимущество -- блокчейн не только для функций валюты, а все любые прочие применения (потенциально)-- и это создало у пользователей веру в его уникальность и перспективность и действительно появились не-валютные применения -- и валюта тоже раскрутилась до статуса "второй после"..
привет. ну "упаковка софта" -- не совсем то, о чем я говорю. для разработки, имхо, докер это в первую очередь "воспроизводимое окружение". поэтому, в самом начале статьи, мне действительно _стало понятно_, что это так или иначе, проблема конфигураций.. (далее все увлекательно и я дочитал даже, но интрига "как починить" для меня была раскрыта)) об этом и была шутка! (но, кажется, меня не все поняли).
а, вообще, я и правда считаю контейнеризацию одной из "серебрянных пуль" современной разработки. что же касается бд прода -- то, наверное, тогда уж managed (опять же в воспроизводимой среде).
документация "сверху" (как хотят) -- в конфлюенсах и вордах, а документация "снизу" (как есть) -- в репах и маркдаун. пока так практикуем.. вроде норм. PS: только plantUml сильно серьезно, в итоге оказалось, зато mermaid выручает быстро накидать схему, что происходит, какие-небудь sequence diagram и т.п.
ну и главное... мимикрировать под кого? под конкурентов, про которые уже достроверно известно об их тесном сотрудничестве с анб?) смешно. ни вотсапу ни сигналу доверия просто ноль. а вот телеграму -- больше ноля)
все так говорят ("избыточное доверие"), но подумайте, я вот прикинул -- ни разу не использовал защищенные чаты, однако выбираю телеграм за удобство и скорость/отзывчивость. мне кажется, большинство тоже.
аналогично, -- я хотел довольно сложную функцию на генераторах или итераторах в функциональном стиле, и с серией прототипов и уточняющих правок с моей стороны, все получилось, пожалуй, быстрее у нас вместе, чем если бы я писал "руками" самостоятельно.
ну, в смысле, строгая матмодель с эвристиками и формулами, по идее внутренней картины мира не имеет, точнее эта картина просто внешняя -- в голове автора(ов) матмодели. )
а любая нейросеть, да.. очередное подтверждение принципиального сходства с биологическими нс.
т.е. вывод -- выучивают. но, вроде бы, не только трансформеры!? разве для эффективно обученных сетей с другой архитектурой нельзя найти "срез", где будет видно выученное пространство состояний? вангую, что можно. в любой глубокой сети оно должно быть размазано по промежуточным слоям, но если есть свертки -- то в свертках (окнах фильтров) где-то должно просматриваться.. интуитивно кажется так.
Ну не знаю, не знаю.. ) Например, по моему опыту: * поиск PostGIS в Postgres по колонке типа мультиполигон с spatial-индексом, в итоге, прилично обгоняет поиск Elastic-а по geojson. У нас было ~80 млн полигонов, и в итоге даже до включения векторного кэширования мы отзывчиво выбирали окно и обновляли карту с сотнями/тысячами полигонов в поле видимости. * по часовой/против часовой -- довольно часто встречающаяся ошибки в данных -- некоторые полигоны (или их "дырки") от поставщиков неизбежно будут "битыми", "не в ту сторону" -- и это нужно все равно валидировать и конвертировать при индексации. оставить "на ответственности" поставщиков -- значит потерять контроль над качеством данных * в том же самом PostGIS из-коробки готовые высоко-оптимизированные реализации ST_simplify с тем же дугласом с пекером, (которые вы никогда не обгоните другими реализациями) и еще гора механизмов для развития гео-функционала в будущем, и использовать его было легко -- поэтому мы насколько помню симплифицировали "на лету", не теряя и не обрезая никаких данных (это грех, вообще))) * "такой контракт есть, он называется GeoJSON" -- смысл его в том, чтобы делиться данными, передавать их между системами. Это не формат для хранения или даже передачи во внутреннем апи на фронт, если речь о большой ГИС. Имхо. * стиль отображения? это же мусор. это пусть решается на фронтенде. зачем хранить/передавать это рядом с геоданными?)) плоские структуры всегда быстрее вложенных в глубину структурированных данных. разве нам не нужен перфоманс здесь?
и т.п... В общем, по моему мнению, это решение стратегически тупиковое.
чтобы реализовать
nullable|dateвалидацию?факт "в скраме нет ни слова" прям очень кайфово резонирует с фактом "ни разу за 15 лет не видел чтобы было иначе".. )) в лучшем случае, мудрое руководство просто дает возможность команде периодически "расслабиться" в стиле "ну, давайте, ладно, этот спринт на рефакторинг".. (только роадмап рефакторинга не забудьте подготовить))))
а от него только доска, да и та из канбана..)))
"возьми и прилети".. вот это какая-то глупость. мне даже кажется, что он специально это сделал. чето-там, например, "просчитал" и решил ввязаться в публичный/судебный спор с правительством. ну никто так не протупил бы -- это надо просто забыть или решить что "на денёк обойдется"!) я только поем и все, чесслово..
лет 10+ назад генерировал так синонимы доменов, через google translate)
2 млн -- это ничто. надо иметь возможность подать туда, например, всю актуальную нормативную базу какой-нибудь страны, чтоб,ы получить юриста. или любое подобное применение. так что 2млн -- это, как раз, чтобы хоть компании смогли пользоваться как-то.
думаю, для начала они обеспечили все-таки технологическое преимущество -- блокчейн не только для функций валюты, а все любые прочие применения (потенциально)-- и это создало у пользователей веру в его уникальность и перспективность и действительно появились не-валютные применения -- и валюта тоже раскрутилась до статуса "второй после"..
привет. ну "упаковка софта" -- не совсем то, о чем я говорю. для разработки, имхо, докер это в первую очередь "воспроизводимое окружение". поэтому, в самом начале статьи, мне действительно _стало понятно_, что это так или иначе, проблема конфигураций.. (далее все увлекательно и я дочитал даже, но интрига "как починить" для меня была раскрыта)) об этом и была шутка! (но, кажется, меня не все поняли).
а, вообще, я и правда считаю контейнеризацию одной из "серебрянных пуль" современной разработки. что же касается бд прода -- то, наверное, тогда уж managed (опять же в воспроизводимой среде).
документация "сверху" (как хотят) -- в конфлюенсах и вордах, а документация "снизу" (как есть) -- в репах и маркдаун. пока так практикуем.. вроде норм.
PS: только plantUml сильно серьезно, в итоге оказалось, зато mermaid выручает быстро накидать схему, что происходит, какие-небудь sequence diagram и т.п.
не в докере?!!!) ну тогда все понятно.
ну и главное... мимикрировать под кого? под конкурентов, про которые уже достроверно известно об их тесном сотрудничестве с анб?) смешно. ни вотсапу ни сигналу доверия просто ноль. а вот телеграму -- больше ноля)
все так говорят ("избыточное доверие"), но подумайте, я вот прикинул -- ни разу не использовал защищенные чаты, однако выбираю телеграм за удобство и скорость/отзывчивость. мне кажется, большинство тоже.
аналогично, -- я хотел довольно сложную функцию на генераторах или итераторах в функциональном стиле, и с серией прототипов и уточняющих правок с моей стороны, все получилось, пожалуй, быстрее у нас вместе, чем если бы я писал "руками" самостоятельно.
это не может не работать).. если включить отбор)
ну, в смысле, строгая матмодель с эвристиками и формулами, по идее внутренней картины мира не имеет, точнее эта картина просто внешняя -- в голове автора(ов) матмодели. )
а любая нейросеть, да.. очередное подтверждение принципиального сходства с биологическими нс.
любого на основе статистики)
в смысле, везде там, где происходит отжиг, сжатие, оптимизация полной статистики в ее компактную форму.
т.е. вывод -- выучивают. но, вроде бы, не только трансформеры!? разве для эффективно обученных сетей с другой архитектурой нельзя найти "срез", где будет видно выученное пространство состояний? вангую, что можно. в любой глубокой сети оно должно быть размазано по промежуточным слоям, но если есть свертки -- то в свертках (окнах фильтров) где-то должно просматриваться.. интуитивно кажется так.
Ну не знаю, не знаю.. ) Например, по моему опыту:
* поиск PostGIS в Postgres по колонке типа мультиполигон с spatial-индексом, в итоге, прилично обгоняет поиск Elastic-а по geojson. У нас было ~80 млн полигонов, и в итоге даже до включения векторного кэширования мы отзывчиво выбирали окно и обновляли карту с сотнями/тысячами полигонов в поле видимости.
* по часовой/против часовой -- довольно часто встречающаяся ошибки в данных -- некоторые полигоны (или их "дырки") от поставщиков неизбежно будут "битыми", "не в ту сторону" -- и это нужно все равно валидировать и конвертировать при индексации. оставить "на ответственности" поставщиков -- значит потерять контроль над качеством данных
* в том же самом PostGIS из-коробки готовые высоко-оптимизированные реализации ST_simplify с тем же дугласом с пекером, (которые вы никогда не обгоните другими реализациями) и еще гора механизмов для развития гео-функционала в будущем, и использовать его было легко -- поэтому мы насколько помню симплифицировали "на лету", не теряя и не обрезая никаких данных (это грех, вообще)))
* "такой контракт есть, он называется GeoJSON" -- смысл его в том, чтобы делиться данными, передавать их между системами. Это не формат для хранения или даже передачи во внутреннем апи на фронт, если речь о большой ГИС. Имхо.
* стиль отображения? это же мусор. это пусть решается на фронтенде. зачем хранить/передавать это рядом с геоданными?)) плоские структуры всегда быстрее вложенных в глубину структурированных данных. разве нам не нужен перфоманс здесь?
и т.п... В общем, по моему мнению, это решение стратегически тупиковое.
ну, формат тут "невиновник"