Junior React Developer - что нужно знать
1. Хорошее знание JavaScript. В React разработке используется ES6 и большинство экспериментальных фич еще не вошедших в стандарт.
2. Хорошее знание HTML и CSS. Кроссбраузерная верстка. Так же, хорошо иметь представление о том, что такое css-in-js.
3. Web APIs. Умение работать с объектной моделью документа(DOM) и все эти XMLHttpRequest, localstorage, cookie, history и прочее.
4. Хорошее знание API React. Вы должны хорошо знать React, знать его возможности, понимать основные концепции и уметь ответить на большинство типовых вопросов. Для этого достаточно хорошо изучить документацию, разобрать пару типовых проектов на github и попрактиковаться. Много полезной информации, приёмов и идей можно подчерпнуть из тематических статей и докладов. Так же, на просторах интернета можно найти подборки типовых вопросов, часто задаваемых на собеседованиях. В англоязычном сегменте их больше.
5. Redux. Уверенное знание API. API библиотеки до боли пост. Знать, что такое промежуточное ПО и зачем оно. Понимать базовые концепции архитектуры Flux. Все это есть в документации и многочисленных курсах.
6. Умение работать с менеджером пакетов npm на базовом уровне.
7. Node.js. Хотя бы уметь написать простейший express/koa сервер, который будет отдавать ваше приложение и статику.
8. Webpack. Базовые знания.
9. Умение работать с git. Хотя бы знать и уметь примерять команды: init, clone, add, commit, push, pull, merge, checkout.
10. Иммутабельность. Четкое понимание зачем это надо. Знание приемов иммутабельного изменения структур данных. Это есть в официальном туториале React.
11. Статическая типизация TypeScrpt/Flow. Для начала хватит самых основ и способности понимать чужой код.
12. Функциональное программирование. Хватит знаний полученных в процессе изучения JavaScript, а так же не помешает знать, что такое каррирование, чистые функции и рекурсия.
13. Базовые концепции ООП. Хватит знаний полученных в рамках изучения JavaScript.
14. Асинхронный код. Понимать как его правильно организовывать. Promise, async/await.
15. Сетевые протоколы передачи данных. Вполне хватит базовых знаний о http/https, о том, что такое заголовки и какие они бывают. Хорошо знать о том, что такое websocket.
16. За плечами должен быть хотя бы один учебный проект на React. Хватит типового тестового задания.
Примеры таких заданий: 1, 2, 3(сайт может быть не доступен на территории РФ, советую отрыть через VPN и посмотреть), 4, 5. Если подобного проекта у вас нет, то будьте готовы, что потенциальный работодатель предложит вам выполнить тестовое задание и только по его результату вас, может быть, пригласят на техническое интервью. Если напишите хорошо, вас скорей всего пригласят.
17. Желателен опыт создания типовых UI элементов. Например, чтобы не вызывало трудностей написать простой кастомный чекбокс. Куча примеров реализаций типовых элементов есть на codepen.
1. Хорошее знание JavaScript. В React разработке используется ES6 и большинство экспериментальных фич еще не вошедших в стандарт.
2. Хорошее знание HTML и CSS. Кроссбраузерная верстка. Так же, хорошо иметь представление о том, что такое css-in-js.
3. Web APIs. Умение работать с объектной моделью документа(DOM) и все эти XMLHttpRequest, localstorage, cookie, history и прочее.
4. Хорошее знание API React. Вы должны хорошо знать React, знать его возможности, понимать основные концепции и уметь ответить на большинство типовых вопросов. Для этого достаточно хорошо изучить документацию, разобрать пару типовых проектов на github и попрактиковаться. Много полезной информации, приёмов и идей можно подчерпнуть из тематических статей и докладов. Так же, на просторах интернета можно найти подборки типовых вопросов, часто задаваемых на собеседованиях. В англоязычном сегменте их больше.
5. Redux. Уверенное знание API. API библиотеки до боли пост. Знать, что такое промежуточное ПО и зачем оно. Понимать базовые концепции архитектуры Flux. Все это есть в документации и многочисленных курсах.
6. Умение работать с менеджером пакетов npm на базовом уровне.
7. Node.js. Хотя бы уметь написать простейший express/koa сервер, который будет отдавать ваше приложение и статику.
8. Webpack. Базовые знания.
9. Умение работать с git. Хотя бы знать и уметь примерять команды: init, clone, add, commit, push, pull, merge, checkout.
10. Иммутабельность. Четкое понимание зачем это надо. Знание приемов иммутабельного изменения структур данных. Это есть в официальном туториале React.
11. Статическая типизация TypeScrpt/Flow. Для начала хватит самых основ и способности понимать чужой код.
12. Функциональное программирование. Хватит знаний полученных в процессе изучения JavaScript, а так же не помешает знать, что такое каррирование, чистые функции и рекурсия.
13. Базовые концепции ООП. Хватит знаний полученных в рамках изучения JavaScript.
14. Асинхронный код. Понимать как его правильно организовывать. Promise, async/await.
15. Сетевые протоколы передачи данных. Вполне хватит базовых знаний о http/https, о том, что такое заголовки и какие они бывают. Хорошо знать о том, что такое websocket.
16. За плечами должен быть хотя бы один учебный проект на React. Хватит типового тестового задания.
Примеры таких заданий: 1, 2, 3(сайт может быть не доступен на территории РФ, советую отрыть через VPN и посмотреть), 4, 5. Если подобного проекта у вас нет, то будьте готовы, что потенциальный работодатель предложит вам выполнить тестовое задание и только по его результату вас, может быть, пригласят на техническое интервью. Если напишите хорошо, вас скорей всего пригласят.
17. Желателен опыт создания типовых UI элементов. Например, чтобы не вызывало трудностей написать простой кастомный чекбокс. Куча примеров реализаций типовых элементов есть на codepen.
Backend-Мастер - авторский блог про backend в телеграм.
Этот канал для тебя, если ты:
- учишь backend и языки программирования
- работаешь на Python / PHP / Ruby
- хочешь выйти на фриланс
- интересуешься Django / Laravel / Ruby on Rails
Этот канал для тебя, если ты:
- учишь backend и языки программирования
- работаешь на Python / PHP / Ruby
- хочешь выйти на фриланс
- интересуешься Django / Laravel / Ruby on Rails
Шпаргалка по работе с DOM #1
Создание элементов
document.createElement(tag) - создать элемент с тегом tag
document.createTextNode(txt) - создать текстовый узел с текстом txt
node.cloneNode(deep) - клонировать существующий узел, если deep=true то с подузлами.
Свойства узлов
node.nodeType - тип узла: 1(элемент) / 3(текст) / другие.
elem.tagName - тег элемента.
elem.innerHTML - HTML внутри элемента.
node.data - содержимое любого узла любого типа, кроме элемента.
Ссылки
document.documentElement - элемент <HTML>
document.body - элемент <BODY>
По всем узлам:
parentNode
nextSibling previousSibling
childNodes firstChild lastChild
Только по элементам:
Дети: children (В IE 8- также содержит комментарии)
Соседи, кроме IE8-: nextElementSibling previousElementSibling
Дети, кроме IE8-: firstElementChild lastElementChild
Таблицы
table.rows[N] - строка TR номер N.
tr.cells[N] - ячейка TH/TD номер N.
tr.sectionRowIndex - номер строки в таблице в секции THEAD/TBODY.
td.cellIndex - номер ячейки в строке.
Формы
document.forms[N/name] - форма по номеру/имени.
form.elements[N/name] - элемент формы по номеру/имени
element.form - форма для элемента.
Создание элементов
document.createElement(tag) - создать элемент с тегом tag
document.createTextNode(txt) - создать текстовый узел с текстом txt
node.cloneNode(deep) - клонировать существующий узел, если deep=true то с подузлами.
Свойства узлов
node.nodeType - тип узла: 1(элемент) / 3(текст) / другие.
elem.tagName - тег элемента.
elem.innerHTML - HTML внутри элемента.
node.data - содержимое любого узла любого типа, кроме элемента.
Ссылки
document.documentElement - элемент <HTML>
document.body - элемент <BODY>
По всем узлам:
parentNode
nextSibling previousSibling
childNodes firstChild lastChild
Только по элементам:
Дети: children (В IE 8- также содержит комментарии)
Соседи, кроме IE8-: nextElementSibling previousElementSibling
Дети, кроме IE8-: firstElementChild lastElementChild
Таблицы
table.rows[N] - строка TR номер N.
tr.cells[N] - ячейка TH/TD номер N.
tr.sectionRowIndex - номер строки в таблице в секции THEAD/TBODY.
td.cellIndex - номер ячейки в строке.
Формы
document.forms[N/name] - форма по номеру/имени.
form.elements[N/name] - элемент формы по номеру/имени
element.form - форма для элемента.
Тест на знание основ Vue JS
Можно выбрать 3 уровня сложности:
Начальный уровень
Средний уровень
Сложный уровень
На тест выделяется небольшой промежуток времени, а также после окончания теста вы сможете просмотреть результаты и ознакомиться с верными и неверными ответами.
Можно выбрать 3 уровня сложности:
Начальный уровень
Средний уровень
Сложный уровень
На тест выделяется небольшой промежуток времени, а также после окончания теста вы сможете просмотреть результаты и ознакомиться с верными и неверными ответами.
Каких знаний php для верстальщика будет достаточно?
1. Надо уметь выводить в шаблонах переменные.
2. Писать логические условия (если пользователь не авторизован, то показываем форму входа, если нет, то ссылку на личный кабинет).
3. Писать циклы (в шаблон передается переменная с массивом постов, верстальщик должен написать цикл для их отображения).
4. Надо знать базовое API языка, встроенные функции для работы с числами, массивами, строками, датами и тп.
5. Нужны знания синтаксиса объектов. Понимать не обязательно, главное знать как вывести содержимое.
1. Надо уметь выводить в шаблонах переменные.
2. Писать логические условия (если пользователь не авторизован, то показываем форму входа, если нет, то ссылку на личный кабинет).
3. Писать циклы (в шаблон передается переменная с массивом постов, верстальщик должен написать цикл для их отображения).
4. Надо знать базовое API языка, встроенные функции для работы с числами, массивами, строками, датами и тп.
5. Нужны знания синтаксиса объектов. Понимать не обязательно, главное знать как вывести содержимое.
Нужно ли использовать препроцессоры CSS?
Разумеется в препроцессорах нет никакой магии, и можно обойтись без них. но они делают вашу работу проще и вас продуктивнее.
Это удобная штука, не нужно ее бояться, не нужно бояться webpack, фреймворки, но и не нужно фанатеть, это просто инструменты.
1) Переменные.
2) Наследования
3) Вложенность
4) Авто-префиксы
Вот 4 основных причины для вас.
Разумеется в препроцессорах нет никакой магии, и можно обойтись без них. но они делают вашу работу проще и вас продуктивнее.
Это удобная штука, не нужно ее бояться, не нужно бояться webpack, фреймворки, но и не нужно фанатеть, это просто инструменты.
1) Переменные.
2) Наследования
3) Вложенность
4) Авто-префиксы
Вот 4 основных причины для вас.
Junior Front-End Developer Angular
Angular шпаргалка
1) Знания разметки HTML5 + CSS3;
2) Знание Angular;
3) Умение простой доработки дизайна – создания простого элемента интерфейса, который бы вписывался в общую концепцию уже готового дизайна;
4) Адаптивная верстка.
5) Опыт работы с Angular Material, SASS, LESS;
6) Знания JavaScript / TypeScript;
7) Опыт построения SPA;
8) Работа с Websocket + Node.JS;
Если нет проектов в портфолио, то сделайте и показывайте проект, в котором просто будет логин/логаут, регистрация, вход через соц. сеть (типа вконтакте), восстановление пароля. Если человек может сделать такой проект, как правило с остальными задачами проблем не будет.
Angular шпаргалка
1) Знания разметки HTML5 + CSS3;
2) Знание Angular;
3) Умение простой доработки дизайна – создания простого элемента интерфейса, который бы вписывался в общую концепцию уже готового дизайна;
4) Адаптивная верстка.
5) Опыт работы с Angular Material, SASS, LESS;
6) Знания JavaScript / TypeScript;
7) Опыт построения SPA;
8) Работа с Websocket + Node.JS;
Если нет проектов в портфолио, то сделайте и показывайте проект, в котором просто будет логин/логаут, регистрация, вход через соц. сеть (типа вконтакте), восстановление пароля. Если человек может сделать такой проект, как правило с остальными задачами проблем не будет.
Как при клике в любую точку на странице сделать переадресацию?
document.addEventListener('click', () => { window.location = 'ваш файл'})
WebAssembly заменит JS?
Уже сейчас (и довольно давно) можно компилировать в JS ту же джаву, Clojure, Scala и множество других вкусных и интересных языков. Не говоря уж о emscripten (на котором wasm пока что и работает).
Учите JS, потому что с webassembly неизвестно, что ещё получится. А во-вторых, даже если webassembly будет плотно использоваться, то это вовсе не значит, что JS куда-то исчезнет.
Уже сейчас (и довольно давно) можно компилировать в JS ту же джаву, Clojure, Scala и множество других вкусных и интересных языков. Не говоря уж о emscripten (на котором wasm пока что и работает).
Учите JS, потому что с webassembly неизвестно, что ещё получится. А во-вторых, даже если webassembly будет плотно использоваться, то это вовсе не значит, что JS куда-то исчезнет.
Создатели Ruby on Rails выпустили инструмент для отказа от JavaScript при разработке веб-приложений
Компания Basecamp уже успела создать одноимённый менеджер проектов и разработать Ruby on Rails. А сейчас она решила посягнуть на святое и выпустить Hotwire. На сайте проекта говорится, что это «альтернативный подход к созданию современных веб-приложений без использования JavaScript».
На сайте проекта заявляется, что Hotwire позволяет достигнуть «скорости одностраничного веб-приложения без написания JavaScript-кода». В том числе за счёт отправки «по проводам» HTML вместо JSON.
Компания Basecamp уже успела создать одноимённый менеджер проектов и разработать Ruby on Rails. А сейчас она решила посягнуть на святое и выпустить Hotwire. На сайте проекта говорится, что это «альтернативный подход к созданию современных веб-приложений без использования JavaScript».
На сайте проекта заявляется, что Hotwire позволяет достигнуть «скорости одностраничного веб-приложения без написания JavaScript-кода». В том числе за счёт отправки «по проводам» HTML вместо JSON.
Babel или Typescript? Есть ли смысл учить второй?
Не стоит придавать столь высокое значение новым технологиям. TypeScript и Babel сравнить можно, разве что в отношении того что их реализация предполагает прекомпиляцию JS.
Typescript - идет по другому пути.
Он более надежен по определению, так как значительная часть проверок выполняется еще до того, как код идет в реальный браузер.
Если вас устраивает функционал Typescript - это будет вполне себе целесобразно. Качество ваших проектов будет выше.
Если же вам по каким то веским причинам нужен ES6 - используйте Babel на здоровье.
Не стоит придавать столь высокое значение новым технологиям. TypeScript и Babel сравнить можно, разве что в отношении того что их реализация предполагает прекомпиляцию JS.
Typescript - идет по другому пути.
Он более надежен по определению, так как значительная часть проверок выполняется еще до того, как код идет в реальный браузер.
Если вас устраивает функционал Typescript - это будет вполне себе целесобразно. Качество ваших проектов будет выше.
Если же вам по каким то веским причинам нужен ES6 - используйте Babel на здоровье.
Стоит ли изучать Nuxt.js?
В Vue 3.0 это будет из коробки
Недостатки:
1) Он долго запускается при `nuxt dev` (мой блог запускается за 3-5 минут) и HMR обновляется в среднем 1-5 секунд (порой и дольше), даже если обновил просто template. Это больше всего напрягает.
2) После изменения кода, иногда папка `.nuxt` генерируется с ошибкой, приходится менять любую строчку в исходниках проекта чтобы опять запустить генерацию или порой полностью перезапускать Nuxt. Такая проблема была замечена не на всех проектах.
3) Бывает проблематично использовать модули которые не идут сразу на сервере и на клиенте, но это больше проблема SSR. Еще порой хочется получить сам nuxt контекст где store, router, плагины, но это нельзя сделать в некоторых местах, обычно эта проблема на клиенте. Например, на клиенте в store где state еще нет свойства window.$nuxt, нельзя обратится к плагину универсальных куков cookie-universal-nuxt и взять из куков значение и записать в state, а по другому к контексту nuxt не обратится. Store тяжело получить в самом store, порой это нужно.
4) Когда с ним использовал TypeScript, то иногда nuxt выдавал что типа (обычно интерфейса) не существует или другие ошибки типов, но этих ошибок на самом деле не было. Единственный выход — заново запускать nuxt dev и долго ждать, порой эта проблема возникала по несколько раз в течении 20 минут, приходилось перезапускать несколько раз.
В Vue 3.0 это будет из коробки
Недостатки:
1) Он долго запускается при `nuxt dev` (мой блог запускается за 3-5 минут) и HMR обновляется в среднем 1-5 секунд (порой и дольше), даже если обновил просто template. Это больше всего напрягает.
2) После изменения кода, иногда папка `.nuxt` генерируется с ошибкой, приходится менять любую строчку в исходниках проекта чтобы опять запустить генерацию или порой полностью перезапускать Nuxt. Такая проблема была замечена не на всех проектах.
3) Бывает проблематично использовать модули которые не идут сразу на сервере и на клиенте, но это больше проблема SSR. Еще порой хочется получить сам nuxt контекст где store, router, плагины, но это нельзя сделать в некоторых местах, обычно эта проблема на клиенте. Например, на клиенте в store где state еще нет свойства window.$nuxt, нельзя обратится к плагину универсальных куков cookie-universal-nuxt и взять из куков значение и записать в state, а по другому к контексту nuxt не обратится. Store тяжело получить в самом store, порой это нужно.
4) Когда с ним использовал TypeScript, то иногда nuxt выдавал что типа (обычно интерфейса) не существует или другие ошибки типов, но этих ошибок на самом деле не было. Единственный выход — заново запускать nuxt dev и долго ждать, порой эта проблема возникала по несколько раз в течении 20 минут, приходилось перезапускать несколько раз.
Под какие разрешения экрана готовить дизайн сайтов в 2021?
(320/360 - 1920)
1. Усложнять простое проще, чем упрощать сложное.
2. Сначала мобильные. P.S это не подразумевает обделить десктоп.
3. Перестать мыслить сетками и точными размерами.
4. Больше отзывчивости, больше относительных единиц, больше grid css.
5. Украшайки — в последнюю очередь.
6. Дизайн сразу в браузере. Да, дизайнить сайт сразу в браузере, использовать условные элементы, которые потом можно отрисовать уже в граф. редакторе. Чтобы дизайнить в браузере, соответственно изучить вёрстку + технологии анимаций в вебе. +доступность +производительность.
7. Фильтровать тренды.
(320/360 - 1920)
1. Усложнять простое проще, чем упрощать сложное.
2. Сначала мобильные. P.S это не подразумевает обделить десктоп.
3. Перестать мыслить сетками и точными размерами.
4. Больше отзывчивости, больше относительных единиц, больше grid css.
5. Украшайки — в последнюю очередь.
6. Дизайн сразу в браузере. Да, дизайнить сайт сразу в браузере, использовать условные элементы, которые потом можно отрисовать уже в граф. редакторе. Чтобы дизайнить в браузере, соответственно изучить вёрстку + технологии анимаций в вебе. +доступность +производительность.
7. Фильтровать тренды.
Продвинутый CSS
Какое-то время CSS оставался односторонним: один цвет, одно состояние, одно мгновение, одно устройство.
На протяжении многих лет были разработаны новые функции, которые изменяют взаимодействие, промежуточные состояния и даже время.
Псевдоклассы в CSS
Градиенты в CSS
Переходы в CSS
Анимация в CSS
Трансформация в CSS
Отзывчивость в CSS
Какое-то время CSS оставался односторонним: один цвет, одно состояние, одно мгновение, одно устройство.
На протяжении многих лет были разработаны новые функции, которые изменяют взаимодействие, промежуточные состояния и даже время.
Псевдоклассы в CSS
Градиенты в CSS
Переходы в CSS
Анимация в CSS
Трансформация в CSS
Отзывчивость в CSS
Что быстрее освоить: javascript + node.js или javascript + php?
Для новичков PHP проще. PHP вида "запрос-ответ-умер" прощает многое. Можно писать как угодно и при этом не иметь утечек памяти поскольку всё должно быть подчищено за разработчиком по завершению скрипта, а если нет, то проблема не ваша, а связующего ПО.
Node.js ничего не прощает, не понимаете как работает event loop считайте, что не понимаете в какой последовательности будет выполнен код. Возможны утечки, захват процессорного времени, неэффективное использование многоядерного процессора.
Но многие используют Javascript на клиенте, никогда не слышали про event loop, их код бесконечно ест память и большинство об этом даже не знают, что не мешает вешать себе регалии сеньоров и мидлов. Если похожий подход то можно прямо сейчас начать писать боевой код на node.js. Как-то оно всё равно будет работать.
Для новичков PHP проще. PHP вида "запрос-ответ-умер" прощает многое. Можно писать как угодно и при этом не иметь утечек памяти поскольку всё должно быть подчищено за разработчиком по завершению скрипта, а если нет, то проблема не ваша, а связующего ПО.
Node.js ничего не прощает, не понимаете как работает event loop считайте, что не понимаете в какой последовательности будет выполнен код. Возможны утечки, захват процессорного времени, неэффективное использование многоядерного процессора.
Но многие используют Javascript на клиенте, никогда не слышали про event loop, их код бесконечно ест память и большинство об этом даже не знают, что не мешает вешать себе регалии сеньоров и мидлов. Если похожий подход то можно прямо сейчас начать писать боевой код на node.js. Как-то оно всё равно будет работать.
Проверка уровня знаний JavaScript
Тесты на русском языке:
https://learn.javascript.ru/quiz
https://proghub.ru/t/js-basic
https://bakhirev.biz/demo/fdconf/
Тесты на английском языке:
https://www.tutorialsteacher.com/online-test/javascript-test
https://www.wscubetech.com/quiz-test-javascript
Тесты на русском языке:
https://learn.javascript.ru/quiz
https://proghub.ru/t/js-basic
https://bakhirev.biz/demo/fdconf/
Тесты на английском языке:
https://www.tutorialsteacher.com/online-test/javascript-test
https://www.wscubetech.com/quiz-test-javascript
Gulp vs Webpack, внятно и понятно
Нужно ли использовать Webpack с Gulp или вовсе, только Webpack?
Webpack - бандлер, который собирает модули. В модули могут входить как js-файлы так и css, шаблоны и т.д. и webpack умеет все это бандлить в один такой большой бандл (или разделять их по умному).. На этом его зона ответственности заканчивается. Но что же остается task раннерам в таком случае?
Да собственно для простых проектов и ничего. Для проектов посложнее - запуск тестов, различные рутинные действия. Например gulp deploy, gulp build который после бандлинга сделает нам билд всего и все в tar.gz и еще и запустит тесты. Ну и т.д.
Есть конечно "плагины" для webpack добавляющие функциональность task раннеров но как по мне это уже перебор.
Нужно ли использовать Webpack с Gulp или вовсе, только Webpack?
Webpack - бандлер, который собирает модули. В модули могут входить как js-файлы так и css, шаблоны и т.д. и webpack умеет все это бандлить в один такой большой бандл (или разделять их по умному).. На этом его зона ответственности заканчивается. Но что же остается task раннерам в таком случае?
Да собственно для простых проектов и ничего. Для проектов посложнее - запуск тестов, различные рутинные действия. Например gulp deploy, gulp build который после бандлинга сделает нам билд всего и все в tar.gz и еще и запустит тесты. Ну и т.д.
Есть конечно "плагины" для webpack добавляющие функциональность task раннеров но как по мне это уже перебор.
Шаблоны для верстальщика — канал на котором Вы найдете шаблоны, которые помогут прокачать Ваш навык вёрстки и пополнить Ваше портфолио реальными примерами.
Подписывайтесь 👈
Подписывайтесь 👈
Envato — стоит ли заходить?
Сейчас на envato стало очень сложно пробиться. Постоянно отказы, не соответствует качеству продукт и всё. Никаких объяснений, что именно не так. Деньги там реальные. Минус в том, что на приём проекта отталкиваются от дизайна, и можно получать хард реджекты(отказы), непонятно по какой причине очень долго.
Проще пробиться в App Store с простым приложением и по затратам меньше. В то же время, в категориях куча всяких посредственных товаров, добавляется и добавляется, как они проходят модерация - загадка.
В одной только категории 12 одинаковых товаров от 1 автора, т.е. меняется чуть цвет, название - и вперёд. Как этот автор проходит модерацию - загадка, но, что удивительно, всегда проходит модерацию.
Сейчас на envato стало очень сложно пробиться. Постоянно отказы, не соответствует качеству продукт и всё. Никаких объяснений, что именно не так. Деньги там реальные. Минус в том, что на приём проекта отталкиваются от дизайна, и можно получать хард реджекты(отказы), непонятно по какой причине очень долго.
Проще пробиться в App Store с простым приложением и по затратам меньше. В то же время, в категориях куча всяких посредственных товаров, добавляется и добавляется, как они проходят модерация - загадка.
В одной только категории 12 одинаковых товаров от 1 автора, т.е. меняется чуть цвет, название - и вперёд. Как этот автор проходит модерацию - загадка, но, что удивительно, всегда проходит модерацию.
