latteo

Конкретно здесь проще, и я бы даже сказал, нужно сделать страницу на jquery =))

------------------------

Если же вас интересует как в принципе заменить jquery на vue, то постараюсь ответить.

1. Как и в случае jquery, ищем подключаем подходящий пакет. Например этот.

2. Аккордеон реализуется вручную парой строчек

<div>
  <h2 @click="toggle"></h2>
  <div v-if="stateOpen">
    Скрытое содержимое
  </div>
</div>

{
  data() {
    return {
      stateOpen: false,
    }
  },
  methods: {
    toggle(){
      this.stateOpen = !this.stateOpen;
    }
  }
}

Анимации раскрытия по вкусу, с помощью обёртки transition

3. Аналогично предыдущему пункту. 10 минут на реализацию.
4. Аналогично первому пункту.
5. Аналогично первому пункту.
6. Блин, ну тут то же самое =)) Мне нравится этот пакет: vue-form

Вот и всё. jQuery можно не подключать.

Понятие еnd-to-end обозначает всего-навсего классификацию тестов по уровню, на котором тестируется система, и, само по себе, ничего не говорит ни о том, какие конкретно должны быть эти тесты, ни о том, какую роль они играют в общей стратегии обеспечения/проверки качества и, также, не является методикой тестирования. (Методика - это совсем другое понятие.)

Для понимания сути этого понятия хорошо сравнить его с модульным ("нижний" уровень) и интеграционным ("средний") тестированием на каком-нибудь конкретном примере. Давайте рассмотрим некий сферический webshop в вакууме. Предположим, в нем есть 50 классов и для большинства из них написаны модульные тесты. Они проверяют исключительно функционал конкретного модуля (чаще всего, класса), т.е. тот, что зависит только от самого модуля и ни от чего чего более. Потом есть интеграционные тесты. Они проверяют корректность работы отдельных "модулей", если их собрать вместе согласно архитектурe. Например, работает ли правильно "Корзина", состоящая, в свою очередь, из 10 классов (предварительно проверенных модульными тестами), или "Корзина", подключенная к "Вебморде" и т.д. Где-то повыше в этой иерархии есть такие интеграционные тесты, которые проверяют конкретный функционал всей системы. Например, отправляется ли юзеру мейлом копия оплаченного заказа...

И вот тут начинается самое интересное для понимания того, что такое end-to-end тестирование! Можно представить себе тест, проверяющий, что соответствующий мейл генерируется и сбрасывается SMTP серверу. Если SMTP сервер не рассматривать, как часть разрабатываемой системы, то этот тест вполне можно назвать end-to-end тестом (послали кучку HTTP запросов через "Вебморду" и проверили сброс мыла на SMTP - все зашибись!). Однако, если настройки и эксплуатация SMTP сервера - часть проекта (например, заказана разработка webshop "под ключ"), может оказаться, что это мыло будет отфильтровано каким-нибудь спам-фильтром, превысит лимит почтового ящика пользователя... короче, не дойдет до него. Тогда этот же самый тест уже нельзя считать end-to-end, а нужно бы было написать тест, проверяющий приход мыла в POP3/IMAP ящик. (Опять же, если это действительно нужно! Ибо, в зависимости от конкретных функциональных и нефункциональных требований, архитектор и QA инженер вполне могут найти возможность обеспечить адекватный контроль качества и без такого теста.)

Таким образом, end-to-end тесты, это такие интеграционные тесты, которые воздействуют на систему через ее самые внешние интерфейсы и проверяют ожидаемую реакцию системы через эти же интерфейсы. Почему именно интеграционные? Потому, что это единственное, что можно о них сказать наверняка: они по определению не могут быть модульными тестами. А все остальное: являются ли они одновременно приемочными, нагрузочными или еще какими - зависит только от общих плана/стратегии тестирования и той роли, которые эти тесты в них играют.

Последние года 3 пользуюсь Appcelerator Titanium.
https://github.com/appcelerator/titanium_mobile

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

Чем он хорош?

