• Black Friday 2017 глазами IT и разработчиков. Как мы выдержали черную пятницу при увеличении трафика в 10 раз
    0
    Ну так, а какие критерии вы для себя выбрали для ручного управления, и почему именно их?
  • Автоматическое тестирование веб-интерфейсов в компании Virto Commerce
    +1
    Все-таки объясните, у тех, у кого вместо AngularJS самописный фреймворк+React нре получится использовать Protractor вообще? Или будут какие-то сложности? Если да, то какие?
  • Javascript-фреймворки: должен остаться только один
    0
    Слушай, ну, я мало сейчас имею отношения к проекту. Ребята там переехали на новую версию Angular, сделали шину сообщений общую для всего проекта. Они довольны. Мы как раз будет релизить скоро ооочень большую веб-консоль на нем. Визуально отзывчивость интерфейса после ExtJS стала сильно приятнее.
  • Ransomware набирает силы
    0
    Давайте разберемся как именно не совестим. Мы тестировали внутри компании, все работает. Скорее всего, имеет место некое ложное срабатывание со стороны Symantec, наш продукт не делает ничего такого, чтобы антивирусы были с ним не совместимы.
    Что касается сервер-сайд защиты: Windows-клиент защищен, откат занимает секунды, если не меньше. Чтобы зашифрованные копии залились в облако, синхронизация должна сработать в те доли секунды, пока несколько файлов зашифрованы (до срабатывания эвристик). Шанс, что такое произойдет, практически нулевой.
  • Ransomware набирает силы
    0
    Я сам лично столько раз попадал в разные неприятности в IT-сфере, что не привык надеяться на «дядю». Мой лично опыт такой что «мы наняли — они разберутся» заканчивается при первом же фейле либо печально, либо очень печально. Отвественность за потери там весьма условная.
  • Ransomware набирает силы
    0
    Привет. Говорить про 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

    Можно найти еще кучу подобных примеров. Так что, скорее, все-таки растет, чем падает.
  • Видео докладов с Techleads Meetup #1
    0
    Хорошая тематика, жаль что раньше такого митапа не было.
  • Javascript-фреймворки: должен остаться только один
    0
    Новые вещи — да, но приходится и поддерживать существующие, их плавно мигрируем, но медленно, т.к. проектов много и все они большей частью на ExtJS
  • Javascript-фреймворки: должен остаться только один
    0
    А кто сказал что одно безаппеляционно лучше второго или наоборот?
    Ну, по этим двух компонентам хорошо видно отличия в религии одного от второго фреймворка, если брать конкретно компненты, 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 вероятен.
  • Javascript-фреймворки: должен остаться только один
    0
    я написал ребятам, пойду еще раз напомню
  • Javascript-фреймворки: должен остаться только один
    0
    Культура написания кода во многом определяет результат.
    Если предлагается делать плохо — большинство сделает плохо.
  • Javascript-фреймворки: должен остаться только один
    0
    Это уже надо просить веб-команду написать вам ответ, щас попрошу, надеюсь, согласятся.
  • Javascript-фреймворки: должен остаться только один
    0
    Любой доклад не является руководством к действию, а лишь поводом к размышлению.
    Готовое решение было выбрано коллегиально, уже большой командой, и оно тоже потребовало много изучения, допиливания, и переделки архитектуры. Так что просто кол-во костылей стало меньше, ибо саппортить их большое кол-во не очень хотелось.

    С Angular2 мучений было еще больше, просто по итогу по совокупности факторов выбрали его.
  • Javascript-фреймворки: должен остаться только один
    0
    Я не понял. Я и есть автор доклада. Написал же, что в итоге поддерживать собственное решение занимало силы, и придумали, по сути, как сократить издержки, используя Angular2. Меньше самописных решений так.
  • Javascript-фреймворки: должен остаться только один
    0
    JSX — ужасное смешение всего в кучу, имхо. Мы еще кодга тестовый проект запиливали с двумя экранами уже эту мешанину было сложно читать.
  • Javascript-фреймворки: должен остаться только один
    0
    Судить о том, что нет проблем в огромной сложной области исходя из того, что есть один подход к тестированию одного конкретного фреймворка мягко говоря наивно.
    Попробуйте запилить действительно большой проект с Redux, возможно вы поймете, что это очень нишевый фреймворк.

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

    Можно попробовать позвать его что-нть рассказать.
  • Javascript-фреймворки: должен остаться только один
    0
    Дело не в тормозах, каких-то диких сложностей не было, просто код разрастался, синтаксис этот специфичный итд
  • Javascript-фреймворки: должен остаться только один
    0
    не слышал ни разу
  • Javascript-фреймворки: должен остаться только один
    0
    сильно не рассматривали, т.к. не было стабильной версии, и популярность была около нуля. И никто из нас про него и не слышал особо.
  • Javascript-фреймворки: должен остаться только один
    0
    напиши в личку или на мыло
  • Javascript-фреймворки: должен остаться только один
    +1
    Большинство технологий не умирает, а становится «нишевыми».

    image
  • Javascript-фреймворки: должен остаться только один
    +1
    Честно говоря маловероятно, т.к. внутрення тулза и опенсор-продукт — разные вещи по степени приложения усилий.
    Щас пилим активно Angular 2 вместо React.
  • Javascript-фреймворки: должен остаться только один
    0
    Конечно. Текст мне не прислали на вычитку =(
  • Javascript-фреймворки: должен остаться только один
    0
    Нет, цель экономии была, но совершенно в другом — перестать параллельно разрабатывать на зоопарке технологий, т.к. это постоянно жрало кучу ресурсов у каждого отдела в отдельности, и при этом качественного скачка вида «вот эти трое делают ядро продукта, а эти трое — UI» быть не могло. Специализация, и более специлиализированные рзработчики, шаринг знаний, шаринг ресурсов — вот, что хотел менеджмент.
  • Javascript-фреймворки: должен остаться только один
    +2
    Мы долго пытались жить с immutable.js, но в итоге это был оверкилл, вместо него сформировали одно простое правило — не изменять данные во View-слое, и immutable.js был смело выпилен.
  • Javascript-фреймворки: должен остаться только один
    0
    Знал про него, но сильно не смотрел ввиду малой популярности. Этот вопрос был весьма важен для нас.
  • Javascript-фреймворки: должен остаться только один
    +2
    Честое слово, это всё всё равно вкусовщина, но основных причин было три:
    1. Крайне редко бывают вещи в которых я не могу разобраться за день — и это был именно такой случай — трудно понять быстро с высоты птичьего полета как что работает, и как сделать быстро какое-нть тестовое одностраничное приложение
    2. Никто из команды ничего про него не знал, и энтузиазмом изучать не горел
    3. Шаблонизатор был так себе — как делать анимации или локализацию было непонятно

  • Javascript-фреймворки: должен остаться только один
    +1
    Посмотрел, очень похоже на внутренние документы которые я делал.
    Много людей после доклада подходили и говорили «во, знакомо до зубовного скрежета, у нас также итд итп»
  • Javascript-фреймворки: должен остаться только один
    0
    И в итоге все равно все это было задвинуто в 2016-м когда появился стабильный Angular 2.
    Как я и писал выше — количество самодельных вещей всегда должно регулироваться наличием ресурсов у команды на их поддержку и развитие.
  • Javascript-фреймворки: должен остаться только один
    +1
    Нет, самое сложное в докладе не освещено — это как я все это дело задвигал и «продавал» сотоварищи соседним отделам, подчиненным и начальству. :-)
  • Javascript-фреймворки: должен остаться только один
    0
    Knockout UI library — плохо… React тоже UI library c ваших слов — но это хорошо. В чем же тогда по-вашему разница между феймворком и библиотекой?


    То, что это фрейворк или UI-библиотека — не имеет отношения к «понравилось» или «не понравилось».
    Я в самом начале доклада написал, что не буду подробно останавливаться на том, почему не подошло, потому что это будет война религий и закидают помидорами.

    Одним из важных моментов был тот, что технология не популярна.

    Фактически кодер может лепить html почти также как статику, притом добавить байндинг разработчику несложно и позднее и кодеру этот байндинг не мешает во время последующего редактирования.

    На текущий момент звезды сложились так, что верстальщика и не появилось, верстает самый опытный в этом чел из команды, и он же и пишет код для UI-виджетов, с которыми работает эта верстка.

    А html темплейт в JS-коде в React приложениях меня например как-то удручает…

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

    Angular будет вечно пытаться заткнуть магией недостатки JS и DOM.

    Это тоже меня сильно расстраивает, т.к. в версии 2 появилась еще самодельная реализация Shadow DOM, и с CSS это дает кучу геморроя. Внятного способа создать застилизировать вложенный компонент из родительского так и нет. В общем, костылей стало больше.
  • Javascript-фреймворки: должен остаться только один
    +4
    Забегая вперед стоит сказать, что описываемая в докладе работа делалась в 2015-м, и сейчас, в 2016-м AngularJS2 получил богатую документацию, примеры, стал стабильным и т.д.
    И в итоге, столкнувших с очередным набором проблем, которые нужно было решать руками, мы таки в итоге выбрали AngualrJS 2 вместо React'а, это было коллективное и сомысленное решение с идеей, что лучше пусть будет «потупее или позапутанней», но меньше собственного кода поддерживать и развивать, больше доков и примеров, проще и меньше учиться.

    Хотя для Angular2 тоже пришлось придумать более стандартизованную архитектуру, и набор правил как можно и нельзя делать.

    Сами по себе костыли и самоделки, которые действительно ускоряют разработку, сделанные с умом хороши, но в масштабах боьлшой компании всегда приходится находить баланс между своими и сторонними решениями, в условиях когда много сил на поддержку собственных выделять не получается.
  • Javascript-фреймворки: должен остаться только один
    +1
    Все зависит от степени генерализации вопроса. С точки зрения владельцев бизнеса вопрос «на какой технологии делать веб-продукты компании, если наши программисты, в принципе, могут разобраться в любой из них?» вполне резонен и адекватен.

    Особенно в нашем случае, когда UI-пакет ExtJS нам не очень-то подходил, т.к. дизайн и поведение UI-контролов у нас другие.

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

    Ведь в реальной жизни купить станок не всегда экономически выгоднее.
  • Тонкие места в React.js
    0
    У меня не получалось, попробуй, может в новых версиях что-то изменилось…
  • Composer — the right way
    0
    К сожалению, есть и печальная тенденция с пакетами, я ее замечал в среде javascript и python-разработчиков, когда у любого мало-мальски простого проекта 15 зависимостей, и среди них юмор типа «debug»: "~2.1.1", «serve-favicon»: "~2.2.0" (реальнй пример из Kibana4).
    Так что есть и тенденция в работе предпринимать усилия по избавлению от такой «лапши».
  • Composer — the right way
    +4
    В общем случае — нет, не стоит, именно для этого придумана модуляризация и package-менеджеры.
    Но как только возникает или потребность переделки(доделки) чужого кода или жесткие бизнес-требования, что «должно работать из коробки в любой момент, мы не можем что-то скачивать из инета» и все такое — тогда да, стоит хранить рядом.
    Как и у любой более-менее серьезной инженерной задачи решения есть разные, зависящие от обстоятельств.
  • Открытие хакспейса «Сталь»
    +1
    О, спаисбо за обзор. Круто.
  • Электронный журнал «Радиоежегодник» — Выпуск 34. Путеводитель по Arduino
    0
    Спаисбо, очень интересно.