Pull to refresh
1
0
Дмитрий Баранов @dem0n3d

Пользователь

Send message

Спасибо за статью! Сам буквально вчера встал на этот нелегкий путь... Но, есть одно "но". Опробовал на gitlab.com, сразу же столкнулся с ошибкой: JOB ID там уже выходит за пределы инта. Рекомендую использовать $CI_PIPELINE_IID (внутренний для проекта номер пайплайна). PS Жду продолжения про подписание и доставку.

Это всё конечно хорошо, но когда уже добавите голосовой поиск в Кинопоиск для Android TV? Неужели это так сложно с такими то технологиями?

сотрудник Apple с сильным еврейским акцентом

что, простите?

Как раз недавно изучал подобный сценарий. Обнаружилось, что в обычном образе nginx нет ни wget, ни curl, а вот в alpine-варианте есть wget. Можно пойти ещё дальше: статику предварительно сжать и раздавать её со смонтированного RAM-диска (tmpfs). И всё это со стандартным образом nginx-alpine.

Это вы про a,b,c т.д.? Да, это большая потеря.
А имя файла в tree = ET.parse("add-30-40.xml",parser=parser) вы вручную каждый раз подставляли? Нельзя было просто циклом пройтись сразу по всем XML-файлам и записать разом в один CSV файл?
Кстати, заголовок в CSV вообще не обязателен (в т.ч. для pandas).

Специальная утилита для склеивания CSV-файлов. Серьёзно?

Подробный разбор темы на HolyJS 2019 Piter.


Вовремя: я как раз собрался брать 4К, но остались вопросы. У меня такой ноутбук, с одним портом type-C. В спеках написано "USB 3.1 Type-C™ Gen 1 (скорость передачи данных до 5 Гбит/с, DP1.2, технология HP Sleep and Charge)". В описании DisplayPort написано что скорость передачи данных для 4К@60Hz = 12.54 Gbit/s, в DP1.2 (заявленный в спеках ноутбука) поддерживает 17.28 Gbit/s. Это означает, что USB будет работать на скорость 5Гбит/с, а DP на этом же порту — 17.28 Gbit/s?

Вообще то это уже всё прекрасно описано: https://habr.com/post/301044/
И под курсорами в данном контекст обычно понимается нечто совершенно другое.

Есть некая вкладка "Rules", но пока не понятно насколько сложные конструкции там можно создавать: https://www.youtube.com/watch?v=ZXEZkqnT-6o

Механизм кеширования встроен в раннер, настраивается довольно гибко: https://docs.gitlab.com/ee/ci/caching/

Весьма топорная конфигурация:


  • Мешанину в скриптах следует разделить на job'ы в gitlab-ci. Деплой уж точно следует вынести в отдельные задачи.
  • Ключи (и проч.) надо хранить в Gitlab Secret variables.
  • Уведомления можно отправлять через Web Hooks (для Slack уже есть готовый).
  • Не используется кеширование (вероятно, оно может решить проблемы с ассетами).

По поводу версии Unity: с одной стороны это — зависимость и должна устанавливаться вместе с другими зависимостями (например в before_script), кеширование в помощь. С другой стороны — слишком тяжёлая и основополагающая зависимость, я бы скорее делал через docker, привязав образ к версии Unity.

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

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

А не рассматривали вариант представлений (View)? Не проще ли их интегрировать в ORM?

Что касается диктора, то он скорее всего просто читает по листочку заранее написанный текст. Роскосмос, видимо, делает так же. Вот, нашёл трансляцию, где комментатор говорит об этом (ещё на 27:30):

Information

Rating
Does not participate
Location
Оренбург, Оренбургская обл., Россия
Date of birth
Registered
Activity