Full Stack Developer в Tractor
  • Многоступенчатая сборка Docker-образа

    Как тестировать все эти SDK на VM? Спойлер: либо через жэ с настройкой всего этого зоопарка руками, либо многократно упростить себе жизнь Докером.

    Запускаючи тести. Наприклад перший-ліпший SDK : Android SDK. Копіюєте 2 версії SDK в 2 різні папочки. Встановлюєте параметр ANDROID_HOME для першого тесту на першу папку, для другого на другу. І т.д. Ну звісно, простіше інсталювати в дефолтний шлях на 2 різних докер образах. Не потрібно встановлювати ніякі змінні. Дуже професійно. Що значить руками? А з докером це буде ногами робитись, чи якимось іншим органом? Ви маєте прослідкувати щоб було 2 версії SDK які Ви підтримуєте. Докер магічним чином дозволить Вам це не перевіряти, чи принципово користуватись копіюванням папочок в 2к19 вже не модно і потрібно «закатумбрити тумбаюнбник оверкуратор». Це справді звучить як багатократне спрощення життя.

    Если Вы хотите всё удалять/устанавливать руками, следить за подобным зоопарком и, мало того, считаете это чем-то (sic!) позитивным, то Докер здесь, конечно, не поможет. Я вообще не знаю, что в таком случае может помочь). А говорят, что программисты чего-то там автоматизируют...

    Я хочу мати контроль над тим що в мене встановлено, де це знаходиться і якої версії. В ідеалі я хочу копіювати папочки, або запускати інсталлер. Я вважаю що позитивно використовувати прості сценарії і інструменти в порівняні зі складними. При автоматизації програмісти намагаються позбутися непотрібних залежностей, а не додали нових.

    «Його» — чей? И что имеется в виду под «захламлением Докера»?

    Я маю на увазі, що якщо в розробника виникає хаос при копіюванні і видаленні папочок, то в нього точно буде хаос і з купою докер контейнерів. І він не зможе розібратись, який для чого використовується.

    ...или написать это в Докерфайле один раз и юзать на любой машине, а не страдать лишними настройками VM.

    Або написати в .bat, .ps1, .sh файл без докера один раз і використовувати на будь-якій машині.

    Странно, почему не пишем на асме или плюсах до сих пор все, ну на самом-то деле, а? Проверенные решения, по 100500 лет каждому). И какие лицензии имеются в виду? Докер бесплатен.

    Тобто докер корисний тому що асм або плюси застаріли?)

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

    Намагаюсь розібратись навіщо мені автоматизувати з зав’язкою на докер, якщо я можу автоматизувати без цієї зав’язки. Якщо все потрібне записати в папочку, це буде рахуватись? Все потрібне в образі це як? А поза образом пустота? Чи операційна система конкретної версії зі своїм API і можливо несумісна з API схожої версії. Докер сам магічним чином знає якщо в мене OS несумісна або якось зможе це поправити? Поки я бачу що в будь якому разі за такими речами маю слідкувати я + слідкувати ще за докером. Якщо все потрібне в образі без врахування залежності від OS, чому я не можу просто снинуте це все в одну папку? Система залишається чистою... з докером, який підмінює системні драйвери, ага. Ізоляція в подарунок. Ізоляція від чого? Якщо софт пише в базу на віддаленому сервері, як ми це можемо ізолювати? Якщо софт захоче записати в папочку, а інший софт захоче прочити з папочки, як докер дізнається це валідний сценарій по задумці розробника чи ні? Викидує монетку? Чому не весь софт працює з докером? Більше питань та невизначеної поведінки яка не піддається логіці.

    Кроме этого нужно устанавливать вагон разного софта, шэрить и апдейтить конфиги на все VM. Но зачем, если этого можно НЕ делать, используя Докер? Изменился конфиг для конкретного окружения/проекта/команды etc — сделали апдейт Докерфайла/Докер образа, и VM даже не трогаем.

    Знову ж таки, якщо потрібен софт, і розробники дають гарантії правильної його роботи при використанні інсталятору, то використання костилів докера, не гарантує нічого. Помінявся конфіг — скопіюй файл з конфігом. Помінялась змінна оточення — зміни її. Все геніальне просто. VM навіть не торкаємся. Це такий челенж, не торкатись VM?) В чому суть цього і чому це добро?

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

    Не дає в загальному випадку, зате дає купу невизначеної поведінки. В розробників докера зате є виправдання на всі випадки життя. «В продакшені не юзати.» Геніально. Писати різні деплойменти для продакшена і для дев-середовищ. Докер це не стандарт, і ніколи їм не буде. Стандарт це використання app-get або .msi або як в .NET way, копіювання папочок.

  • Многоступенчатая сборка Docker-образа

    Я намагаюсь вирішити для себе, чи потрібно мені витрачати час на вивчення докера, чи на щось більш корисне. Поки реальних аргументів за докер малувато. Героїчно долаються вигадані проблеми.

  • Многоступенчатая сборка Docker-образа

    1. Навіщо використовувати складні сетапи, потрібно використовувати прості. Що значить захламляти — якщо програма використовується вона є на компі, якщо не вокористовується — її немає. Ви видаляєте її або просто не встановлюєте. Програма яка використовується це не хлам, а корисний софт. Якщо Ви не можете\хочете слідкувати за софтом на компі докер тут не допоможе — Ви захламите його докер чимось там. На рахунок системних змінних — якщо захламляють, я рекомендую їх не використовувати, а використовувати змінні хоста. Якщо не хочете модифікувати PATH системний, або користувача, використовуєте:
    SET PATH=%PATH%;c:\whatever\else
    Це базова річ і використовується не один десяток років, і ніколи не було з ним проблем. Навіщо для цього використовувати софт, купувати ліцензії, апгрейдити, вчити людей, ловити купу багів ?
    2. До чого тут докер?
    2.1 До чого тут докер?
    2.2 Я пас, але думаю це казочка.
    2.3 Звучить як фіча, але вирішитись може на рівні VM. VM не повинна буди загажена якщо все ОК, якщо так сталось — правимо і розгортаємо іншу VM.
    2.4 Знову ж, використовувати змінні на рівні хоста, а не ОС або користувача. Це дуже просто.

    В теорії докер не потрібен, в реальномо житті все звичайно залежить від ситуації.

  • Многоступенчатая сборка Docker-образа

    Я одною командою роблю це без докера, і не маю проблем з купою безглуздих абстракцій без чітких меж. Вже приводили приклад з ангуларом і статикою. Це п’ята нога зайцю. Будь-який мій деплоймент скрипт має залежності тільки від продукту, я не думаю що розумно додавати залежності від якогось софту, з непрозорими умовами ліцензії, з купою багів і апдейтами які ламають зворотну сумісність. Навіть якщо цей продукт піариться вже не один рік і обіцяє золоті гори і магічно все робити супер однією командою, а по суті ще один EEE ...

  • Как научить команду общаться. Прием для менеджеров

    так, є така професійна хвороба в менеджерів, пояснювати проблеми софт скілами і шукати їх вирішення також софт скілами. дуже і дуже поширена. Насправді тільки кілька разів стикався з реальними проблемами з комунікаціями за всю карь‘єру. Коли на прохання щось заімплементити людина регулярно відповідала — ні, я не хочу)

  • Многоступенчатая сборка Docker-образа

    Яке відношення «докер» має до фічі яку я пишу для проекту, для якого потрібно спеціальне оточення, яке мені потрібно для реалізації фічі ? Я без докеру маю можливість використати готовий продукт під свої потреби, наприклад я працюю з проектом на будь-якій мові, для моєї таски потрібно додати модуль якийсь, я беру сам і додаю його — це підхід профі, або пишу таску на PMа що мені потрібен модуль без докера, PM через день — тиждень — місяць — дає таску тех. ліду, або девопсу, або адміну, щодо переробки оточення під мою фічу, що стає нудною гидотною таскою для всіх. Бо такий примітив як додавання модуля без докера повинен знати навіть джун у сучасному IT. Коли ви самі написали свою фічу без докера, відправили до staging, + додали до деплою потрібні кроки — фіча після тесту запрацювала на staging, та QA перевірили і фіча пішла на продакшин — бо все автоматизовано, а девелопер не чекає поки docker, щось зробить для нього — він як профі сам вже зробив, користуючись наданими йому інструментами...

  • Многоступенчатая сборка Docker-образа

    тобто коли я будую свій будинок, і розставляю меблі, мені потрібно складати план на папірці, на випадок якщо я буду будувати такий же будинок, і розставляти такі ж меблі в тому ж порядку?

  • Многоступенчатая сборка Docker-образа

    docker потрібний для розробників?

  • Как научить команду общаться. Прием для менеджеров

    Так, я думаю що Ви розібрались в тому що робите, і дякую що поділились. Мій коментар це скоріше застереження для тих хто буде намагатись використати Ваш досвід в непідходящому кейсі. Наприклад погана комунікація може мати глибші першопричини. Як от продакт овнер не встигає за командою розробників. Або задачі які взаємоблокують розробників, або змушують їх часто перетинатись в функціоналі один одного. Команда QA не знає версії коду який тестує, її просто немає на сторінці. DevOps має час тільки на поточні операції, але немає часу на покращення деплойментів. Або дуже банальна проблема — низька якість коду. Ці кейси точно приведуть до проблем з комунікацією, але тут це буде тільки ’проекція’ реальних проблем. Коли цих проблем немає, а є продакт овнер який розумно розбиває рішення на проекти, проекти на модулі, і знає як це все працює, і сенйорні розробники — комунікація буде на висоті. Але не тому що для вирішення якогось питання знадобилось 1 пленінг і 3 повідомлення в slack, а не 1 пленінг і 5 повідомлень, і навіть не тому що ці 3 повідомлення більш інформативні і грамотні. Сподіваюсь Ви розумієте про що я)

  • Как научить команду общаться. Прием для менеджеров

    Робити надлаштування над спілкуванням в команді потрібно далеко не завжди. З досвіду менеджери часто переоцінюють важливість вербального спілкування і недооцінюють можливості інструментів, таких як звичайний git. Переоцінка пов’язана з особистим досвідом, так в менеджерів прийнято працювати, курси і т.д. де наголошують на важливості спілкування в команді. При налаштованому процессі, і злагодженій команді 90% ефективного спілкування між розробниками зводиться до перегляду пулл реквестів і резолву конфліктів в коді.

  • Гід IT-спеціальностями КНУ імені Шевченка

    в 2010-12 іноді доводилось сидіти в теплих куртках і рукавицях, в деяких аудиторіях РФФ, нам пояснювали що ці факультети побудовані в 60-х роках по кубинським технологіям, і не дуже розраховані на холод. Навіть жарким літом там прохолодно. Те що не стали студентів морозити норм рішення.

    Підтримав: Богдан
  • Делайте return, как только нашли ответ

    Це скоріше не плюс, а особливість. Уявіть що вам потрібно дослідити\змінити поведінку одного об’єкта з ієрархії класів, в випадку з switch це робиться за одну операцію, у запропонованому Вами підході — час залежить від кількості підкласів, чим більше тим довше. Щось на зразок O(N), де N кількість класів. Якщо ж використовуються декоратори — складність пошуку конкретного місця зростає ще на порядок — в гіршому випадку. O(N^2). Це тільки пошук. Це такий собі антипаттерн — розмивання логіки.

  • Front-Еnd дайджест #25: пишем и учим WebAssembly, будущие стандарты JavaScript и сможет ли Vue.js захватить мир?

    щоб vue захопив світ, він має загопити спочатку мене, але я його ігнорую.

    Підтримали: Sergiy Morenets, Andrii Shumada
  • Делайте return, как только нашли ответ

    пункт 4 поки тримається, ніхто не став став апелювати)

  • Делайте return, как только нашли ответ

    це не перевідкриття, це капітан очевидність. Я можу з десяток таких істин написати сходу:

    1. перевіряй об’єкт на null перед тим як викликати функцію
    2. не використовуй string для enum
    3. використовуй switch замість багатьох if else операторів
    4. чисть зуби перед сном...
    Підтримав: Yuriy Pitometsu
  • Microsoft Azure PaaS для .NET приложений

    Azure PaaS, цікавий термін. Від термінологій Ms Azure і Amazon Cloud хочеться закрити статтю і трохи поспати. В голові не вкладуться терміни по типу «М’які сині сервіси».

    PaaS
    - це модель за якою software ліцензується,
    IoT
     — це для чого. Таке відчуття що цим сервісам давали назви колишні продавці автомобілів. Microsoft, Amazon, будь-ласка, називайте ваші продукти так щоб їх можна було відрізнити один від іншого.
  • Как меня увольняли и прочие байки

    Задача для железячников
    треба підказка.
    Підтримав: Gremlin
  • Что происходит с Angular 2

    цікаво, а в книзі розказують чому «hello world» в браузері рендериться 2.5 секунди і stack-trace на 70 вкладень? і нащо в «hello world» десятки залежностей.

  • Время для покупки жилья

    ви маєте на увазі звичайну оренду? Я розглядаю такий варіант, багато плюсів — можна змінити авто, якщо набридло + не потрібно тратитись на кап ремонти. Питання тільки в ціні і надійності орендаря. А лізинг, це коли існує посередник, наприклад банк, який заробляє на тому що, я дає гроші зараз, а розплачуюсь я потім, тільки на відміну від кредиту власником майна є лізінгодавець. По суті той же кредит — я плачу за авто і лізінгодавцю. Ризики на мені — не дуже хороший варіант.

    Підтримав: ZeRMiuNT ZeRM
  • Время для покупки жилья

    для когось мабуть непоганий варіант. але я не довіряю нашим хитрим банкірам) з їх 25% річних.

← Сtrl 1... 8910111213 Ctrl →