Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×
архімаггриб в Дарницькі печери
  • Використання транзакцій в реляційних базах даних: забезпечення надійності та цілісності

    Якось занадто поверхнево.

    > Команди управління транзакціями використовуються тільки з командами DML, як-от — INSERT, UPDATE та DELETE. Вони не можуть використовуватися під час створення таблиць або їх видалення, оскільки ці операції автоматично фіксуються в базі даних.

    Вірно для більшости, але не для всіх баз.

    > Ця команда може використовуватися тільки для скасування транзакцій з моменту виконання останньої команди COMMIT або ROLLBACK.

    Не згадан autocommit-режим, і що він може бути за замовчуванням. Тоді ви нічого вже не скасуєте.

    > SAVEPOINT — це точка транзакції, до якої ви можете повернути транзакцію, не відкочуючи її повністю.

    Багато де не реалізовано.

    > Приклад 1. Банківська транзакція

    Ані слова про те, що будь-який з UPDATE може зависнути на визначений час чи одразу відмовити, що COMMIT може відмовити, що робити у такому випадку. (Я вже не згадую, що реальна банківська транзакція пише ще два десятки таблиць логів і статистики, і скоріш за все сам переказ на цільовий рахунок теж у таблиці тимчасового логу, а не одразу.)

    > Основні проблеми паралельного доступу:

    І ані слова про те, що цей аналіз дуже поверхневий. Забуті такі проблеми, як read skew, write skew. Щоб почитати, наприклад:
    www.cockroachlabs.com/...​le/demo-serializable.html
    justinjaffray.com/...​oes-write-skew-look-like
    A Critique of ANSI SQL Isolation Levels, Jun 1995, Microsoft Research (1995! це ж коли було і мало хто знає)
    Кожен хто претендує на звання хоча б інтерна з DBA чи мідла у суміжних областях — має це знати і уважати. В такій статті як ця — якщо не в основному тексті, то хоча б у PS треба було б зауважити.

    Ні слова про те, як можна керувати рівнем оптимістичности в транзакціях, які рушії (движки?) як з цим працюють (блоковочники і версіонники (MVCC) дуже по-різному відносяться до цього), про переваги всяких select for update де вони є...

    Ні слова про те, як застосунок має кешувати дані і як це робиться через різні ORM, навіть не згадане їх існування...

    Привіт автору від Даннінга з Крюгером, даруйте.

  • Онбординг на новій роботі. Діліться своїми кейсами — вдалими та не дуже

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

  • Онбординг на новій роботі. Діліться своїми кейсами — вдалими та не дуже

    Тобто, поки йшли співбесіди та поки ми його чекали місяць — він про цю свою «особливість» не згадував. Він ссилався на те, що «ну ви ж сказали у вас гнучкий графік».

    Ну это в первую очередь ваша ошибка — «гибкий график» должен предусматривать уровень гибкости. Может, он работал раньше с теми, кто иного варианта просто не знал.
    Обычно таки «гибкий график» это что-то вроде «понедельник, среда и пятница — обязательное присутствие и работа с 12 до 16 с быстрой реакцией на все входящие, участие в совещаниях, остальное когда хочешь» и детали — когда быть на связи — критически важны. Поэтому «гибкий график» без указания постоянной части это вообще ни о чём. Тут вы сами виноваты на 90%. Остаток на него — что не подумал какая степень гибкости — но, может, у него таки опыта в этом не было.

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

    Все так (навіть якщо документація здається повною і ідеальною)... ну і зовсім без живої розмови можна впоратись з дуже малою часткою робіт...

  • Онбординг на новій роботі. Діліться своїми кейсами — вдалими та не дуже

    Ну якщо для вас «вчитись» то «шаройобитися»... що ви тут робите?

  • Чи є у вас на проєкті код фрізи?

    Там де найдовше працював — декілька днів перед форком релізної гілки, потім вивільняє. А ось в релізній вже сувора дисципліна. Релізні гілки за часом кожні ~2 місяці.
    Там appliances що встановлюються у кастомера.

    На поточному проекті схоже, але дещо більше бардака.

  • Чи багато у вас вкладок і закладок у браузері? Як ви їм даєте раду?

    800-900 в найбільш товстому профілі. Не заважають, бо не завантажені.

    Підтримали: Oleksandr Suvorov, Alex Oliinyk
  • Онбординг на новій роботі. Діліться своїми кейсами — вдалими та не дуже

    Головне — кричати «Вільна каса!» впевненим голосом.
    Oh wait... навіть в маку вчитися новій роботі це декілька тижнів.

    Підтримав: Микола Сидоренко
  • Відбувся реліз Django 5.0

    На нём DOU работает.

  • Які ваші прогнози та очікування від 2024 року?

    И тогда действительно победа была нужна любой ценой,

    Требование победы любой ценой — _никогда_ не должно быть. Не потому, что нельзя так хотеть, а потому, что это даёт оправдание именно бессмысленным потерям.
    ещё
    В случае WW2 это 1942: Мясной Бор, Ржев и ещё десяток аналогичных локаций, которые стараются не вспоминать, потому что до сих пор в лесах труп на трупе во много слоёв. Или взятие Берлина «к дате», которое добавило полмиллиона погибших.
    Статистика смертности в тылу, кстати, не радует. Сколько там от голода и холода?

  • Які ваші прогнози та очікування від 2024 року?

    У «Воскресения» пісні були також «вгадай про що це я», особливо у Нікольського. Заборонили, розігнали. Бо кінець 70х, а не 80х.

  • Які ваші прогнози та очікування від 2024 року?

    Звісно, ви нічого крім своїх тарганів не чуєте.

    Підтримав: Dmytro Lapshyn
  • Які ваші прогнози та очікування від 2024 року?

    Претензії до будь чого дозволеного в совєтському союзі базуються саме на тому що вони були дозволені.

    1. Це не має відношення до періоду після 1985. Обмеження майже не діяли. А Цой, раз уж мова про нього, десь тоді і стартував помітно.
    2. у різні періоди дозволялось не лише те, що було 100% на користь головної задачі, а і те, що просто формально не протирічило. Абсолютної цензури не було ніколи.

    Все дуже просто — пісню Цоя Восьмикласниця, розглянула, проаналізувала та дозволила комуністична парт

    Ні, не «дозволила», а «не вирішила достатньо небезпечною».

    «4 сентября 1986 года Главлит СССР издал приказ № 29с, в котором цензорам было дано указание сосредоточить внимание на вопросах, связанных с охраной государственных и военных тайн в печати, и информировать партийные органы только о существенных нарушениях в идеологической сфере.»

    Хто реально навмисно прогибався під цензуру — це попереднє покоління, але серед них тільки «Машина времени» відкрито казала про це. Але щоб під неї «калічили у концтаборах» — такого не було. Покоління, що здатне калічити і вбивати заради «русского мира» під Цоя, МВ і навіть ГО — це вже після 2000.

    Підтримав: Dmytro Lapshyn
  • «ШІ є загрозою для багатьох робочих місць». Шведська IT-компанія зупинила найм всіх фахівців, окрім інженерів

  • Чи потрібно знати CS теорію для роботи?

    Спробуй попрацювати зі spark, знаючи лише АПІ.

    1. Яка частка програмістів працює зі Spark?
    2. Яка частка CS потрібна для розуміння глибин Spark?

  • Про Ethernet на пальцях

    А як їм ще входити в IT?

  • Про Ethernet на пальцях

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

  • Про Ethernet на пальцях

    Якщо біти, то «bit».
    Якщо байти, то «B».
    А просто «b» це, якщо строго дотримуватись стандарту, просто помилка.

    Підтримав: Олег
  • MacBook M3 або М2. Що обрати для Java Microservices?

    знайшов між іншим такий параметр який відповідає за своп і по дефолту в убунті (в інших треба перевіряти чи є такий самий параметр) десь на 60 відсотків зайнятої оперативи починається своп(це можна налаштувати).

    Якщо vm.swappiness, то він, навпаки, про вільну памʼять — 60 означає що зайнято 40%. Але це про те коли _починається_ свопінг, тобто якщо більше вільної, система про нього взагалі не думає. А коли думає, то головне питання, що саме скидається і в якому темпі.

    Чому саме така біда коли є своп тут я вже так глибоко не став копати тому що навіть як я це з’ясую це буде знання із розряду «небо синє» знати знаєш, а змінити нічого не можеш.

    А це і є головне. Ні, можеш. Бо можеш контролюватит політику хоча б на рівні скільки місця піде на процеси, а скільки на кеші.

    Проте це костильне рішення коли вже такі важкі проекти треба ганяти то якось на планку пам’яті нашкрести можна, а не думати як же влізти в ті 8 — 16 гіг оперативи.

    Не на лаптопі. Чіпсети з лімітом 16, 32GB це звично.

  • MacBook M3 або М2. Що обрати для Java Microservices?

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

    А чому саме, якщо в першому тесті було 46?
    Чи менеджер тільки «розгорнув» і не запускав?

  • MacBook M3 або М2. Що обрати для Java Microservices?

    Причому своп починається до того як вичерпається оперативна пам’ять.

    І що?

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

    2. Оперативка це місце не тільки для процесів, але і для кеша диску. Щоб не писати один сектор по 300 разів, краще його тримати в кеші і тільки зрідка скидати.

    Але не треба впадати в іншу крайність — 12309. Ось тут, дійсно, Linux має проблеми, якщо не регулювати. Може, ви як раз на це наривались.

    TLDR: треба міряти реальні цифри і розуміти їх. А не огульно скопом всіх.

    Так чи інакше на такі проекти купувати ноут це дичина і гроші на вітер

    Це інше питання і тут згоден. Зрідка треба щоб можна було працювати (включаючи розгортання 100500 докерів) звідки завгодно, але я б долю таких оцінив в 1%.
    Іншим вистачає десктопа або стенда на роботі, до яких можна приєднатись ssh+RDP+etc.

← Сtrl 1... 34567...373 Ctrl →