Есть такое понятие как технологический стэк. Необходимо отталкиваться именно от него.

Если в вашем личном технологическом стэке нет FE (HTML+CSS, JavaScript) то не делайте кастомные FE решения. Если в вашем личном технологическом стэке нет PHP, то не берите WordPress. Используйте, то что вы и так знаете.

Если у вас нет опыта с хостингом или вы не хотите заморачиваться, то рассмотрите варианты готовых решений:

• Medium
• dev.to
• GitHub Pages

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

Вообщем, ждем от вас следущий пост на dou «Покритикуйте мой блог».

Это не галера, а так шлюпка.

Константин, вы уверены, что речь идет именно о 90% покрытие юнит тестами? В ангуляре есть два разных инструмента для тестирования:

• юнит тесты на Karma без браузера. Используется для тестирования бизнес логики
• end-2-end тесты на protractor с браузером. Используется для тестирования user-flow

Дальше о каком уровне покрытия идет речь:

• фич
• юзер кейсов
• строчек кода

Если же не углубляться в ваш конкретный случай, то мое мнение о JS/TS коде:

• для библиотек (внутренних или опенсорус): 100% покрытие как на юнит тестах, так и на e2e
• для SPA приложений: 0-20% юнит тестами для бизнес-логики, и 30-50% e2e для фич

Ни одна платежная система не дает удобства сопоставимого с кэшем/картами. Поэтому берите для карточку для микроплатежей в нужной валюте из Украины и кэш.
А вот по получения и снятию денег сейчас лучше всего себя показывает Payoneer. Например, знакомый в прошлом месяце на Кипр с euro карты снял в банкомате 2000 euro заплатив 6. Немного детальней:

• Обслуживание 3$ в месяц
• 3.15$ снятие налички в банкомате
• Бесплатные карточки в нужной валюте
• Возможность получения денег на локальный банковский счет (USA — ACH, EU — SEPA, England — BACS). Заказчики это просто обожают.
• Переводы на свой счет в банке или на карту
• 25$ рефералка для тебя и приглашеного человека, после того как он получить свою первую 1000$, Моя реферальная cсылка

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

Я слушаю книги из моего read-list. Возможно, когда нибудь руки дойдут оформить его так же как это сделал Мигуцкий, но пока это просто проект в things. В мой список книга чаще всего попадает во время конференций или нетворкинга. Я люблю спрашивать мнение людей о книгах.
В этом списке не обязательно новые книги, хорошую книгу стоит перечитать переслушать снова спустя 2-3 года.

Покопался в заметках. Вот список по софт-скилам, который может вас заинтересовать:

1. Henry Mintzberg, Managinghttps://www.amazon.com/Managing-Henry-Mintzberg/dp/1605098744
2. James C. Collins, любая книга en.wikipedia.org/wiki/James_C._Collins
3. Ицхак Адизес, любая книга
4. Clay Christensen www.amazon.com/...​-Successful/dp/1422196577
5. www.amazon.com/...​ison-Wesley/dp/0321637704
6. Стивен Кови, The Seven Habits of Highly Effective People
7. Management 3.0: Leading Agile Developers, Developing Agile Leaders. Jurgen Appelo
8. Макс Батырев — "45 татуировок менеджера«www.mann-ivanov-ferber.ru/books/paperbook/tattoos
9. www.amazon.com/...​ther-Others/dp/1591845327
10. www.amazon.com/...​nchard-Ph-D/dp/074350917X
11. Архипенков: «Управление программными проектами»
12. Джефф Сазерленд: «Scrum. Революционный метод управления проектами»
13. Том Де Марко: «Deadline»
14. PMBoK Дэниел Пинк: «Драйв»
15. Том Де Марко: «Вальсируя с медведями»
16. «Управление проектами для чайников» coollib.com/b/279290/read
17. Глеб Архангельский, Тайм-драйв www.mann-ivanov-ferber.ru/books/mif/005
18. www.amazon.com/...​ing-Out-Box/dp/1576759776
19. www.amazon.com/...​orth-George/dp/1119082943
20. Никогда не ешьте в одиночку и другие правила нетворкинга (К.Ферацци)
21. Мотивация на 100%, Светлана Иванова
22. Договориться можно обо всем, Гэвин Кеннеди
23. Помогите им вырасти или смотрите, как они уходят. Беверли Кей и Джулия Джулиони
24. Обнимите своих клиентов, Джек Митчелл
25. Я слышу вас насквозь, Марк Гоулстон.

