Ихрь постит в уютный бложик: заметки с тегом education

How to sync Obsidian between iOS devices

Sun, 15 Oct 2023 19:39:31 +0300

I’ve written a lot of notes since 2010, I really like methodologies like second mind and Zettelkasten, and as a consequence I really like Obsidian.

And many times I’ve seen people find solutions to synchronize different iOS/iPad OS devices without iCloud and Obsidian Sync. People use Apple Shortcuts and third-party tools like Working Copy to sync Obsidian via git, or use terminal emulators like iSH to mount the vault directory and sync it manually.

But Obsidian on mobile devices (yes, iOS too) supports community plugins.
And instead of reinventing the wheel, you can... just install the plugin you need.

Just go to Settings — Community Plugins — Browse. And install:

«Obsidian Git» for synchronization with git;
«Remote Save» to synchronize with S3/WebDav.

Yes, it works on iOS devices, it works natively and automatically on startup, you just need to enable it in the settings. And also you can add shortcut to Obsidian menu to call action you need.
Enjoy!

Диплом NaN. The end

Sat, 07 Jul 2018 17:57:04 +0300

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

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

После всего вот этого взял отпуск на пару недель (жаль, что он почти завершился), провел некоторые мероприятия (воркшопы и лекции), провёл практику у студентов, наигрался в игры и поконтрибьютил во всякие интересные проекты https://github.com/WebPurple.

Теперь надо намечать дальнейшие планы, отказываться от привычки играть в игры и изучать всякое новое, в планах есть погрузиться в Vue и PWA, а если брать бэкенд, то чуть глубже пощупать NestJS. Также, вероятно, стоит дочитать кучку начатых книг и, всё-таки, попробовать писать что-то осмысленное и конкретное в блок, но это — как пойдёт.

На этом можно завершить цикл публикаций про диплом, вернусь к нему через пару лет, когда буду писать магистерскую “диссертацию”.

Диплом 5. UI, FrontEnd

Sat, 03 Mar 2018 17:55:37 +0300

Со всякими сложностями, возникшими в начале написания клиентской части разобрались, теперь можно и поверстать.

Январь 2018

Разумеется, мне лень всё придумывать с нуля, поэтому я пошёл в гугл, затем перешел к посту на Hackernoon с подборкой UI-тулкитов для реакта. Сейчас что-то подберу и начну творить.

—

Самым популярным оказался Material-UI, его и возьмём, такой дизайн сейчас вроде модный, так что сойдёт.

—

Дока у них, конечно, странновата, хотя, может я где-то не там и как-то не так смотрю...

—

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

—

Только сейчас узнал, что `fetch` не уходит в `catch`, если сервер отдаёт не, на что потратил где-то полчаса, отыскивая причину возникающих ошибок. Подключил `axios`, не понимаю, почему сразу так не сделал.

—

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

—

Хотел начать с эвентов и их страниц, но всё-таки начну с юзеров, придумал ещё всякие таймлайны, лайф апдейт и всякие фичи, но их я, скорее всего, реализовывать не буду, а просто докину потом в текст диплома и презентацию как «возможные варианты развития».

—

По дизайну всё выходит ну очень не очень, но мне как-то лень что-то нормальное придумывать (да и не умею я в дизайн). От адаптива, вероятно тоже откажусь в итоговой версии, но это не точно.

—

Видимо, систему загрузки аватаров и подобного нужно будет как-то переписать...

—

Сделал редактирование профайлов, загрузку аватара — работает отлично, вот только в коде там всё ужасно, но стадия рефакторинга у меня запланирована на потом. Пока делаю PoC. Теперь бы нужно разобраться с изменением пароля... Вот это самое ужасное в данном случае. Ну, и, конечно, валидность введенных данных надо проверять так же как при регистрации и красиво подсвечивать.

—

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

—

Вчера в `app.use(express.static(’build’))` забыл дописать `/client`, из-за чего у меня файл сервера торчал наружу, фейл на фейле, хорошо, в прод это не пошло :wink:

—

<off_topic>
Думаю впилить сюда какую-то систему комментариев, однозначно не Disqus, а других вариантов особо и нет. Facebook’ом из моего окружения мало кто пользуется, у Twitter нет виджета комментариев, а ВК я просто не хочу.

Самый явный вариант — накостылить комментарии на основе Issues на GitHub, только тогда для комментирования нужен будет там аккаунт, но вот как раз это есть у всего моего окружения.

Идея годная, но с одной стороны, с другой — те, кто хотят что-то обсудить и так пишут мне, например, в Telegram, а обсуждение чего-то, что не относится к репозиторию в его issues — использование не по теме, да и вообще оверинжениринг выйдет какой-то.
</off_topic>

—

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

—

Выставил — всё поломалось. Не понимаю, почему, но всё где-то падает.

—

Кажется, я починил. Но почему оно сломалось, так и не понял.

—

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

—

Всё поправил, роль сыграл один злополучный `await` и вызов метода.
#np

—

Зачем-то запилил комментарии в блог (сюда), которые работают на основе... GitHub Gists.
Потестировать можно на посте «Каррирование в JS».
А сейчас — самое время писать часть диплома для работы с сущностями типа «эвент». Ну или подумать над идеей для хакатона.

—

Хватит лениться, пора запилить добавление эвента.

—

Отодвинул разработку на «когда-нибудь»...

—

Март 2018

Первым делом сделал возможность собрать докер-контейнеры. Теперь всё цивильно: 3 контейнера (nginx, mongodb, nodejs). Контейнер с nginx проксирует запросы на ноду и балансит нагрузку, внутри ноды крутится кластер процессов ноды под pm2. В целом неплохо. На эту тему написал бы отдельный пост, но пока особо времени нет.

Смысла распределять нагрузку nginx’ом пока нет, поэтому с nodejs только один контейнер

Теперь решил отказаться от Google-Material кита для React и перешёл на Ant Design. С формами тут всё гораздо лучше, логин и регистрацию накидал довольно быстро.

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

—

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

Технология блокчейн и её применение

Thu, 15 Feb 2018 17:50:43 +0300

С докладом про блокчейн, его достоинства, недостатки и хайп я выступил на WebPurple Meetup #25.

На форуме «СТНО-2018» в секции «Информационные системы и защита информации» я выступил с докладом «Применение технологии блокчейн в области защиты информации и его недостатки».

Ниже представлена тезисная статья (для научного сборника), которая посвящена самой технологии, базовым принципам работы и возможным способам использования в распределённых вычислениях и информационной безопасности веб-систем.

Введение

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

Блокчейн — цепочка блоков, представляющая собой связанный список. Его основные концепции: распределенность, одноранговость и защищенность. Распределенный “реестр” хранит историю всех операций между узлами одноранговой сети в виде блоков информации.

В общем случае каждый блок характеризуется следующими параметрами:

индекс;
временная отметка;
данные;
хеш текущего блока;
хеш предыдущего блока.

Схематичное представление блокчейна

Хешами называют результаты хеширования.

Хеширование — это преобразование массива входных данных в битовую строку фиксированной длины, выполняемое определённым алгоритмом^[1].

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

Блокчейн обеспечивает высокую надежность сохранности данных и прозрачность всех действий, в результате чего повышается уровень доверия участников сети друг к другу и к блокчейну.
Наиболее развитые области, в которых применяется технология блокчейн: финансы и налогообложение, проведение прозрачных процессов голосований, криптовалюты. Наиболее перспективны на данном этапе развития технологии областях распределённых вычислений BigData и информационной безопасности.

Применение блокчейна в области распределённых вычислений и BigData

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

Число вычислительных устройств в мире с хорошими показателями вычислительных мощностей постоянно растёт, однако “КПД” этих вычислительных мощностей падает. При среднестатистическом использовании персонального компьютера большую часть времени центральный и графический процессоры в лучшем случае используются на 30%.
Неиспользуемые мощности персональных компьютеров, серверов и даже смартфонов могут приносить пользу, производить вычисления и решать какие-то задачи, если использовать давно существующий подход распределённых вычислений.