Как и React Native и Xamarin он предоставляет возможность создания _нативных_ приложений, управляемых JavaScript, в отличии от Cordova/Phonegap.

Другой момент, в отличии от конкурентов в Appcelerator появилась возможность писать на JavaScript _нативный код_ ! который при помощи специального транслятора (Hyperloop) превращается в Java / Obj. C
Эта штука позволяет напрямую дергать нативное окружение, минуя бридж между виртуальной машиной V8 и системой, а так же использовать любые нативные фреймворки внутри вашего приложения.
https://www.appcelerator.com/mobile-app-developmen...

Есть MVC фреймворк Alloy:
docs.appcelerator.com/platform/latest/#!/guide/All...

Менеджер модулей:
gitt.io

Так же из коробки есть облачко, если не хочется писать сервер (я пользуюсь им, как бекапом):
docs.appcelerator.com/platform/latest/#!/guide/Mob...

Есть так же аналитика, бесплатный вариант порезанный, но мне хватает.

Добавлю:
Для моделей используется надстройка над Backbone:
docs.appcelerator.com/platform/latest/#!/guide/All...
Которая умеет синкаться с SQLite

Так же пользуюсь модифицированным app.tss из https://github.com/TNuzzi/wriststrap
(https://github.com/TNuzzi/wriststrap/blob/master/t...
плюс Jade/Pug (можно через Grunt в XML перегонять, но я пользуюсь Jade Watcher в WebStorm) и получаются симпатичные на мой вкус шаблоны:

Alloy
    ScrollView.w-fill.h-fill.lo-v(right=10, left=10).st-vertical  // lo-v == (layout='vertical'), w-fill == (width="FILL")
        Label#eventName.event-name.l-0

        View.lo-c(top=10)
            ImageView#photo.event-info-photo(onLoad="photoLoad")
            View.event-info-date-time
                Label#date.event-info-date-time-label.event-info-date
                Label#type.event-info-date-time-label.event-info-type
            Label#price.event-info-price

        Require#details(src='event/card/event_card_details')
        View.bottom-spacer

Если хочется просто запустить локальный сайт, аля Phonegap, просто кидаем в шаблоне WebView компонент:
docs.appcelerator.com/platform/latest/#!/api/Titan...
растягиваем по экрану: width="Ti.UI.FILL", height="Ti.UI.FILL"
в папку с assets добавляем папку с продакшн билдом вашего веб-проекта, и в WebView проставляем ссылку.
Получится та же Cordova, только с уровнем доступа выше, вы через EventListener-ы получите доступ к любым нативным функциям, без сторонних плагинов.

И напоследок канал в Слэк:
https://ti-slack.slack.com

Есть несколько вариантов.

js-to-native, нативное приложение с бизнес-логикой на js и нативными виджетами:

• react-native
  
• NativeScript — на выбор angular, с недавних пор vue, чистый js
  
• weex — аналог react-native для vue.js, из коробки так же работает под веб. С документацией пока грустновато, но народ работает.
  

Вроде как из этого react-native самый проработанный и стабильный. Имел дело только с ним, если это стабильно и проработанно, то в остальное даже страшно заглядывать (хотя NativeScript+ionic мне хвалили). Выглядит нативно на каждой платформе. Знания html и css по большей части не пригодятся: тэги/компоненты свои, css-свойства работают не все и не во всех сочетаниях.

webview, гибридное приложение, браузер на весь экран:

• cordova, старейшее живое решение
  

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

прочее:

• *.webmanifest и PWA, нечто среднее между установкой приложения и добавлением сайта в закладки.
  

По идее идеал, часто юзаешь сайт — типа ставишь приложение, редко — открываешь из браузера. У разработчика голова не болит как подружить веб, iOS и Android: везде выглядит и работает одинаково. На практике поддержка пока что пятнистая.

https://codepen.io/chaly7500/pen/zRazex

> Но такой способ мне не очень удобный показался. Как делать хот-фиксы тогда? Изменение одной буквы в коде — целый процесс.

В хорошем процессе это не проблема. Если изменение критичное вы просто деплоите старую версию (не откат, а именно деплой старой). Хот фиксы это уход от проблемы, а нее решение.

> В сети прочитал, что нужно использовать CI/CD, который будет скачивать последнюю версию из гита, устанавливать зависимости, тесты, перекачивать на сервер, разархивировать в отдельную папку, тесты, и в конце концов переключить симлинк вебрута на эту папку

У наиболее продвинутых ребят вся эта история уже делается (и довольно давно) используя docker. Вы можете хотя бы немного познакомиться с ним здесь guides.hexlet.io/docker/. Если докер для вас пока рано, то можно реализовать процесс используя Ansible и его специальный модуль docs.ansible.com/ansible/latest/deploy_helper_modu...

Там вы заодно увидите ответ на вопрос "что делать с состоянием".

> Что делать с БД? Что делать с загруженными файлами от пользователей? Копировать из предыдущей версии?

Состояние никак не связано с деплоем, оно должно быть шареное. Если у вас есть файлы от пользователей, то возможно вы захотите использовать aws s3. Как минимум про него надо знать.

Рекомендую заодно посмотреть вебинар про stateless vs statefull чтобы немного понимать эту тему: https://www.youtube.com/watch?v=WPCz_U7D8PI

Что сам читал:
1. Брюс Эккель - Философия Java
2. Корнелл Хорстманн - Java. Библиотека профессионала.
3. Элизабет Фримен и Эрик Фримен - Паттерны проектирования
4. Джошуа Блох - Java. Эффективное программирование
5. Роберт Мартин - Чистый код

Ну и что-нибудь поновее.

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

Стандартные решения:
1. самодокументируемый код, составленный так, что читающий может понять что для чего и в какой последовательности работает.
2. описание интерфейсов (назначение метода, тип/суть параметров и т.п.) в форме комментов в коде.
3. автоматическая документация (генерится из комментариев) - эффективно, только если сам код закрыт.
4. модульные тесты, фиксирующие требования к коду и демонстрирующие его использование.
5. описание высокоуровневого дизайна (High Level Design, HLD), описывающий какие элементы существуют, их взаимосвязь друг с другом и основные сценарии взаимодействия.

Работающая документация - это компромисс из этих практик, релевантный конкретной ситуации.

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

Есть множество вариантов реализации.
На машину ставится устройство, которое получает координаты с GPS-приемника и других датчиков (включая расходомеры для топлива и так далее). Данные сохраняются в буфере на устройстве. Потом они отправляются на сервер, либо HTTP-запросом, дергающим какой-то скрипт на сервере, либо просто через SMS, чтобы GSM-модем на сервере принимал эти SMS, а какой-то серверный софт принимает их и расшифровывает. Вот этот самый скрипт и кладет данные в базу простым SQL-запросом. Ничего сложного архитектурно, но множество мест, где можно сделать ерунду, от чего получится еще один говносервис подобного рода.

syslog в помощь.

Жрёт раму или цпу, система убивает.

Русский язык тоже не лишне бы подучить.

Школьного курса математики для большинства задач будет достаточно. Купите учебники с 1 по 11 класс и изучайте.

Как определитесь в сфере, там уже будете дальше копать (если молоды, то можно просто пойти в вуз из верхних 20% по РФ). В топ-вузах, на it-факультетах 2 года почти только тем и занимаются, что учат математику. Если не знаете зачем оно вам – лучше не теряйте времени больше, чем требуется для школьной программы. Быстро вы математику все-равно не изучите, поскольку cмысл изучения математики в трансформации мозга, что небыстрый процесс, хотя с другой стороны процесс этот лучше проходит в возрасте до 21 года. Поэтому если возраст ваш до 19 лет, то лучшие вузы страны по it-направлению ждут вас. Если вы ощутимо старше, или не тянете поступления в хороший вуз, то не стоит без прозрачной необходимости изучать дальше школьной программы. Но школьную программу по математике знать определенно стоит.