Привет, Олег. Спасибо. У каждого своя дорога. Написал тебе в личку в Facebook.

Если я правильно вас понимаю, вы считаете что разработчик должен только писать код. Такая точка зрения имеет право на жизнь, особенно в Outsource. Мне она не близка, я считаю, что разработчик должен решать проблемы бизнеса с помощью кода. Поэтому код я пишу треть времени, а остальное время помогаю коллегами-разработчикам или выясняю детали проблемы, которую необходимо решить.

1) Чи можете порадити якісь конкретні матеріали, для ознайомлення з методикою «Ключ», щоб компактно та ефективно ?

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

В свое время я знакомился с этой методикой по вот этой ссылке www.koob.ru/aliev Тренингов не проходил, хотя слышал что они дают больший результат. Буду рад вашему отзыву.

2) Яки у Вас технічні плани на майбутнє ? Вдосконалення у напрямку Node.js ?

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

В начале года планировал пройти сертификации от Cloud провайдеров (AWS, Google Cloud, Azure), но отзывы коллег и мой опыт показывают, что это не влияет при трудоустройстве.

В любом случае навык/знания, которые не используются ежедневно забываются. Поэтому учеба ради учебы бессмысленна.

Вот более короткая цитата:

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

О что-то новенькое. Посмотрю.

Лайк за правильную статью

1. Формулировка. Мне кажется вам нужна система не реального времени, а близкая к реальной. С системами реального времени работают программы и счет там идет на миллисекунды, пример: биржевые боты, автопилоты автомобилей, и так далее. У вас же конечный пользователь человек, веб как никак. Задержку в 0.5-2 секунды вас вполне устроит. Верно?
2. Подход — сквозная событийная модель реализованная с помощью реактивного программирование. Наиболее популярные реализации на разных языках — ReactiveX. В случае другого подхода вы не сможете иметь задержку сопоставимую с задержкой сети/реакции человека. Поддерживать вашу систему с таким подходом будет значительно проще, чем с объектной моделью.
   
3. FrontEnd может быть реализован на любом из тройки современных фреймворков. Angular 2+ имеет под капотом RxJs, React нужно стоит брать вместе с Mobx вместо Redux или припиливать RxJs, аналогично Vue с Rx. Тут лучше смотреть по разработчикам. Для MVP можно брать даже PureJS.
   
4. Протокол коммуникации server<->client очень важный вопрос. Учитывая плотный поток данных вам он нужен один протокол на обновления и на получения начального состояния. То есть забрать начальные данные по REST, и сделать подписку по WS нельзя. У вас будут или дублироваться события или терятся.
   Если у вас поток данных только от сервера, то берите SSE. Он отлично работает и решает проблему подписок, синхронизации состояния ложиться на протокол. Только убедитесь, что сможете прикрутить http2 без него легко упереться в ограничение количества соединения между браузером и сервером.
   Если нужен двунаправленный поток, то вам WebSockets.
   Подробней habr.com/post/120429
   
5. BackedEnd любой технологический стэк для реализации веб сервера с поддержкой WS/SSE и интеграции с C кодом по сокетам. Определитесь, можете ли вы терять события. Это подскажет, что будет у вас single source of truth о прошедших событиях — какая-то база данных или in memory веб-сервера. С помощью RxGO/RxPY можно будет легко агрегировать события для отдачи на FE.
   Вы в списке почему-то не указали мой любимый Node.js. Я бы рекомендовал рассмотреть и его. Там удобные Stream для реактивного программирования.
   