Распределенные вычисления — способ решения трудоемких вычислительных задач с использованием нескольких компьютеров, чаще всего объединённых в параллельную вычислительную систему^[2].

Проблемой всех существующих систем распределенных вычислений является зависимость от какого-то управляющего центра. Задержки, вызванные особенностями работы сети интернет, большие нагрузки на системы провайдеров и особенности географического расположения узлов являются лишь малой частью проблем, возникающих при обработке данных, созданных на множестве независимых друг от друга устройств. Решением этой проблемы является предоставление устройствам возможности обмена данными друг с другом в режиме реального времени, что распределит нагрузку. В этом случае остаётся лишь одна крупная проблема — синхронизация и валидация различных узлов. С этой задачей и призван справиться блокчейн.

Распределённая сеть устройств на основе блокчейна

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

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

Схематичные представления различных типов сетей

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

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

Применение блокчейна в области информационной безопасности веб-систем

С точки зрения информационной безопасности, блокчейн — это технология, которая помогает шифровать все действия, выполняемые с файлом или объектом, в хеш. Фактически, это не совсем шифрованием, но оно не может быть отменено, изменено и или вскрыто простыми способами, в то же время все манипуляции с зашифрованными блоками остаются полностью прозрачными: всегда известно, какие транзакции были выполнены, когда и кем. Такой подход к обеспечению безопасности данных открывает новые возможности в области безопасности веб-приложений.

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

Блокчейн решает эту проблему, избавляя пользователя от необходимости постоянного использования личных данных для авторизации в системах, а компании от необходимости поиска надежного хранилища и организации его защиты. Все данные будут случайным образом разбиты на небольшие кусочки (чанки) и распределены по пользователям всей системы. Отдельный пользователь не сможет извлечь из отдельного чанка никакой информации, а злоумышленник не сможет собрать все чанки воедино.

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

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

У существующей системы DNS-серверов тоже есть проблемы с защищенностью информации, потому что они хранят ключи доступа в централизованном хранилище и часто почти полностью полагаются на кеширование. Эту проблему можно решить с помощью блокчейна, используя распределенную сеть ключей и ключевых узлов-серверов. В конечном счете, блокчейн защитит серверы от хакерских атак и сделает их практически недоступными для злоумышленников, а также снизит риски отказа в обслуживании в результате высокой нагрузки на централизованный сервер или нарушения целостности кеша.

Блокчейн — самое перспективное изобретение в области кибербезопасности последнего десятилетия. Вероятно, это произведет революцию существующих систем кибербезопасности, обеспечит гораздо более безопасный интернет на долгие годы и, в любом случае, запустит новый цикл эволюции индустрии.

Диплом 4. Redux, роутер, SSR

Sun, 28 Jan 2018 17:44:51 +0300

Сегодня я начинаю писать клиентскую часть диплома. Первым делом надо всё донастроить, сконфигурировать и связать с роутером и redux’ом.

Втащить Redux несложно, сложно его подключить нормально и прокинуть всё через роуты. Так ещё и ESlint ругается на код типа:

class App extends React.Component {
  methodName = () => {
    /*Говорит, что methodName undefined =/ */
  }
}

—

Окей, ESlint оказался как-то слишком старым, обновил — вроде всё завелось.

—

Так, вроде бы заработало, успел всё сломать и починить пару раз. `react-router-redux` заюзать всё-таки пришлось. Пока далеко от роутинга не ушёл, нужно серверный рендеринг сделать.

—

Серверный рендеринг + react + redux = вообще ад какой-то. Что-то то одно, то другое ломается, мануалы везде разные, ЧИТО ДЕЛАТЬ.

—

Сейчас, например, babel-node ну никак не хочет модключать стили в изоморфный компонент со стороны сервера.

—

