Ну так, а какие критерии вы для себя выбрали для ручного управления, и почему именно их?

Все-таки объясните, у тех, у кого вместо AngularJS самописный фреймворк+React нре получится использовать Protractor вообще? Или будут какие-то сложности? Если да, то какие?

Слушай, ну, я мало сейчас имею отношения к проекту. Ребята там переехали на новую версию Angular, сделали шину сообщений общую для всего проекта. Они довольны. Мы как раз будет релизить скоро ооочень большую веб-консоль на нем. Визуально отзывчивость интерфейса после ExtJS стала сильно приятнее.

Давайте разберемся как именно не совестим. Мы тестировали внутри компании, все работает. Скорее всего, имеет место некое ложное срабатывание со стороны Symantec, наш продукт не делает ничего такого, чтобы антивирусы были с ним не совместимы.
Что касается сервер-сайд защиты: Windows-клиент защищен, откат занимает секунды, если не меньше. Чтобы зашифрованные копии залились в облако, синхронизация должна сработать в те доли секунды, пока несколько файлов зашифрованы (до срабатывания эвристик). Шанс, что такое произойдет, практически нулевой.

Я сам лично столько раз попадал в разные неприятности в IT-сфере, что не привык надеяться на «дядю». Мой лично опыт такой что «мы наняли — они разберутся» заканчивается при первом же фейле либо печально, либо очень печально. Отвественность за потери там весьма условная.

Привет. Говорить про 2018 год пока рано, потому что любые эпидемии развиваются по синусоиде – всплеск/спад. Активность киберпреступников разнится от месяца к месяцу. Например, в начале 2018 года может наблюдаться некий спад, потому что плохие парни отдыхают, а к осени будет большой рост.

За 2017 год все отмечают рост, например www.forbes.com/sites/tonybradley/2018/01/31/ransomware-and-cryptomining-spiked-in-2017-according-to-report/#32fb23d87bff

www.spamtitan.com/blog/ransomware-growth-in-2017

Можно найти еще кучу подобных примеров. Так что, скорее, все-таки растет, чем падает.

Хорошая тематика, жаль что раньше такого митапа не было.

Новые вещи — да, но приходится и поддерживать существующие, их плавно мигрируем, но медленно, т.к. проектов много и все они большей частью на ExtJS

А кто сказал что одно безаппеляционно лучше второго или наоборот?
Ну, по этим двух компонентам хорошо видно отличия в религии одного от второго фреймворка, если брать конкретно компненты, ReactJS, конечно, выглядит намного лучше, и я в целом ему отдаю предпочтение, но такого рода шаблоны

<span [ngClass]="{'ui-autocomplete ui-widget':true,'ui-autocomplete-dd':dropdown,'ui-autocomplete-multiple':multiple}" [ngStyle]="style" [class]="styleClass">
            <input *ngIf="!multiple" #in pInputText type="text" [ngStyle]="inputStyle" [class]="inputStyleClass" 
            [value]="value ? (field ? resolveFieldData(value)||value : value) : null" (input)="onInput($event)" (keydown)="onKeydown($event)" (blur)="onModelTouched()"
            [attr.placeholder]="placeholder" [attr.size]="size" [attr.maxlength]="maxlength" [attr.readonly]="readonly" [disabled]="disabled"
            [ngClass]="{'ui-autocomplete-input':true,'ui-autocomplete-dd-input':dropdown}"
            ><ul *ngIf="multiple" class="ui-autocomplete-multiple-container ui-widget ui-inputtext ui-state-default ui-corner-all" (click)="multiIn.focus()">
                <li #token *ngFor="let val of value" class="ui-autocomplete-token ui-state-highlight ui-corner-all">
                    <span class="ui-autocomplete-token-icon fa fa-fw fa-close" (click)="removeItem(token)"></span>
                    <span class="ui-autocomplete-token-label">{{field ? val[field] : val}}</span>
                </li>
                <li class="ui-autocomplete-input-token">
                    <input #multiIn type="text" pInputText (input)="onInput($event)" (keydown)="onKeydown($event)" (blur)="onModelTouched()">
                </li>
            </ul
            ><button type="button" pButton icon="fa-fw fa-caret-down" class="ui-autocomplete-dropdown" [disabled]="disabled"
                (click)="handleDropdownClick($event)" *ngIf="dropdown"></button>
            <div class="ui-autocomplete-panel ui-widget-content ui-corner-all ui-shadow" [style.display]="panelVisible ? 'block' : 'none'" [style.width]="'100%'" [style.max-height]="scrollHeight">
                <ul class="ui-autocomplete-items ui-autocomplete-list ui-widget-content ui-widget ui-corner-all ui-helper-reset">
                    <li *ngFor="let option of suggestions" [ngClass]="{'ui-autocomplete-list-item ui-corner-all':true,'ui-state-highlight':(highlightOption==option)}"
                        (mouseenter)="highlightOption=option" (mouseleave)="highlightOption=null" (click)="selectItem(option)">
                        <span *ngIf="!itemTemplate">{{field ? option[field] : option}}</span>
                        <template *ngIf="itemTemplate" [pTemplateWrapper]="itemTemplate" [item]="option"></template>
                    </li>
                </ul>
            </div>
        </span>

я имел удовольствие по нопытности и в JSX делать, все зависит от задачи и подкованности разработчика.

Если брать именно обычный какойнть сайт с обычным какимнть списком товаров на продажу, с анонсом цен и какихнть скидок, вполне подобный трудночитаемый мегашаблон и на JSX вероятен.

я написал ребятам, пойду еще раз напомню

Культура написания кода во многом определяет результат.
Если предлагается делать плохо — большинство сделает плохо.

Это уже надо просить веб-команду написать вам ответ, щас попрошу, надеюсь, согласятся.

Любой доклад не является руководством к действию, а лишь поводом к размышлению.
Готовое решение было выбрано коллегиально, уже большой командой, и оно тоже потребовало много изучения, допиливания, и переделки архитектуры. Так что просто кол-во костылей стало меньше, ибо саппортить их большое кол-во не очень хотелось.

С Angular2 мучений было еще больше, просто по итогу по совокупности факторов выбрали его.

Я не понял. Я и есть автор доклада. Написал же, что в итоге поддерживать собственное решение занимало силы, и придумали, по сути, как сократить издержки, используя Angular2. Меньше самописных решений так.

JSX — ужасное смешение всего в кучу, имхо. Мы еще кодга тестовый проект запиливали с двумя экранами уже эту мешанину было сложно читать.

Судить о том, что нет проблем в огромной сложной области исходя из того, что есть один подход к тестированию одного конкретного фреймворка мягко говоря наивно.
Попробуйте запилить действительно большой проект с Redux, возможно вы поймете, что это очень нишевый фреймворк.

Мы для React разрабатывали параллельно аж три разных вида тестов.

Да, на Redux запиливал тестовый проект.
Для сложных приложений, с болшим кол-вом вложенных экранов Redux не подходит.
Он очень прост, и специально упрощен, сделать ну хоть какую-то динамику (например, открытие вспылвающих окон с частями приложения) было очень сложно. Основная беда для большого приложения как раз в том, что все данные в одно месте, и работать с огромной «елкой» данных очень неудобно.

В итоге да, но проект уже курирует другой человек, а мне приходится помогать с более сложной задачей.

Можно попробовать позвать его что-нть рассказать.

Дело не в тормозах, каких-то диких сложностей не было, просто код разрастался, синтаксис этот специфичный итд

не слышал ни разу