Серйозно, у вас ніколи не було такого, що поки ви не вивчите предметну галузь, ви просто не розумієте, що означають ті задачі, що вам дані, і як взагалі за них братись?
Навіть у простішому варіанті на те, щоб вивчити, де код, як збирати, як тестувати, з ким обговорювати, де розписаний стиль, де дивитись результати автотестів — це тижні і місяці, і перший результат, який щось значить, приходить не в перший день.
Не вірю. Або малюєте з себе когось кого не існує, або ваша личка — підробна.
Тобто, поки йшли співбесіди та поки ми його чекали місяць — він про цю свою «особливість» не згадував. Він ссилався на те, що «ну ви ж сказали у вас гнучкий графік».
Ну это в первую очередь ваша ошибка — «гибкий график» должен предусматривать уровень гибкости. Может, он работал раньше с теми, кто иного варианта просто не знал.
Обычно таки «гибкий график» это что-то вроде «понедельник, среда и пятница — обязательное присутствие и работа с 12 до 16 с быстрой реакцией на все входящие, участие в совещаниях, остальное когда хочешь» и детали — когда быть на связи — критически важны. Поэтому «гибкий график» без указания постоянной части это вообще ни о чём. Тут вы сами виноваты на 90%. Остаток на него — что не подумал какая степень гибкости — но, может, у него таки опыта в этом не было.
Бо люди, що онбордяться — навіть якщо вони дивляться якісь відео чи читають документацію — у них все одно виникають питання, і людина краще розуміє, якщо є можливість спитати.
Все так (навіть якщо документація здається повною і ідеальною)... ну і зовсім без живої розмови можна впоратись з дуже малою часткою робіт...
Ну якщо для вас «вчитись» то «шаройобитися»... що ви тут робите?
Там де найдовше працював — декілька днів перед форком релізної гілки, потім вивільняє. А ось в релізній вже сувора дисципліна. Релізні гілки за часом кожні ~2 місяці.
Там appliances що встановлюються у кастомера.
На поточному проекті схоже, але дещо більше бардака.
Головне — кричати «Вільна каса!» впевненим голосом.
Oh wait... навіть в маку вчитися новій роботі це декілька тижнів.
И тогда действительно победа была нужна любой ценой,
Требование победы любой ценой — _никогда_ не должно быть. Не потому, что нельзя так хотеть, а потому, что это даёт оправдание именно бессмысленным потерям.
ещё
В случае WW2 это 1942: Мясной Бор, Ржев и ещё десяток аналогичных локаций, которые стараются не вспоминать, потому что до сих пор в лесах труп на трупе во много слоёв. Или взятие Берлина «к дате», которое добавило полмиллиона погибших.
Статистика смертности в тылу, кстати, не радует. Сколько там от голода и холода?
У «Воскресения» пісні були також «вгадай про що це я», особливо у Нікольського. Заборонили, розігнали. Бо кінець 70х, а не 80х.
Претензії до будь чого дозволеного в совєтському союзі базуються саме на тому що вони були дозволені.
1. Це не має відношення до періоду після 1985. Обмеження майже не діяли. А Цой, раз уж мова про нього, десь тоді і стартував помітно.
2. у різні періоди дозволялось не лише те, що було 100% на користь головної задачі, а і те, що просто формально не протирічило. Абсолютної цензури не було ніколи.
Все дуже просто — пісню Цоя Восьмикласниця, розглянула, проаналізувала та дозволила комуністична парт
Ні, не «дозволила», а «не вирішила достатньо небезпечною».
«4 сентября 1986 года Главлит СССР издал приказ № 29с, в котором цензорам было дано указание сосредоточить внимание на вопросах, связанных с охраной государственных и военных тайн в печати, и информировать партийные органы только о существенных нарушениях в идеологической сфере.»
Хто реально навмисно прогибався під цензуру — це попереднє покоління, але серед них тільки «Машина времени» відкрито казала про це. Але щоб під неї «калічили у концтаборах» — такого не було. Покоління, що здатне калічити і вбивати заради «русского мира» під Цоя, МВ і навіть ГО — це вже після 2000.
Прибиральниці вже не потрібні? ШІ замінив?
Спробуй попрацювати зі spark, знаючи лише АПІ.
1. Яка частка програмістів працює зі Spark?
2. Яка частка CS потрібна для розуміння глибин Spark?
А як їм ще входити в IT?
Кое-кто пытается наполнять форум техническими статьями, хотя редакция, формально приветствуя это, делает на практике всё, чтобы тут было как можно меньше технических статей и обсуждений.
После этого ученический материал для статей неизбежен.
Якщо біти, то «bit».
Якщо байти, то «B».
А просто «b» це, якщо строго дотримуватись стандарту, просто помилка.
знайшов між іншим такий параметр який відповідає за своп і по дефолту в убунті (в інших треба перевіряти чи є такий самий параметр) десь на 60 відсотків зайнятої оперативи починається своп(це можна налаштувати).
Якщо vm.swappiness, то він, навпаки, про вільну памʼять — 60 означає що зайнято 40%. Але це про те коли _починається_ свопінг, тобто якщо більше вільної, система про нього взагалі не думає. А коли думає, то головне питання, що саме скидається і в якому темпі.
Чому саме така біда коли є своп тут я вже так глибоко не став копати тому що навіть як я це з’ясую це буде знання із розряду «небо синє» знати знаєш, а змінити нічого не можеш.
А це і є головне. Ні, можеш. Бо можеш контролюватит політику хоча б на рівні скільки місця піде на процеси, а скільки на кеші.
Проте це костильне рішення коли вже такі важкі проекти треба ганяти то якось на планку пам’яті нашкрести можна, а не думати як же влізти в ті 8 — 16 гіг оперативи.
Не на лаптопі. Чіпсети з лімітом 16, 32GB це звично.
Оперативка на тих десктопах із 64Гб закінчилась ще до того, як їх пряморуким девам налаштували.
А чому саме, якщо в першому тесті було 46?
Чи менеджер тільки «розгорнув» і не запускав?
Причому своп починається до того як вичерпається оперативна пам’ять.
І що?
1. Якщо ви міряєте просто по наявности чогось в свопі — це нормально, бо скидаються сторінки, які давно не чіпались. Є процеси типа getty які можуть бути використані 1 раз на рік, але вони потрібні. І вони падають в своп.
2. Оперативка це місце не тільки для процесів, але і для кеша диску. Щоб не писати один сектор по 300 разів, краще його тримати в кеші і тільки зрідка скидати.
Але не треба впадати в іншу крайність — 12309. Ось тут, дійсно, Linux має проблеми, якщо не регулювати. Може, ви як раз на це наривались.
TLDR: треба міряти реальні цифри і розуміти їх. А не огульно скопом всіх.
Так чи інакше на такі проекти купувати ноут це дичина і гроші на вітер
Це інше питання і тут згоден. Зрідка треба щоб можна було працювати (включаючи розгортання 100500 докерів) звідки завгодно, але я б долю таких оцінив в 1%.
Іншим вистачає десктопа або стенда на роботі, до яких можна приєднатись ssh+RDP+etc.
Якось занадто поверхнево.
> Команди управління транзакціями використовуються тільки з командами 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, навіть не згадане їх існування...
Привіт автору від Даннінга з Крюгером, даруйте.