Ладно, решил уже не заморачиваться с «горячей» отладкой SSR, поэтому его только после билда можно проверить. Что касается мануалов — самый подходящий оказался на [codeburst](https://codeburst.io/react-isomorphic-universal-app-w-nodejs-redux-react-router-v4-be80aa57dcaf). Теперь рендеринг на сервере работает, но вот правильно или нет я пока не совсем разобрался.

—

Удалил `react-router-redux`, ибо не так он уж мне и нужен. Я так-то пока не придумал, зачем мне вообще в этом проекте Redux.

—

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

—

Хм, опять же это всего диплом, а я не планировал делать SSR для кого-то кроме поисковых ботов, так что пока вообще всё неплохо идёт.

—

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

—

Поправил dev-сборку, а всё ломалось из-за того, что где-то там, через 2 файла подключался компонент со стилями, чего babel терпеть не желал. В процессе ещё со статикой нахватал проблем и gzip, но там я над фиксами долго думал по причине невнимательного чтения доков.

—

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

—

Больше они не работают, т. к. блог уже пару раз переехал

Под конец дня зачем-то добавил в блог Github emoji :sunglasses: (чуть-чуть пописал на jQuery).

А сейчас пора почитать что-то интересное и отдыхать, например, «REST is the new SOAP», а так же пара ответов «A Response to REST is the new SOAP» и «Still Going on REST is the new SOAP».

Диплом, часть 3. MongoDB, API, Cloudinary

Wed, 17 Jan 2018 17:35:20 +0300

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

—

Прикрутить базу оказалось несложно, работать с ней тоже проще простого. Начнём с написания авторизации пользователей.
В этот раз я решил юзать `passport.js` и ещё некоторые обвесы. Писать буду на основе своих существующих знаний и серии видео по написанию системы логина с использованием выше названной библиотеки.

В общем и целом объясняют не совсем так, как мне хотелось бы и как объяснял бы я именно взаимодействие NodeJS, работу Express. Но непосредственно по `passport.js` меня всё устраивает.

—

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

—-

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

export default (err, req, res, next) => ...
export default (err, req, res) => ...

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

—

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

—

После деплоя все вызовы API работают, это гуд. Прикручиваю токены.

—

Всё оказалось гораздо проще, и Passport мне вообще не нужен будет, ибо есть JWT. День в пустую.

—

Окей, с API логина и регистрации разобрались. Теперь накидаем простые варианты API и чуть расширим схемы моделей.
Конечно, я шифрую пароли bcrypt’ом. Сейчас объект юзера в БД хранится в примерно таком виде:

{
  "_id": {
    "$oid": "5a5cbe2425ac100014571bd4"
  },
  "login": "root",
  "password": "$2a$10$YWEDx35UrhtLOg1x2FPP5ezxPP7XSbFfuYsvpdWblGGbo9nqLLzZe",
  "email": "root@example.com",
  "__v": 0
}

—

Сделал API для юзеров. Вроде бы всё ок, нужно только продумать, как быть с аватарами и всякими такими файлами.

—

Серверная часть готова абсолютно, если исключить всякие особенности и, конечно, загрузку файлов.

—

Несколько часов промучался с загрузкой файлов, а все проблемы были в правах и неверных заголовках. Теперь вроде бы окей работает загрузка отдельных файлов в виде `form-data`. За это спасибо `Multer.js`. Теперь ещё впилю поддержку облака `cloudinary`.

—

Собирался накостылять своё решение, но вовремя нашёл `multer-storage-cloudinary.js`. Закинул в деплой, теперь осталось чуть-чуть протестировать.

Окончательная версия выглядит примерно так:

Routes.js

import express from 'express';
import checkToken from '../middlewares/checkToken';
import * as FileController from '../controllers/file';

const router = express.Router();
router.post('/avatar', checkToken, FileController.uploadFile('avatar'), FileController.uploadController);
router.post('/event', checkToken, FileController.uploadFile('event'), FileController.uploadController);

export default router;

Controllers.js

import path from 'path';
import multer from 'multer';
import cloudinary from 'cloudinary';
import cloudinaryStorage from 'multer-storage-cloudinary';
import config from '../config';

cloudinary.config(config.cloudinary);

const storage = fieldName => (config.isProduction ?
  cloudinaryStorage({
    cloudinary,
    folder: `${config.uploadDirectory}/${fieldName}`,
    allowedFormats: ['jpg', 'jpeg', 'png', 'gif'],
    filename: (req, file, callback) => {
      callback(null, req.user._id);
    },
  }) :
  multer.diskStorage({
    destination: config.uploadDirectory,
    filename: (req, file, callback) => {
      callback(null, req.user._id + path.extname(file.originalname));
    },
  })
);

export const uploadFile = fieldName => multer({
  storage: storage(fieldName),
  limits: { fileSize: config.maxFileSize },
}).single(fieldName);

export const uploadController = async (req, res, next) => {
  if (req.file) {
    if (config.isProduction) {
      return res.json({
        fileUrl: req.file.url,
      });
    }
    const filePath = req.file.destination.slice(req.file.destination.indexOf('/') + 1);
    return res.json({
      fileUrl: `/${filePath}${req.file.filename}`,
    });
  }

  return next({
    status: 500,
    message: 'Upload error!',
  });
};

Проверить работу можно следующим образом (отправлять запросы можно, например, Postman’ом):

Регистрируемся, послав post-запрос на http://diploma.ifedyukin.ru/api/user/register, формат `x-www-form-urlencoded`, поля: login, password, email (что в них отправлять, думаю, не стоит комментировать); последующий вход осуществляется отправкой такого же запроса, только на http://diploma.ifedyukin.ru/api/user/login и без поля «email» — в ответ придёт токен авторизации;
В ответе получаем объект, в котором нас интересует поле `token`, содержимое этого поля вносим в заголовок `Authorization`;
Посылаем post-запрос на http://diploma.ifedyukin.ru/api/file/avatar, формата `form-data`, с полем `avatar`, в котором будет лежать картинка.

—

Прикрутил аналитику от «Keen.io» и логгирование от «Logentries». Теперь могу смотреть статистику всяких событий, отслеживать «атаки» (сегодня в 4 утра кто-то пытался подбирать пароли к учетным записям, которых нет) и много-много всего интересного, а так же анализировать ошибки, внезапно возникающие при работе.

—

В планах прикрутить авторизацию на основе блокчейна (воспользуюсь готовым сервисом, но главное — блокчейн ~~антихайп~~), server-side рендеринг страничек полностью реализовать и сделать нормальную систему service-worker’ов, чтобы клиентская часть работала быстро в нескольких потоках (вероятно) и вообще: всё было здорово.
Но к этому я перейду после того, как сделаю базовую часть клиентской части, ибо, по сравнению с сервером, времени на это уйдёт ну очень много.

—

Впилил защиту от бесконечных регистраций и брутфорса паролей, ну и, конечно, закинул сбор статистики кого и с каким IP заблокировала «защита».

Диплом, часть 2. Сборка и CI

Sun, 14 Jan 2018 17:29:01 +0300

Как уже было сказано в предыдущем посте, диплом я буду писать полностью на JavaScript. 2018 год, поэтому никакие Gulp’ы (или Makefile’ы) для сборки JS я использовать не буду. Обойдусь одним WebPack.

Изначально я планировал собирать только FrontEnd, но потом и BackEnd решил тоже включить в сборку, ибо это даст больше профита, т. к. нативно NodeJS не всё хорошо поддерживает. Да и это отличная возможность пощупать TypeScript везде, где возможно.

Т. к. собираются и клиент и сервер, то будет соответственно 2 конфига webpack’a. Ничего особенного в них нет, если не брать во внимание, что в каждом конфиге есть и babel, и TypeScript. Приложение я планирую писать всё-таки на JS, а всякую сложную логику на TypeScript. В результате такой “архитектуры” у меня и в конфигах некоторая путаница (на первый взгляд), и линтеров целых 2. Ну, опять же в первую очередь я хочу хоть чуть пощупать TypeScript, так что приемлемо.

Конфиги клиента так же имеют кучу всяких loader’ов для стилей, картинок и всего-всего, но в них углубляться не буду. “Для вязкости” были добавлены всякие плагины.

В production-сборке:

config.plugins = [
  new CaseSensitivePathsPlugin(),
  new HappyPack({
    id: 'JavaScript',
    threads: Math.min(os.cpus().length, 4),
    loaders: [{
      loader: 'babel-loader',
    }],
  }),
  new webpack.optimize.CommonsChunkPlugin({
    name: 'vendor',
    minChunks(module) {
      return module.context && module.context.indexOf('node_modules') !== -1;
    },
  }),
  new JavaScriptObfuscator({
    rotateUnicodeArray: true,
  }),
  new HtmlWebpackPlugin({
    title: 'Event-Listener',
    template: '../src/client/templates/production.html',
  }),
  new CompressionPlugin({
    algorithm: 'gzip',
  }),
];

В development-сборке:

config.plugins = [
  new HappyPack({
    id: 'JavaScript',
    threads: Math.min(os.cpus().length, 4),
    loaders: [{
      loader: 'babel-loader',
    }],
  }),
  new webpack.optimize.CommonsChunkPlugin({
    name: 'vendor',
    minChunks(module) {
      return module.context && module.context.indexOf('node_modules') !== -1;
    },
  }),
  new HtmlWebpackPlugin({
    title: 'Event-Listener',
    template: '../src/client/templates/development.html',
  }),
  new CaseSensitivePathsPlugin(),
];

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

const config = {
  entry: {
    server: path.resolve(__dirname, '../src/server/index.js'),
  },
  target: 'node',
  externals: fs.readdirSync(path.resolve(__dirname, '../node_modules'))
    .reduce((acc, mod) => {
      if (mod === '.bin') {
        return acc;
      }

      acc[mod] = 'commonjs ' + mod;
      return acc;
    }, {}),
  node: {
    console: false,
    global: true,
    process: true,
    Buffer: false,
    __filename: false,
    __dirname: false,
  },
  output: {
    path: path.resolve(__dirname, '../build/server'),
    filename: '[name].js',
    publicPath: '/',
  },
  resolve: {
    extensions: [
      '.ts',
      '.js',
      '.json',
    ],
  },
  module: {
    loaders: [
      {
        test: /\.ts$/,
        exclude: /node_modules/,
        loader: 'awesome-typescript-loader',
      },
      {
        test: /\.js$/,
        exclude: /node_modules/,
        loader: 'babel-loader',
      },
      {
        test: /\.json$/,
        loader: 'json',
      },
    ],
  },
};

CI/CD одна из тех вещей, которую я делал не потому что надо (в отличие от webpack-конфига), а потому что интересно было всё это настроить. В предыдущем посте я рассказал, что деплой на Heroku — просто. Не совсем так.

Я хотел, чтобы билд производился на GitLab CI, а уже собранное приложение заливалось на Heroku.
Первая проблема: dpl заливал “чистую” версию приложения, без билда, без ещё чего-то. Я долго не мог понять, почему так, нормальной документации у dpl нет и не было (либо я не нашел). Но, где-то в обсуждениях GitLab CI я нашел решение: параметр —skip-cleanup. Теперь “скрипт”, производящий деплой выглядит так:

- dpl --provider=heroku --app=el-dev --api-key=$HEROKU_API_KEY --skip-cleanup

Для stage’а “Deploy” в качестве зависимости указан stage “Build”:

dependencies:
  - "Build"

Stage “Build” производит сборку и сохраняет результат на 3 часа (не знаю, почему именно на 3, но просто сделал так):

"Build":
  image: node:8.9.2
  stage: Checks
  dependencies:
    - "Install"
  script:
    - npm run build
  artifacts:
    expire_in: 3 hrs
    paths:
      - assets
      - build
      - public

С деплоем собранного приложения разобрались, но так же на Heroku улетало множество конфигов, исходников и подобных бесполезных для production’а файлов. Нужно было удалять всё лишнее. В *nix довольно несложно решить эту проблему, однако большая часть способов построена на использовании глобальных параметров системы или изменении. Использовать эти способы CI не позволяет, поэтому решением стал небольшой sh-скрипт, удаляющий всё лишнее:

#!/bin/bash

find ./ \
     -type f \
     -maxdepth 1 \
     -mindepth 1 \
     -name "*" \
     ! -name "Procfile" \
     ! -name "app.json" \
     ! -name "package.json" \
     ! -name "package-lock.json" \
     -exec rm -r {} \;

find ./ \
     -type d \
     -maxdepth 1 \
     -mindepth 1 \
     -name "*" \
     ! -name "public" \
     ! -name "assets" \
     ! -name "build" \
     ! -name ".git" \
     -exec rm -r {} \;

После удаления можно заливать только необходимые файлы на Heroku.
Кстати, Heroku передаёт вообще все переменные проекта через process.env.VARIABLE, например, параметры MongoDB.

Схема CI в Gitlab

Теперь можно начать писать чисто код, изредка добавляя loader’ы в конфиг клиентского webpack и не о чем другом не думать. Особенно хорошо, что в TypeScript я могу погружаться совсем понемногу и использовать его только там, где нужно, хотя, вероятно, для подобного использования стоило бы просто втянуть Flow, но уже поздно (да и мне как-то лень)…

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

Диплом, часть 1. Главное начать

Sat, 30 Dec 2017 17:17:43 +0300

Итак, 4 курс. В конце этого учебного года надо защищать диплом.
За процессом написания диплома надо как-то наблюдать, ну а чтобы как-нибудь потом порефлексировать, буду сюда писать небольшие посты.

В любом деле самое сложное — начать. Благо, начать писать диплом мне помог Hacktoberfest. А как именно — я рассказал на последнем митапе WebPurple.

В целом, всё, что я получил от Open Source сообщества — заготовки общих концепций. Нужно переходить к конкретики.

Результатом моего диплом, в теории, должно быть готовое программное обеспечение, решающуе какую-либо проблему. Моя тема — “ПО для организации мероприятий”. Под мероприятиями подразумеваются митапы, конференции, etc. Тема несложная, что и как должно работать я понимаю, поэтому с продумыванием реализации проблем возникнуть не должно.

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

На клиенте у меня будет типичная связка React + Redux, к которым я прикручу TypeScript (ибо давно хотел его подробно пощупать), а так же SASS (чтобы стили просто писались).
На сервере будет NodeJS и Epress, а в качестве БД — MongoDB с Mongoose. Этот стек серверных технологий мне кажется наиболее подходящим для текущей задачи, да и он мне интересен сильнее других.

Так как относительно недавно я открыл в себе интерес к DevOps, то всё это должно быть максимально автоматизировано, тестироваться, деплоиться и выполнять трюки само. Для этого я планирую использовать GitLab CI (потому что он клёвый).

Именно с CI/CD я и начал. Попытался сделать конфиг, который бы деплоил приложение на Express на Heroku. Вышло что-то типа этого:

stages:
  - heroku

before_script:
  - apt-get update -y
  - apt-get install apt-transport-https -y

deploy:
  stage: heroku
  script:
    - apt-get update -yq
    - apt-get install rubygems ruby-dev -y
    - gem install dpl
    - dpl --provider=heroku --app=el-dev --api-key=$HEROKU_API_KEY

К моему удивлению всё это с первого раза задеплоилось и заработало, исключая SSL-сертификаты, но это уже проблемы моего конфига Cloudflare.

На этоп часть первая окончена, следующим шагом планирую написать все конфиги (babel, webpack, etc) для development и production.

Production-билд будет крутиться на diploma.ifedyukin.ru.