6. Масштабирование, если оно конечно потребуется, необходимо будет делать с использование Event Bus паттерна, то есть внедрять RabbitMQ, Nats и производить рапределиние потока событий уже через них

1. PMI VS PMP. Согласен.
2. Мне казалось, что результаты вашего экзамена доступны только вам. Это в институте есть красный-синий диплом и вкладыш с оценками, а тут нет.
   Или я ошибаюсь и можно посмотреть разбаловку конкретного человека, а не только факт сдачи PMP?

3. Пока рано об этом судить, так как менеджмент работает в гораздо большем уровне неопределенности, чем DevOps и соответственно результат отложенный.

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

4. Я получил новые знания, уверенность в своих силах работать с большим проектом и желание это сделать.

   Вы хороший менеджер :) Только я хочу конкретики.
   Скажем в ходе первого полугодия, когда вы готовились, вы применяли новые знания? Какой-то процесс появился/изменился? Что об этом думают ваши коллеги подчиненные?

5. А потом пришел и сказал — «ну я ж теперь вон сколько сэкономил, а поднимите-ка мне ЗП на $500?» ;)

   Пример с DevOps был приведен, чтобы подтвердить идею вашей статьи «профильная сертификация это хорошо». В той ситуации счет за месяц существенно изменился и этим заинтересовался клиент. Как я думаю, это была инициатива менеджера, возможно, клиента, но точно не инженера.
   С таким же успехом, я мог привести пример коллеги, который готовился к IELTS и за пару месяцев разницу стало слышно во время стендапа.

Большее всего я хотел бы узнать о зримом для наблюдателя эффекте от PMP. Можно даже в виде отдельной статьи! Вы интересно пишите.

Константин, отличный подход к обучению!
У меня есть ряд вопросов:
1) PMP это в первую очередь организация, сертификация действительна 3 года. Какие планы? Как будете поддерживать знания и подтверждать статус? И будете ли?
2) Чем по факту отличается ваш результат above target от target? Для достижения такого результата вам пришлось глубоко разобраться в темах, которые вам не были нужны и вряд ли пригодятся.
3) Какие последствия сертификации? Что вы, текущий проект, компания получили в замен потраченных сотен часов на подготовку? Приведу пример: DevOps на одном из проектов начал готовиться к сертификации по AWS, узнал новое, поднастроил сервера и уменьшил затраты с 2к $ до 500$ в месяц. Сертификация за счет компании, +500 без смены проекта.

Да, просматриваю. Причем не только репозитории, но и gist-ы.

Очередное подтверждение, что писать код психологически комфортней, чем работать с людьми.

Это же явно пятничный пост!

Просто не успокоюсь, пока не поделюсь с кем то

 Чем именно ты хотел поделиться? Тем что на конкретном проекте, интересуются малозначимой с твоей точки зрения тонкостью работы промисов?

С моей точки зрения, на проекте, где код написан на промисах, а не на async/await это не тонкость, а базовое знание. Без его понимания, ты не сможешь отлавливать в нужном месте цепочки промисов ошибки. Ниже писали об этой проблеме промисов — их паршивой читаемости. Поэтому, скорее всего вопрос был абсолютно обоснован.

А может ты хотел поделить тем, что все

Все прошло ужасно

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

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

О canvas
Если вы хотите поиграться/поучиться c canvas за счет средства заказчика, то берите сanvas
Если вы хотите сделать работающий продукт, то не берите canvas, так как вы замучаетесь с поддержкой мобильных браузеров.

О технологиях
1. Составьте список требований.
2. Погуглите библиотеки. Возможно в ходе просмотре библиотек вы добавите, что-то в свои требования.
3. В таблице заполните какие из библиотек реализуют ваши требования.
4. Обсудите с PM-ом или заказчиком. Менеджеры любят выбирать какой из компонентов использовать. Можно смухливать и отбросить варианты, которые вам не нравятся, но могут быть выбраны. Если поймают, то потеряете доверие.

Вот мои требования:
— кросплатформенность (HTML5)
— наличие drug&drop
— быстрый поиск — первый же вариант означает стоп

deck-of-cards.js.org