GitHub *

Продолжу выкладывание примеров использования GitHub'а как инструмента обучения.
Рассмотрим версию работы нескольких команд над одним большим проектом с подпроектами.

В данной статье я покажу и расскажу, как можно сгенерировать аватарки как на Github.

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

В своей статье "Использование GitHub в обучении студентов" я кратко коснулся темы использования GitHub'а именно как инструмента для обучения, а не как темы в обучении. Сейчас хочу попробовать привести примеры нескольких кейсов.

Начну с относительно простого варианта, а в следующих статьях расскажу про другие варианты.

В своей преподавательской практике использую GitHub...

Но для начала давайте представлюсь. Зовут меня Старинин Андрей. И я преподаю программирование, хотя по первому образованию я биолог.

Открываю VS Code и начинаю набирать статью с самого начала. Но вот незадача — формат маркдауна не совсем совместим с имеющимся форматом Хабра. Получается выхода нет и придётся возвращаться к встроенному редактору Хабра;

Или не придется?

В голову пришла идея написать утилиту, которая конвертирует разные форматы маркдаунов друг в друга, например, из формата GitHub в формат Habr;

Такую программу я в итоге и разработал. Теперь не надо копировать статьи в редактор Хабра, чтобы посмотреть как она выглядит, можно продолжать писать в любимом VS Code;

Хотя я и использую множество плагинов VS Code, но мысли о неэффективном процессе написания статей не исчезли. Раз уж я набираю текст в VS Code, то почему бы сразу не делать коммиты контента в гит-репозиторий?

Это дало бы немало новых возможностей, которыми пользуются программисты: версионирование, бекапы на локальные носители или веб-сервисы, правки от редакторов и пользователей. А еще можно внедрить CD/CI;

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

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

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

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

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

Предыстория

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

Подходы к созданию фреймворка

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

Всем известны два стиля написания кода — императивный и декларативный. Императивный стиль описывает то, как получить результат, декларативный — что требуется получить в результате.

Внедряем оплату BTC куда угодно (Python)

- генерация кошелька на основе seed фразы

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

- отправка BTC на другие кошельки

- создаем телеграм бота для выполнения операций с BTC

- исходники бота (github)

В статье детально, с приведением исходного кода, описывается работа, проведенная по переносу и запуску с SD-карты программной прошивки с ОС Андроид для устройств на процессоре Amlogic S912.