Еще одно практическое подтверждение книги Прохорова "Русская модель управления". Разделы "Планирование работ" и "Заключение" прям первые страницы введения книги. Рекомендую всем кто не читал.
Эх, если бы еще на груминги эти модели можно было звать :)
А так ждем новых и более удобных плагинов для популярных IDE c элементами ИИ. Кстати если у кого есть список плагинов для VS, VS Code, intellij idea и прочих, то буду признателен на ссылку
Не очень частный кейс, но может быть актуально, например, для справочников.
использует всего 64 бита (для bigint)
Увидев две цитаты выше вспомнил кейс из практики. У нас в одном легаси-приложение, попавшем к нам на редизайн, Id/PK справочников делали bigint, но значений там было обычно не более 100, а обычно и нескольких десятков. Но проблема в том что они связывались с таблицей типа "item" или "entity" у которых были внешние ключи на десятки справочников. И эти внешние ключи были тоже bigint разумеется.
А таблицы "item" или "entity" содержали миллионы записей. Как следствие они все содержали десятки bigint колонок с внешними ключами на справочники. То есть если одна из таблиц "item" содержит хотя б 10 внешних ключей на такие справочники, то мы получим 10 * 8 байт * 1000000 (число записей) = 8 * 10 ^ 7 = 80 МБайт информации. У нас таких таблиц было штук 25. Но если предположить что их хотя бы 5, то мы получим 5 * 80 Мбайт = 400 Мбайт в одной базе подобных внешних ключей. С учетом что мы использовали полные бэкапы раз в сутки и они хранились иногда до полугода, то набегал приличный бесполезный объем данных. За месяц могло набежать 12 ГБ. Конечно если вы в облаке как SaaS то проблем почти нет, а если как IaaS или у вас свои сервера, то надо внимательно следить за свободным местом на диске. А об этом как обычно забывают)) честно скажу забывали и мы и наши опсы )
Хотя если б для Id/PK справочников использовать хотя бы int (4байта), то можно итоговые 12ГБ "перегруза" перевести в 6ГБ, а если smallint (2 байта) то в 3ГБ. Tinyint использовать наверное уже рискованно, но тоже можно рассмотреть.
Это я все к чему ?) К тому что bigint способ хранения PK наверное самый популярный но далеко не самый эффективный. По хорошему нужно проводить мини анализ при его использование от таблицы к таблице. И не слушать крики коллег из разряда "у нас все Id это bigint".
Давным давно хотел провести анализ с списком рекомендаций, когда использовать bigint когда int когда smallint и так далее. Но так и сделал. Если об этом подумаете вы, раз уж взялись за эту тему, то будет замечательно )
Это конечно, поразительно, когда программисты и просто высококвалифицированные профессионалы думают, что то, что подходит сегодня им подойдет всем. И вот мы получаем попытки адаптировать lynda, pluralsight для школьников!
Т.е. ресурсы которыми пользуются инженеры с опытом работы или студенты профильных направлений адаптируются для школьников! Мне кажется это не совсем верно, т.к. людям до 18 лет нужно немного по другому структурировать и подавать учебную информацию. Всему свое место, друзья!
Именно по этому в университетах работают преподаватели, а в школах — учителя. Вроде значения слов похожи, но есть нюанс.
Это-то да. Но вам придется переписывать API под graphQL. А если бы появился HTTP/2, то вам вообще ничего не надо делать. Запросы как летели так и будут лететь, а там пусть за них сервер отвечает. Для legacy очень хорошо. А таких проектов как всегда очень много
Мне кажется, что классический REST отлично жил бы с протоколом HTTP/2 (https://habrahabr.ru/post/308846/). Новый протокол бы решил главную проблему REST — большое число запросов, т.к. позволил бы посылать их в одном TCP- соединение. Но так как HTTP/2 задерживается, то и начали появляться Odata, GraphQL и прочее. Это всё Отличные инструменты, но новый протокол бы был очень кстати. Все-так HTTP1.1 уже скоро 20 лет будет.
Ну это тоже верно и никак моему первому комментарию не противоречит.
В Бизнес-анализе девушек значительно больше чем в разработке. Тоже вполне ясно почему. Разработка более тяжелое и более творческое направление. А анализ требует больше усидчивости (оформление ТЗ, встречи с заказчиком и т.д.), внимания к мелочам + повышенной коммуникабельности.
Со специальностями кстати так же обстоит: «Информатика-экономика», «информатика и английский» это чуть ли не профильный путь для аналитиков. Диплом + 4 месяца курсов бизнес-анализа и вот вам готовый спец.
В общем то моя мысль была больше о специальностях ВУЗовских, чем о гендерном признаке.
Тут осторожней. Во многих которых нельзя разглашать вопросы и прочие подробности с собеседований. Если будете об этом писать, то согласуйте с начальством.
Это классическая итория. «Информатика-экономика», «информатика и английский» это просто базовые специальности для тестирования (по моему городу по крайней мере). Причин несколько:
1. В большинстве случаев знаний для глубокой разработке там не дают. Обычно кто хочет больше кодить идет на другие специальности.
2. Дают неплохие high level знания.
3. Большинство народу на таких специальностях девушки. А у них усидчивость больше и как результат выше эффективность в работе тестера (я в наши дни не обязательно мануального).
У нас в конторе подобные специальности рекрутеры мониторят начиная курса с 3. Так что можно сказать что вы попали по профилю.
Цена конечно не маленькая. Но я все равно собираюсь. Вопрос — есть какой-то гид с советами для тех кто приезжает в город только на dotNext? Я Питербург почти не знаю. Было бы полезно прикинуть что и как еще до приезда…
Если есть. Пока мы лишь предполагаем. Ваш вариант не опробовался. Тут ещё задача сгенерировать валидный Regex из 100k ключевых слов. Представляю как он будет выглядеть
хммм… такой вариант не изучался. Стоит попробовать. На мой взгляд если Regex сам создает префиксное дерево, то это уже не оптимизация а low code development какой-то)) Когда раньше разбирался с принципом работы и выполнения Regex то всё было намного проще (рекурсия и всё). Хотя по тестам производительности, которые делал раньше у меня не было ощущения что там что-то большее
Теперь понял ваш вопрос! Вариант интересный, но не забывайте, что у нас 20k-100k ключевых слов. Подобный Regex будет весьма сложным. Насколько я помню принцип работы регулярных выражений из примеров в томике Страуструпа, то в их работе лежит рекурсивный принцип (могу ошибаться). А любая рекурсия это увеличенный расход памяти. При сложном Regex да и на большом объеме документа (а он большой) могла банально закончиться память.
P.S. Прогонял всё-таки не я, а автор. Обращаю внимание что это перевод. Я не могу присваивать себе заслуги автора :) Кстати автор оригинала (Vikash) очень коммуникабельный человек, если у вас будут интересовать более глубокие детали, то можете и его смело спрашивать. Мне он отвечал в течении нескольких часов.
arty К сожалению немного не понял вопрос. Если вы имеете ввиду на сколько подобный Regex будет медленней чем простой (описанный в статье), то таких сравнений тут не проводилось.
Проблема была в том, что даже простой Regex уже выполнялся неприемлемо долго.
что конкретно? Если вы про время, которое потребуется на обновление кода для поддержки многопоточности, то немного. Т.к. проще всего в каждый отдельный поток загонять поиск/замену по отдельному документу. Каждый поток будет работать только с одним документом. Остальные ему не нужны. Корпус ключевых слов можно шарить между потоками, так как он в процессе работы приложения не меняется.
А результаты работы поиска агрегировать,
А результат работы замены просто выгружать и сохранять в новый документ.
Сама задача довольно проста для распараллеливания.
а вам не кажется, что вы широкую нишу взяли? может лучше было бы делать универсального робота, но в какой-то определенной области. Допусти для расфасовки. А уж что он будет фасовать: мешки, стеклотару или свежую рыбу можно было бы настроить
Еще одно практическое подтверждение книги Прохорова "Русская модель управления". Разделы "Планирование работ" и "Заключение" прям первые страницы введения книги. Рекомендую всем кто не читал.
Пал Каляля забыли еще. Куда без него.
И кстати, мне показалось или этот пост был в ленте "Разработка" ?)
Эх, если бы еще на груминги эти модели можно было звать :)
А так ждем новых и более удобных плагинов для популярных IDE c элементами ИИ. Кстати если у кого есть список плагинов для VS, VS Code, intellij idea и прочих, то буду признателен на ссылку
"Берём список из самых популярных паролей" и добавляем к ним год рождения админа или опса
Увидев две цитаты выше вспомнил кейс из практики. У нас в одном легаси-приложение, попавшем к нам на редизайн, Id/PK справочников делали bigint, но значений там было обычно не более 100, а обычно и нескольких десятков. Но проблема в том что они связывались с таблицей типа "item" или "entity" у которых были внешние ключи на десятки справочников. И эти внешние ключи были тоже bigint разумеется.
А таблицы "item" или "entity" содержали миллионы записей. Как следствие они все содержали десятки bigint колонок с внешними ключами на справочники. То есть если одна из таблиц "item" содержит хотя б 10 внешних ключей на такие справочники, то мы получим 10 * 8 байт * 1000000 (число записей) = 8 * 10 ^ 7 = 80 МБайт информации. У нас таких таблиц было штук 25. Но если предположить что их хотя бы 5, то мы получим 5 * 80 Мбайт = 400 Мбайт в одной базе подобных внешних ключей. С учетом что мы использовали полные бэкапы раз в сутки и они хранились иногда до полугода, то набегал приличный бесполезный объем данных. За месяц могло набежать 12 ГБ. Конечно если вы в облаке как SaaS то проблем почти нет, а если как IaaS или у вас свои сервера, то надо внимательно следить за свободным местом на диске. А об этом как обычно забывают)) честно скажу забывали и мы и наши опсы )
Хотя если б для Id/PK справочников использовать хотя бы int (4байта), то можно итоговые 12ГБ "перегруза" перевести в 6ГБ, а если smallint (2 байта) то в 3ГБ. Tinyint использовать наверное уже рискованно, но тоже можно рассмотреть.
Это я все к чему ?) К тому что bigint способ хранения PK наверное самый популярный но далеко не самый эффективный. По хорошему нужно проводить мини анализ при его использование от таблицы к таблице. И не слушать крики коллег из разряда "у нас все Id это bigint".
Давным давно хотел провести анализ с списком рекомендаций, когда использовать bigint когда int когда smallint и так далее. Но так и сделал. Если об этом подумаете вы, раз уж взялись за эту тему, то будет замечательно )
Т.е. ресурсы которыми пользуются инженеры с опытом работы или студенты профильных направлений адаптируются для школьников! Мне кажется это не совсем верно, т.к. людям до 18 лет нужно немного по другому структурировать и подавать учебную информацию. Всему свое место, друзья!
Именно по этому в университетах работают преподаватели, а в школах — учителя. Вроде значения слов похожи, но есть нюанс.
В Бизнес-анализе девушек значительно больше чем в разработке. Тоже вполне ясно почему. Разработка более тяжелое и более творческое направление. А анализ требует больше усидчивости (оформление ТЗ, встречи с заказчиком и т.д.), внимания к мелочам + повышенной коммуникабельности.
Со специальностями кстати так же обстоит: «Информатика-экономика», «информатика и английский» это чуть ли не профильный путь для аналитиков. Диплом + 4 месяца курсов бизнес-анализа и вот вам готовый спец.
В общем то моя мысль была больше о специальностях ВУЗовских, чем о гендерном признаке.
1. В большинстве случаев знаний для глубокой разработке там не дают. Обычно кто хочет больше кодить идет на другие специальности.
2. Дают неплохие high level знания.
3. Большинство народу на таких специальностях девушки. А у них усидчивость больше и как результат выше эффективность в работе тестера (я в наши дни не обязательно мануального).
У нас в конторе подобные специальности рекрутеры мониторят начиная курса с 3. Так что можно сказать что вы попали по профилю.
P.S. Прогонял всё-таки не я, а автор. Обращаю внимание что это перевод. Я не могу присваивать себе заслуги автора :) Кстати автор оригинала (Vikash) очень коммуникабельный человек, если у вас будут интересовать более глубокие детали, то можете и его смело спрашивать. Мне он отвечал в течении нескольких часов.
Проблема была в том, что даже простой Regex уже выполнялся неприемлемо долго.
А результаты работы поиска агрегировать,
А результат работы замены просто выгружать и сохранять в новый документ.
Сама задача довольно проста для распараллеливания.