Это конечно, поразительно, когда программисты и просто высококвалифицированные профессионалы думают, что то, что подходит сегодня им подойдет всем. И вот мы получаем попытки адаптировать 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 уже выполнялся неприемлемо долго.
что конкретно? Если вы про время, которое потребуется на обновление кода для поддержки многопоточности, то немного. Т.к. проще всего в каждый отдельный поток загонять поиск/замену по отдельному документу. Каждый поток будет работать только с одним документом. Остальные ему не нужны. Корпус ключевых слов можно шарить между потоками, так как он в процессе работы приложения не меняется.
А результаты работы поиска агрегировать,
А результат работы замены просто выгружать и сохранять в новый документ.
Сама задача довольно проста для распараллеливания.
а вам не кажется, что вы широкую нишу взяли? может лучше было бы делать универсального робота, но в какой-то определенной области. Допусти для расфасовки. А уж что он будет фасовать: мешки, стеклотару или свежую рыбу можно было бы настроить
Обеспечивая бурный рост Dodo IS, мы нередко предпочитали скорость разработки всему остальному. Иногда это происходило в ущерб системной логике, архитектуре и инфраструктуре.
У меня приятель в Dodo работал. Рассказывал, что подобные «ускорения» приводили к тому, что js и css писали прямо в cshtml файлах в массовом порядке. Описанная в статье проблема была конечно архитектурная, а не тактическая, но симптомы на лицо. Он ушел из Dodo, потому что боялся что «ускорения» к чему-то подобному приведут. Надеюсь выводы сделаны и в дальнейшем у Dodo будет рост качества кода и безотказности системы! А пицца и так вкусная)
Я бы переименовал статью на «поговорим о SOLID на примере js». C учетом развития веб-мира мне кажется SOLID принципы можно попробовать расширить на CSS или HTML. Концептуальные мысли на это есть, но вот формальных принципов не хватает пока. Никто не встречал таких идей где нибудь?
Блистательно! Видно, что в верстке автор большой профи. :epmty для меня в новинку. Полезная вещь для больших систем, где контролы отображаются/скрываются через CMS
+1. Всему свое место. Вообще Ангуляр просто так не вводится, т.е. если вы уж решили вводить ангуляр то стройте под него приложение, а не цепляйте на ходу, а используйте jquery
Т.е. ресурсы которыми пользуются инженеры с опытом работы или студенты профильных направлений адаптируются для школьников! Мне кажется это не совсем верно, т.к. людям до 18 лет нужно немного по другому структурировать и подавать учебную информацию. Всему свое место, друзья!
Именно по этому в университетах работают преподаватели, а в школах — учителя. Вроде значения слов похожи, но есть нюанс.
В Бизнес-анализе девушек значительно больше чем в разработке. Тоже вполне ясно почему. Разработка более тяжелое и более творческое направление. А анализ требует больше усидчивости (оформление ТЗ, встречи с заказчиком и т.д.), внимания к мелочам + повышенной коммуникабельности.
Со специальностями кстати так же обстоит: «Информатика-экономика», «информатика и английский» это чуть ли не профильный путь для аналитиков. Диплом + 4 месяца курсов бизнес-анализа и вот вам готовый спец.
В общем то моя мысль была больше о специальностях ВУЗовских, чем о гендерном признаке.
1. В большинстве случаев знаний для глубокой разработке там не дают. Обычно кто хочет больше кодить идет на другие специальности.
2. Дают неплохие high level знания.
3. Большинство народу на таких специальностях девушки. А у них усидчивость больше и как результат выше эффективность в работе тестера (я в наши дни не обязательно мануального).
У нас в конторе подобные специальности рекрутеры мониторят начиная курса с 3. Так что можно сказать что вы попали по профилю.
P.S. Прогонял всё-таки не я, а автор. Обращаю внимание что это перевод. Я не могу присваивать себе заслуги автора :) Кстати автор оригинала (Vikash) очень коммуникабельный человек, если у вас будут интересовать более глубокие детали, то можете и его смело спрашивать. Мне он отвечал в течении нескольких часов.
Проблема была в том, что даже простой Regex уже выполнялся неприемлемо долго.
А результаты работы поиска агрегировать,
А результат работы замены просто выгружать и сохранять в новый документ.
Сама задача довольно проста для распараллеливания.
У меня приятель в Dodo работал. Рассказывал, что подобные «ускорения» приводили к тому, что js и css писали прямо в cshtml файлах в массовом порядке. Описанная в статье проблема была конечно архитектурная, а не тактическая, но симптомы на лицо. Он ушел из Dodo, потому что боялся что «ускорения» к чему-то подобному приведут. Надеюсь выводы сделаны и в дальнейшем у Dodo будет рост качества кода и безотказности системы! А пицца и так вкусная)