Comments 105
«Матрешка» RDP на тестовый стенд с БД.
Нужно быстро почистить тестовые данные для того чтобы уместилась новая порция.
Пишу truncate table оченьважнаятаблица
В последний момент перед запуском решаю проверить, а много ли данных и нужно ли вообще очищать стенд?
Пишу count(*) from оченьважнаятаблица
И тут у меня потеют ладошки. Возвращаемое значение превышает на пару порядков возможности тестового стенда.
В последнем уровне «матрешки» -на стенде БД кто-то оставил RDP во весь экран на продуктовый сервер БД.
Вот так обычное число может напугать не хуже фильма ужасов.
PS: Доступ закрыли, невиновных наказали, а непричастных наградили, конечно :)
:-))))
На каждый комп, обычно по 2 монитора, на которых во весь экран обычно работает какая-то система мониторинга.
На одной из систем, возникает авария и инженер центра по процедуре делает скрин и отправляет кому следует, со второго монитора.
Дальше, спокойно сдает смену забыв свернуть скрин и идет домой. О, том что с системой мониторинга что-то не так, заметили аж под утро :))) (благо, что ничего серьезного не произошло).
Страшилка про современный уровень разработчиков.
На собеседование пришел Senior Frontend React-Rocket-Cosmic разработчик с серьезными запросами по компенсации его труда.
После устной беседы решили дать ему задание: написать какой-то банальный reducer коллекции.
Он написал, показал интервьюерам.
Потом у него спрашивают:
— Можно этот reducer упростить до O(log n)?
Он говорит:
— Нет, нельзя.
— Почему? — интересуются интервьюеры.
И тут гениальный ответ:
— Потому что интерпретатор JS не понимает такой синтаксис и будет ошибка.
p.s. для тех кто не вкурсе, большинство служителей питона, чихать хотели на интерфейс своих решений. Пашет и ок. Нейросетка распознала лицо? выведем табличку и ок. Остальное отдадим на фронт RestApi-шкой фронтендщикам и запакуем в Electron(зато красиво и везде пашет).
Это сильно! :)
А вообще: хороший программист пишет глупым кодом гениальные вещи, а не наоборот.
Когда нанимают человека на позицию Senior Software Developer а он пишет O(n!), вместо O(n), то такого человека не лучше не брать. Мы вам перезвоним. А Frontend это, Backend или что ещё — дело десятое. Я на собеседованиях даю простенькие задачки, две из которых как раз про bigO и .reduce((accummulator, value) => [...accummulator, someFn(value)], []). Если человек не понимает, что с этим кодом не так, даже после подсказки, если он не знает что такое bigO и почему с минимальными изменениями этот код начинает работать на порядки быстрее, то такой человек нам в команде не нужен.
Хотя в последнее время народ, претендующий на Senior позицию, не может решить даже задачу: выведите числа от 1 до 9 с интервалами 100ms, 200ms, 300ms… соответственно. Пишут такое, что у меня глаза на лоб лезут. Придумывают новый синтаксис языка даже. Такой человек бесполезен в команде. Его по сути придётся учить практически с нуля, несмотря на его 8-9 лет "продакшн опыта". А он просит квадратные деньги и его резюме переполнено модными базвордами.
Проблема обычно не с этим. Проблема с замыканиями и областью видимости. Народ упорно пишет решения которые выводят 9, 9, 9, 9… А когда понимают, что так дальше нельзя и надо пробросить в таймаут корректное значение — они начинают писать такое, что цензурными словами это не описать. Придумывают новый синтаксис, делают многоуровневые обёртки из самозапускаемых функций...
До того чтобы это ещё и выводилось с правильными интервалами доходят далеко не все. Задача вывести просто числа от 1 до 9 уже становится едва преодолимой преградой :)
Да. При написании SPA очень часто много обработки данных, трансформации их из одного в другое и пр… И там полно самых разных reducer-в, фильтров, map-ов и прочего. И разумеется надо понимать их алгоритмическую сложность.
Вы считаете что Frontend разработчик всего этого знать и уметь не должен? Вы его с верстальщиком не перепутали? :)
Хотя в последнее время народ, претендующий на Senior позицию, не может решить даже задачу: выведите числа от 1 до 9 с интервалами 100ms, 200ms, 300ms… соответственно. Пишут такое, что у меня глаза на лоб лезут.
И даже хуже. Сам в ужасе
Когда нанимают человека на позицию Senior Software Developer а он пишет O(n!), вместо O(n), то такого человека не лучше не брать.
А вы можете оценить сложность CSS селекторов? А парсинга JSX? А парсинга `template {var}`? Вообще о какой части времени выполнения мы говорим?
почему с минимальными изменениями этот код начинает работать на порядки быстрее, то такой человек нам в команде не нужен.
Это хорошо, правда, и я в восторге, что еще остались люди, которые занимаются оптимизацией. Но! Я про алгоритмическую сложность слышу из каждого утюга очень давно, а вижу десятки слоев абстракций с жутким оверхедом, тормоза на отрисовке 20 строчечных таблиц, жуткие утечки памяти и отчеты, формируемые по 10 минут.
При написании SPA очень часто много обработки данных, трансформации их из одного в другое и пр…
Пока вы между итерациями не перерисовываете DOM, плевать в принципе как вы обрабатываете данные.
Кроме того, при написании SPA, вы как правило работаете с очень ограниченным множеством объектов, не на что там по сути процессорное время тратить.
Это хорошо, правда, и я в восторге, что еще остались люди, которые занимаются оптимизацией. Но! Я про алгоритмическую сложность слышу из каждого утюга очень давно, а вижу десятки слоев абстракций с жутким оверхедом, тормоза на отрисовке 20 строчечных таблиц, жуткие утечки памяти и отчеты, формируемые по 10 минут.
Потому что сначала нанимают «крутых» сеньёров, которые заметят, что в reduce лучше не копировать массив через спред, а потом эти крутые сеньёры напишут что-нибудь не согласующееся с жизненным циклом либы/фреймворка, который они используют, и будут перерисовывать таблицу на 20 строк 20 же раз (и хорошо если не 20 * количество столбцов). И это они не заметят, потому что в их собственном коде всё прекрасно и оптимизировано жеж, и работает за O(1).
Тссс. Пусть наш друг и дальше пребывает в плену неведения того, как кривые алгоритмы в сочетании с другими кривыми алгоритмами и подходами, способны ронять как по памяти, так и по производительности — даже тривиальные задачи, чего уж там говорить про крупные SPA обрабатывающие бОльшие данные. А учитывая что товарищи не умеющие в это ^ практически всегда не умеют и в архитектуру, то поручить им что-то сложнее вёрстки (без тщательного присмотра) уже нельзя. Только рутину, и только под надзором. А кому нужен такой "senior"?
А учитывая, что наш друг похоже адепт размешивания на клиенте невменяемого объема данных, совсем грустно становится
Я писал системы которые на входе принимают несколько сотен мегабайт JSON-а в gzip. Бывало оно падало на JSON.parse от нехватки памяти на слабых системах. Была таска про это пару лет назад.
И SPA работал с этими данными. Да одновременно и да быстро, даже на слабых машинах. Толстый клиент, тонкий сервер. Клиент — текстово-объектный редактор очень для больших документов (например 900 страниц А4 бюджета какого-нибдуь города с одной дебильной таблицей) с произвольной разметкой. Тут нет выбора работать работать цельно или по кусочкам, т.к. работа по кусочкам в рамках задачи нецелесообразна (из-за структурной работы с документов, авторазметкой иерархии и других вещей, не хочу сейчас вдаваться в детали).
И таки оно прекрасно работало. Проблемы с DOM решались очень сложным виртуальным скроллом (тема для отдельной статьи). Остальные проблемы — это работа с самим данными документов. Так как там не было глупых неоптимизированных алгоритмов — работало оно быстро. И по памяти в пределах разумного. Пару раз правда пришлось чинить хитрые утечки памяти, т.к. приложение предполагалось для многочасовой вдумчивой работы, а сложной логики было много.
Работал также над системой построения расписаний. Там необходимо было на толстом клиенте держать цельный граф школы с данными о преподавателях, кабиентах, нормативах, классах и многом другом. Было много работы с данными. В частности от Vue пришлось отказаться ввиду того как он осуществляет обработку выяснения зависимостей одного computed значения от другого. Те самые алгоритмы.
К сожалению пока не работал с картографией (например яндекс-навигатор). Там тоже без математики и алгоритмов вы и шагу не сдвинетесь.
На самом деле полно разных SPA которые заменяют привычные нам desktop-приложения и требуют вычислений, алгоритмов, структур данных и др… Не всё лендинги.
P.S. Касательно вопросов про селекторы — не понимаю зачем вы спрашиваете про это вновь и вновь. До тех пор пока вы не отображае десятки тысяч элементов на одной странице разом даже вмеру сложные CSS-селекторы не будут бутылочным горлышком вашего приложения. Всё из-за той же асимптотики. Вы просто скорее всего не сможете в реальном приложении дойти до такого N когда css-селекторы начнут тормозить, т.к. DOM сам по себе начнёт тормозить на пару порядков раньше и вам потребуется его виртуализировать или перестраивать UI чтобы избежать самой такой задачи. Опять же эти вещи надо понимать. Это всё о тех же алгоритмах и структурах данных.
Если человек претендует на должность senior разработчика, то он должен сам всё это понимать и решать. Никто его за ручку водить не будет. Ожидается что он уже сформировавшийся программист.
Пусть наш друг и дальше пребывает в плену неведения того, что никакой алгоритм не спасет от утечки памяти, если не знать как работает сборщик мусора JS
Я разве где-то отрицал необходимость понимания того как избегать утечек памяти и знания принципа работы сборщика мусора (хотя бы напростом уровне)?.. К чему был этот пассаж?
Мне упорно кажется что вы фронтенд разработчиков в верстальщики записываете. Мне вот не очень важно умеет ли человек в css3-анимации и знает ли он 210 способов центрировать блок по вертикали. Этому можно и обезьяну научить. Мне важно чтобы он мог простым образом решать сложные вещи, мог решать их самостоятельно и быстро, без специального надзора. Это попросту невозможно если человек не умеет в простые алгоритмы, в простые структуры данных, в паттерны проектирования, в архитектуру приложений в целом и т.д… На ровном месте эти вещи не берутся.
Вот уметь при этом решать CSS-головоломки не так уж и важно. С приходом flexbox и grid эти задачи упростились на порядок.
Я писал системы которые на входе принимают несколько сотен мегабайт JSON-а в gzip
Я тоже, и что?)
И таки оно прекрасно работало
Вот это круто
В частности от Vue пришлось отказаться ввиду того как он осуществляет обработку выяснения зависимостей одного computed значения от другого
Не аргумент, используйте методы.
Работал также над системой построения расписаний.
Банальность, все работали.
Было много работы с данными.
Переусложняете
До тех пор пока вы не отображае десятки тысяч элементов на одной странице разом даже вмеру сложные CSS-селекторы не будут бутылочным горлышком вашего приложения
Вы уверены? document.querySelectorAll('tag[data-test=test]') не выглядит сильно простым селектором. К тому же в современном вебе 3к спокойно на ровном месте набегает за счет тучи оберток.
Это всё о тех же алгоритмах и структурах данных.
Не совсем.
когда css-селекторы начнут тормозить
что есть тормозить? если селектор выполняется дольше вашего кода это уже повод для беспокойства?
Если человек претендует на должность senior разработчика, то он должен сам всё это понимать и решать. Никто его за ручку водить не будет. Ожидается что он уже сформировавшийся программист.
Вне всякого сомнения, но не все это конечно, ибо все знать нельзя. Вот только вы предлагаете отсеивать многих из тех кто это понимает и решает на уровне знания расчет алгоритмической сложности.
Мне вот не очень важно умеет ли человек в css3-анимации и знает ли он 210 способов центрировать блок по вертикали.
А зря, эта важная часть UX
Этому можно и обезьяну научить.
А попробуйте. Это очень увлекательно я вам скажу.
К чему был этот пассаж?
Я вам уже говорил, про bigO и прочее я слышу из каждого утюга, вот натурально, отовсюду, а на практике за всей этой мишурой на выходе получаем тормозящее глючное непродуманное нечто. Я вон даже яндексу вагонами багрепорты кидаю (и еще полсотни просто кинуть влом)
Это попросту невозможно если человек не умеет в простые алгоритмы, в простые структуры данных, в паттерны проектирования, в архитектуру приложений в целом и т.д…
Да запросто.
На ровном месте эти вещи не берутся.
А на основе опыта — легко.
Вот уметь при этом решать CSS-головоломки не так уж и важно. С приходом flexbox и grid эти задачи упростились на порядок.
Серьеезно? А таблички с фиксированной шапкой работающие как таблицы а не как прибитые гвоздями поделки уже научились делать? Или, возможно, печать в броузерах поднялась с уровня win95?
Не аргумент, используйте методы
? с этим лучше в личку. Не понимаю причём тут методы. Там у меня древо вычислений. Одно базируется на втором, второе на третьем, третье на четвёртом, разные валидации. Очень сложная связанность данных.
Банальность, все работали
Не знаю никого кто бы работал. Да и хороших решений готовых не встречал. Точно не банально :)
Вы уверены? document.querySelectorAll('tag[data-test=test]') не выглядит сильно простым селектором. К тому же в современном вебе 3к спокойно на ровном месте набегает за счет тучи оберток.
Уверен. Даже были материалы на эту тему. Большая часть "убийц оптимизации" в css из нулевых, насколько я помню уже неактуальны. Это одно из последних мест куда стоит обратить свой взор при поиске проблемных мест. Лучше исходить из удобства проектирования приложения. Конечно до тех пор пока вы эти querySelectorAll в двойных циклах не вызываете.
если селектор выполняется дольше вашего кода это уже повод для беспокойства?
It depends. Нужен конкретный пример. Что угодно может стать поводом для беспокойства если поставить его в большой цикл. А это опять же алгоритмы.
Вот только вы предлагаете отсеивать многих из тех кто это понимает и решает на уровне знания расчет алгоритмической сложности.
Если мы говорим о senior должности то да, я отсеиваю (не предлагаю я именно отсеиваю) таких людей. Они не справятся с поставленными перед ними задачами. Сейчас я пытаюсь победить одну сложную мутную гонку состояний (react hooks + location.search + кое-какие округления). Мягко говоря не очень простая задача. Уже 2-й час ковыряюсь. Зачем мне в команду "синьор" которые не умеет решать такие задачи? Бойлерплейт писать?
А зря, эта важная часть UX
Это обычно легко гуглится. Меньше всего вызывает проблем вёрстка. Времена IE6-7-8 позади
а на практике за всей этой мишурой на выходе получаем тормозящее глючное непродуманное нечто
А с чего вы взяли что авторы глючного непродуманного решения умеют в bigO? Откуда такие выводы? :) Даже если эти авторы из yandex-а. Ну и я не спорю с тем что bigO это одна из многих ступенек, а не единственная.
Вот вы говорите что про оптимизации пишут на каждом утюге. А вы посмотрите где их применяют? Писать о них пишут, а в деле используют единицы. Да и пишут порой такое, что поубивал бы :)
А таблички с фиксированной шапкой работающие как таблицы а не как прибитые гвоздями поделки уже научились делать?
Безотносительно данной конкретной задачи (не хочу плодить холивар в холиваре). Вы серьёзно отрицаете что flexbox-ы и grid-ы значительно упростили нам жизнь? Нет правда, вы правда считаете что со времён inline-block и float вёрстки ничего не поменялось? Да я в 10 раз меньше стал верстать. И то верстальщик из меня ну совсем плохой, всё равно обычно с полпинка заводятся типовые кейсы, над которыми раньше приходилось корпеть.
Или, возможно, печать в броузерах поднялась с уровня win95?
Конечно. Прошлый раз когда я сталкивался с ней там уже были разрывы страниц и умные переносы. Хотя, наверняка, многое ещё впереди.
? с этим лучше в личку. Не понимаю причём тут методы. Там у меня древо вычислений. Одно базируется на втором, второе на третьем, третье на четвёртом, разные валидации. Очень сложная связанность данны
Меня тоже не всегда устраивает поведение computed, но нужно понимать, что они придуманы для реактивности и вы платите за это, если не устраивает то отказываемся от реактивности и реализуем на методах.
Да и хороших решений готовых не встречал
с этим влюбой области напряженка)
Конечно до тех пор пока вы эти querySelectorAll в двойных циклах не вызываете.
ужас какой
Зачем мне в команду «синьор» которые не умеет решать такие задачи?
Ну вот я например могу решить вашу задачу, почти наверняка, алгоритмическую сложность посчитать не могу и не хочу.
Это обычно легко гуглится. Меньше всего вызывает проблем вёрстка. Времена IE6-7-8 позади
UX это не только верстка знаете ли, это много чего еще. И нет, это не гяглится. И спецов по ux найти почти нереально ни за какие деньги.
Откуда такие выводы?
Дак вы чего, в яндексе как раз такие вещи спрашивают в первую же очередь) Ну и что что от их интерфейсов я устал плеваться, там же лучшие из лучших!
Нет правда, вы правда считаете что со времён inline-block и float вёрстки ничего не поменялось?
Немного упростили, да. Но для меня особо ничего не поменялось. Я и раньше не страдал, а находил изящные и рабочие решения.
Прошлый раз когда я сталкивался с ней там уже были разрывы страниц и умные переносы
Попробуйте в таблицу разрыв воткнуть. Обычная tfoot/thead/tbody таблица, и разрыв, да) А потом еще проверье в firefox/chrome. Подскажу сразу: в хром будет все хуже)
если не устраивает то отказываемся от реактивности и реализуем на методах.
А если я не хочу отказываться от реактивности? Я ради неё всё и затеял. Я переписал приложение на redux + react + reselect и оно решило проблему при точно такой же архитектуре древа вычислений и без observables. Если бы я писал это на knockoutJS то я бы тоже не столкнулся с такой проблемой, т.к. knockoutJS умеет в зависимости от computed.
Ну вот я например могу решить вашу задачу, почти наверняка, алгоритмическую сложность посчитать не могу и не хочу
Не собеседовании я бы не стал вас спрашивать вопрос: посчитайте мне bigO. Я бы дал вам кусочек кода и задал пару вопросов:
- всё ли с ним хорошо?
- что можно улучшить? как?
- что поменялось?
Т.е. если вы понимаете это в подкорке головного мозга, то этого уже хватает. Знание терминологии вторично.
И спецов по ux найти почти нереально ни за какие деньги.
Мне вот пока не везло. Имею ввиду что даже если бы такие спецы в конторе были им бы не дали работать. Хороший UX это тонны времени на нюансы. Везде где я работал времени на нюансы не давали вообще. Обычно даже на анимации не было времени. Бегом-бегом-бегом.
Дак вы чего, в яндексе как раз такие вещи спрашивают в первую же очередь
Но берут наверное почти всех :) Да и надо уметь свои навыки в leet code соотнести с реальными задачами.
Я и раньше не страдал, а находил изящные и рабочие решения.
Я прибегал к CSS время от времени и за эти интервали между ними — успевал забыть почти все "сакральные знания костылей". В итоге каждый раз приходилось решать эти головоломки почти с нуля. Сейчас число головоломок сократилось в разы.
Попробуйте в таблицу разрыв воткнуть
Опять тот же вопрос — что вы хотите доказать? Я говорю — стало сильно лучше. Вы говорите — разве? Я показываю примеры. Вы мне говорите а вот если так повернуть, то ломается. Но разве наличие непокрытых кейсов как-то опровергает тот факт, что стало лучше? До идеала далеко, но определённо HTML & CSS стали гораздо удобнее. Чего только css-variables + calc стоят. Многие вещи вроде horisontal aspect ratio стали тривиальными. А css-variables + svg css? А media queries? А тонны другого стафа. Разработчик из 2005 попади к нам попал бы в рай )
Т.е. если вы понимаете это в подкорке головного мозга, то этого уже хватает. Знание терминологии вторично.
Знаете в чем проблема с этим? Я обычно даже читать ленюсь, поскольку такие примеры довели до абсурда: то параметры местами поменяют, то опечатку в имени функции сделают, то вообще магию какую в магических методах __set, __get, то притащат какую то редко используемую функцию и потребуют знать как в этом случае она работает.
Хороший UX это тонны времени на нюансы.
Сажаем заказчиков пользовать это приложение и показываем им альтернативу. Сразу увидите как они запоют.
В итоге каждый раз приходилось решать эти головоломки почти с нуля. Сейчас число головоломок сократилось в разы.
А у меня каркас для SPA со времен iframe и я его только корректирую и дополняю, вся магия происходит без моего участия)
что вы хотите доказать
Не стало, как нельзя было css print использовать полноценно так и до сих пор нельзя. За 20 лет поменялось почти нифига в этом плане. Даже простейшая альбомная ориентация так и является камнем преткновения.
Чего только css-variables + calc стоят
Calc крутая штука, а css переменные конечно забавны, но не убер фича, если правильно и красиво организовывать css.
Разработчик из 2005 попади к нам попал бы в рай
Убедили) Но дело в том, что многие моменты десятилетиями без решений. У меня вот например есть крутая интерактивная таблица работающая на ваниле + data-, сейчас на vue.js для нового проекта делаем нечто похожее. И я вижу что многие вещи не сдвинулись. Разработчики как будто любят побольше ручного труда. Как пример я не возьму в толку почему нельзя компонент vue.js прибить к конкретному слоту прямо в его описании, чтобы не вынуждать пользователя твоего кода помнить слоты связанных компонентов.
Наглядно это кстати видно по шаблонам и дизайну. Возьмите любой: вот вам граффики вот свистелки, а футер для суммы таблицы мы сделать забыли да, и тулбар, и подружить это с пагинацией.
Наглядно это кстати видно по шаблонам и дизайну. Возьмите любой: вот вам граффики вот свистелки, а футер для суммы таблицы мы сделать забыли да, и тулбар, и подружить это с пагинацией.
Я за все эти годы пришел к выводу, что в хорошие компоненты никто не умеет не потому, что прям с технологиями плохо и заморочек много, а в том, что сделать хорошие расширяемые и настраиваемые компоненты UI — это на самом деле адский труд и очень серьезный rocket science. Ну, то есть, кнопочку сделать — еще как-то несложно. Табы там какие — чуть сложнее, но тоже могут. Таблицу? Тушите свет. Графики? Вообще забыть можно.
В простые случаи все умеют, но мало кто вообще осознаёт, что простые случаи никому практически не нужны, в лучшем случае нужна простая основа плюс ни разу не простая специфика. А вопросы безболезненного натягивания на очередные чудо-компоненты чего-нибудь своего решены дай бог у одного из двадцати. Нормальная основа, впрочем, тоже совсем не часто встречается, хотя вот казалось бы.
Поэтому хоть на дворе и 2019 год, а шаг влево или вправо — и уже всё самому делать. Ну и конечно не улучшает ситуацию то, что бизнес-модели за этим не видно никакой — профита делать крутую либу компонентов ради уменьшения труда интерфейсников — вообще никакого. В лучшем случае есть большая контора, которая этот свой труд у себя и сможет использовать, но это в отсутствие конкуренции идей и решений тоже всякую хрень порождает. Любой, кто material UI в руки брал — знает.
Сажаем заказчиков пользовать это приложение и показываем им альтернативу. Сразу увидите как они запоют
Никак не поют, всё наоборот. Как называешь цену решения — готовы на всё, лишь бы стоило дешевле. Одна и та же песня. Особенно если продукт вообще свой. Я сейчас работаю в стартапе. Никого не волнует что продукт сырой. НАШ продукт. Так задумано. Пока не взлетим — качество вторично
Вот ты это писал и слился, а поддерживать нам ...
Вас не смущает что вы в одном и том же комментарии жалуетесь на протекающие абстракции и утверждаете, что во фронтенде bigO не нужен?
Пока вы между итерациями не перерисовываете DOM, плевать в принципе как вы обрабатываете данные.
Кроме того, при написании SPA, вы как правило работаете с очень ограниченным множеством объектов, не на что там по сути процессорное время тратить.
О как. Вы знаете я пожалуй на этом спор закончу. У нас с вами очень разные фронтенд. И стало быть разные требования к программистам.
Вас не смущает что вы в одном и том же комментарии жалуетесь на протекающие абстракции и утверждаете, что во фронтенде bigO не нужен?
Ну, лично я это понял примерно так: "мы всё равно ни черта не знаем про bigO в алгоритмах внутри браузера, но видим, что чаще всего они оказываются медленнее любого нашего кода, а если вдруг это не так — профилировщик нам в помощь".
Вас не смущает что вы в одном и том же комментарии жалуетесь на протекающие абстракции и утверждаете, что во фронтенде bigO не нужен?
Вы можете сколько угодно оптимизировать ваши алгоритмы, но если, например, вы через все слои протащите ссылку на здоровый объект/текст полученный их xhr, то память у вас будет течь всегда. Я такое вижу очень и очень часто.
Кроме того, спрошу еще разок: у вас есть данные по скорости работы css селекторов? Правда интересно. Другое вопрос: вы в курсе, например, насколько медленная штука forEach?
О как. Вы знаете я пожалуй на этом спор закончу. У нас с вами очень разные фронтенд. И стало быть разные требования к программистам.
Действительно. Вы, уж извините, вероятно, из тех адептов, что кидают клиенту пол гига данных и весело их там размешивают? Тоже часто встречаю.
вы через все слои протащите ссылку на здоровый объект/текст полученный их xhr, то память у вас будет течь всегда.
В чём проблема в больших объектах полученных через xhr? Со строками там есть сложности, известная проблема. Но что вас смущает в объектах? Не храните лишних ссылок и не будет у вас утечек памяти. Если будут — репортите баги в v8.
Я кстати никсолько не отрицаю важности понимания работы сборщика мусора. Это снова алгоритмы. В некоторых задачах важно знать даже такие вещи как избегать stop-world (например держать пулы объектов). Про это были материалы.
Вы, уж извините, вероятно, из тех адептов, что кидают клиенту пол гига данных и весело их там размешивают?
Могу и так, если задача это подразумевает. Когда надо цельно работать с этим графом данных на стороне клиента. Стоит правда сразу уточнить что это в 99% случав или какой-нибудь редактор и/или закрытое приложение на заказ под конкретную контору и её сотрудников. Ныне web позволяет это решать. И если раньше сотни мегабайт грузили приложения на Delphi/C++/C#, то теперь их пережовывает и web. При условии что над этим работают не верстальщики.
В чём проблема в больших объектах полученных через xhr? Со строками там есть сложности, известная проблема. Но что вас смущает в объектах? Не храните лишних ссылок и не будет у вас утечек памяти. Если будут — репортите баги в v8.
Меня — ничего. Но вот современный веб нам показывает что как с этим работать не знает почти никто. С текстом кстати примерно тоже самое, что и с объектами, но менее очевидное.
Но вот современный веб нам показывает что как с этим работать не знает почти никто
Вероятнее всего, ни современный веб, ни сами разработчики этому виной не являются. Сам концепт разработки другой: разрабатывать продуманный и оптимизированный софт дорого, глючный и кривой, но полный "фич" — дешевле и выгоднее. А пользователи давно свыклись и с тормозами на пустом месте, и с мириадами багов. Бизнес конкурирует с другими бизнесами и играет по тем же правилам. В итоге если это не какой-нибудь очень критичный к багам и\или скорости софт, то скорость разработки сильно превалирует над качеством. Пока ты делаешь фичу хорошо она уже успевает устареть, конкуренты выпустили 3 других.
Грустно это или нет, другой вопрос. Но сглаживают углы уже почти все. Деньги с неба не берутся.
Это касается почти всех отраслей разработки ПО.
В итоге если это не какой-нибудь очень критичный к багам и\или скорости софт, то скорость разработки сильно превалирует над качеством. Пока ты делаешь фичу хорошо она уже успевает устареть, конкуренты выпустили 3 других
Чуднсно, и пока будет так, у меня всегда будет работа)
Вероятнее всего, ни современный веб, ни сами разработчики этому виной не являются
Являются. Потому что НИКТО не использует собственный софт.
Потому что НИКТО не использует собственный софт.
Вас обманули. Используют. Просто люди считают деньги. Ваша зарплата не из воздуха берётся. Пока кривой но быстро написанный софт приносит больше денег, чем хороший но долго и написанный, выбор будет в пользу первого. Вне зависимости от того, что вы или я об этом думаем.
Вот недавно вспоминается один проект (там правда мобилки а не веб):
есть сервис, у него есть клиенты, есть приложения на iOS и Android
одна из задач:
открывается экран, дергается REST API, приходит список телефонных номеров других пользователей сервиса. пользователь вводит частичный номер и надо показывать подпадающий под него список из контактов, но если это тоже пользователей — с особым значком, означающим что можно выполнить через сервиса определенную операцию с этим контактом. Разумеется этот экран должен летать всегда и везде, по крайней мерее быстрее чем пользователь вводит.
Была наивная реализация но появились жалобы что на адресной книге где то в 300 записей ощущаются некоторые лаги.
В наивной было много веселого вроде компиляции одного и того же регэкспа и потом поиска по этому регэкспу (а что — регэксп это ж дешево), в нескольких вложенных цикле и других милых особенностей. Причем писал вроде хорошо разбирающийся человек, решил что не надо преждевременно оптимизировать и надо решение в лоб(спросить нет возможности уже)?
Пришлось разбираться и анализировать какие и как операции выполняются, и какие из них — где надо бы выполнять.
Поиск получилось ускорить с 1 мс (на тестовом устройстве) на контакт до 0.02 мс + примерно 2 мс на подготовку, задача почти решена но начальство говорит что еще бы хоть раза в два быстрее на пользователях с кучей контактов в адресной книги, мол это VIP-пользователи и вообще не красиво, в итоге выяснилась небольшая особенность андроидного ContactProvider'а (и пришлось делать хитрить с кешем). Вот только без анализа алгоритмической сложности не получилось бы найти и решить главную проблему.
(То что клиентское приложение (из-за данной фичи) технически знает телефоны большинства других пользователей сервиса… ну знает, да, но не такая уж проблема, вот так просто трафик почитать не получится, у конкурентов есть аналоги данной фичи).
Была наивная реализация но появились жалобы что на адресной книге где то в 300 записей ощущаются некоторые лаги.
в нескольких вложенных цикле
Слабо представляю наивную реализацию в том виде, как вы ее описываете. Но увы и ах я с мобилками не работаю, хотя звучит интересно. Но в моем мире обычно вложенный цикл это либо крайне редкий и сложный случай, либо секира ждет писатели тех строк.
Вот только без анализа алгоритмической сложности не получилось бы найти и решить главную проблему.
Получилось бы, профилированием. Поймите меня правильно, все, кто так хорошо работает с UX — герои. В наше время — без преувеличений. Но для этого требуются знания, далеко выходящие за рамки оценки сложности алгоритмов. Мне лично оценка сложности последний раз потребовалась лет 9 назад, там был очень производительный серверный код, но по сути, это было баловство, поскольку с сетью и бд проводилась куда более тщательная работа. Можно вообще сказать, что про сложность алгоритма я не знаю ничего вообще, как и многие хорошие разработчики, но неоптимальный код вижу сразу, а если сомневаюсь — всегда проверю. И наконец: я пользуюсь своим продуктом, всегда, чего 95% программистов не делают вообще.
То что клиентское приложение (из-за данной фичи) технически знает телефоны большинства других пользователей сервиса… ну знает, да, но не такая уж проблема, вот так просто трафик почитать не получится, у конкурентов есть аналоги данной фичи
Почему не сделать наоборот? кинуть на сервак адресную книжку?
ЗЫ то что получилось это здорово, вот у меня сейчас проблема: страничка подтягивает к себе 200-2000 строк, рисует быстро, ui летает, но сервак отдает данные примерно за 350мс. Записей в базе — миллиарды, структуру не поменять от слова совсем, кэширование не вариант (вопрос инвалидации в данном случае не решаем), печаль в общем лютая.
Но в моем мире обычно вложенный цикл это либо крайне редкий и сложный случай, либо секира ждет писатели тех строк.
Человек без понимания основ легко пишет и тройные и какие-угодно другие вложенные циклы. И вообще строят n! на пустом месте. Принцип простой — "оно же работает". Делают последовательные запросы вместо параллельных, делают сотни запросов вместо одного. И многие другие грабли.
Получилось бы, профилированием
Очень велика вероятность, что когда профилирование UI проблемы выяснит где проблема — уже поздно. Поворотная точка бесповоротно позади. У приложения сломана сама архитектура и оно орудует данными не в том виде и не таким образом каким надо. Проблемы решались по мере их поступления без анализа предметной области. Человек решал задачу шаг за шагом не видя её в целом (как минимум кругозора\желания\навыков не хватило). В итоге под снос всё кроме favicon.ico.
Профилирование это не панацея.
И вообще строят n! на пустом месте.
Видел, знаю, проходил, для решения таких проблем (в том числе) есть код ревью.
Вообще я вот смотрю на ваше n-факториал и с трудом понимаю о чем вы. Хотя очень много лет посвятил решению проблем быстродействия и оптимизации скорости работы интерфейса и с интерфейсом.
Кроме всего прочего, поймите меня правильно, вот вы работаете с массивом, у вас варианты: for(;;), for(in), for(of), forEach(), Array.map(). И тут возникает моментик: разница в скорости работы между ними — 20 раз. Вероятно, можно даже выяснить почему, хотя не всегда. Оценка сложности алгоритма вам в данном случае не поможет никак.
Ну и как вишенка на торте: Array.prototype методы могут работать некорректно с объектами среды исполнения ибо зависят от реализации HasProperty.
оно же работает
Если пользователь ощущает как оно работает, значит нихрена не работает.
Делают последовательные запросы вместо параллельных, делают сотни запросов вместо одного.
А вот тут, кстати, привет от ORM с дикими оверхедами. И никого это в современном мире не парит. Я уж молчу про @аннотации, где такая магия происходит, что какая либо оценка алгоритмов вообще теряет всякий смысл.
Профилирование это не панацея.
оверинжиниринг тоже
для решения таких проблем (в том числе) есть код ревью.
Вы серьёзно предлагаете нанимать senior разработчика а потом изучать под микроскопом каждую строку кода? Code-review хоть и must have, но ни разу не silver bullet.
оверинжиниринг тоже
Про него я и не заикался. Сейчас мало кто на него способен. Уже лучше я остановлю коллегу от оверинжиниринга (да и себя порой надо), чем буду менторить каждый 1-ый "синьорский" шаг под микроскопом.
Вы определитесь с тем, что вы хотите мне доказать. Я пока решительно не понимаю. Я ведь не Kwisatz Haderach :)
Вы серьёзно предлагаете нанимать senior разработчика а потом изучать под микроскопом каждую строку кода? Code-review хоть и must have, но ни разу не silver bullet.
Каждую строчку — нет. А общий принцип, именования и комментарии — да. Меня уже трясет от свойств/полей типа anal от «сеньеров» и сэтим можно только смириться.
Вы определитесь с тем, что вы хотите мне доказать.
Хочу доказать что оценка сложности алгоритмов не silver bullet и нафиг не уперлась. Поймите меня правильно, я ровно с той же проблемной постоянно сталкиваюсь, только сейчас мне нужен мидл. У меня волосы на голове шевелятся от ужаса, половину спрашивать неочем, 10-15 лет опыта в резюме а человеку вообще не очем рассказать. У всех заявлен опыт работы с SQL а простейший запрос с union/join написать не могут.
И это при том, что когда я прихожу на собес, меня спрашиваю от уровня изоляций транзакций до алгоримтов работы кеша линуха.
ЗЫ шустро вы отвечаете, пока дописывал уже и ответ О_О
Kwisatz Haderach
Зачет)
И это при том, что когда я прихожу на собес, меня спрашиваю от уровня изоляций транзакций до алгоримтов работы кеша линуха.
Меня в Германии пока ни разу не спрашивали ни про какие кеши линукса. Спрашивают про "расскажите о том, как вы решаете рабочие конфликты", "вы не согласны с коллегой, что вы будете делать", и всякую дурь про BEM. Нормальных вопросов почти не было. В лучшем случае я обсуждал с интервьювером какие-нибудь нюансы современных фреймворков и es-next.
Один одногрупник как-то в году эдак 2013 запустил 20 самых больших инстансов AWS и не додумался их вырубить. Они проработали часов эдак 12.
В итоге 500$ на его карте уплыли мигом, но вся боль была в том что у карты был открыт overdraft и парень ушел в минус на 4000$. Последний раз когда его видел — он сказал уже расчитался с ним.
Кстати дело было в ночь с 30 на 31 декабря, так что это реальный ужастик был.
(спрашиваю как человек далекий от Apache Commons FTPClient)
«Но дело было не в бобине»
… Что делает опытный прожженный временем и бухгалтерами, 1С-разработчик, получив четкое формализованное задание «создать и выложить 3 файла с указанными именами»? Он пишет код который генерит содержимое файлов и код который их выкладывает на удаленный ФТП. Он даже имя им дает такое же, как в задании, прям буква в букву латинские!
А вот расширение файла… расширение файла он пишет с русской буквой «эс»…
ну он же в 1эс код пишет? в 1С, а не в 1си
логика железная надо заметить.
Ну как обычно :)
Ах, классика:) В первый раз не мог понять, почему не могу найти запись в базе, хотя копировал прямо из емайла. А потом понял, что русская А и английская A выглядят почти одинаково:)
Так что «в Азии приучены к засаде» (С) уже давно.
:-)))
Это насколько «красиво», что 1с-ников от праведного гнева, спасли тока наступившие новогодние каникулы :)
Уж потом появился Norton Commander с исправленным этим багом.
Так это наверное gross. А у нас социалку платит работодатель и вы её в бумагах не увидите. Их 50 в час, это что-то около 30 чистыми в час у нас, если наемным сотрудником.
Прям не верится. "Адекватные специалисты" от 16 килобаксов в месяц?
Если не ошибаюсь, в примере было что-то из Джанго. Я с ним сталкивался немного, ну… Не рокет сайенс. С Питоном (PyQt) работал плотно года три, (здесь даже осталась статья, по которой видно, как я наивно юзал кьютовские потоки в питоне, теперь смешно). Сейчас эмбеддед: Линукс, С, ядро, драйвера, юзерспейс. Изредка пишу для коллег гуевые/веб тулзы на Питоне. Как раз именно так изучил (поверхностно) Джанго и вообще ORM (понравилось, но привык иметь больший контроль над БД и писать все руками, оставляя доступ только через встраиваемые функции, догадываюсь, что это тоже возможно, но не дошел). Прям отдыхаю на таких вещах — как же все здесь проще. То задалбываешься без каких-либо доков искать, почему драйвер хост-контроллера не видит USB-устройство или пытаться понять, почему скорость работы связки samba/ntfs-3g ниже на 30%, чем у конкурентов, а то сидишь спокойно, читаешь доки и просто делаешь, что нужно.
Это я к чему… Моя зарплата даже не в 10 раз меньше.
«Адекватные специалисты» от 16 килобаксов в месяц?
В пересчете — да. Это если бы их нанимали на месяц на почасовой ставке… что если и происходит, то только в мегакорпорациях. Обычно же такие почасовые ставки характерны для сравнительно коротких проектов. Ну и чтобы совсем уточнить — 16 штук в месяц для разработчика-сениора в некоторых городах США — это не космос на постоянной основе. В том же Сан-Франциско это вообще скорее медиана, учитывая местные цены. Для какой-нибудь Оклахомы это скорее будет 8-10 в месяц сеньору, 5-6 джунам, но там и жизнь дешевле сильно. В среднем, на дом в ипотеку, пару машин (в кредит, если надо) и раз в год отпуск с семьей среднему айтишнику хватает, особенно если супруг/а работает.
Моя зарплата даже не в 10 раз меньше.
Это обидно. В этом году еще неделю будет работать DV visa program (она же «лотерея грин-карт»), попробуйте. Ну и параллельно учите язык и ищите места работы — руки тут нужны, деньги найдутся.
при полном рабочем дне это около 8к долларов в месяц, 96к в год
Делите часы сразу на два) При почасовке оплачивается только кодинг, а все остальные ваши активности связанные с работой(переговоры, поиск новых клиентов и тд) — за свой счет. Также не забудьте вычесть отпуск и больничные, которые при почасовке тоже за свой счет. Именно же набор кода занимает хорошо если половину от 8 часового дня
Только я сильно не уверен, что там не просто 50$ за разработку.
«1 ноября был ясный холодный день, дул сильный северный ветер. На старте шла подготовка к вечернему пуску. Я забежал после обеда в домик, включил приёмник, убедился в его исправности по всем диапазонам. В 14 часов 10 минут (здесь и далее время московское. — Авт.) вышел на воздух из домика и стал ждать условного времени. В 14 часов 15 минут при ярком солнце на северо-востоке вспыхнуло второе солнце. Это был ядерный взрыв в стратосфере — испытание ядерного оружия под шифром К-5. Вспышка длилась доли секунды.
Взрыв ядерного заряда ракеты Р-12 на высоте 60 километров проводился для проверки возможности прекращения всех видов радиосвязи. По карте до места взрыва было километров 500. Вернувшись быстро к приёмнику, я убедился в эффективности ядерного эксперимента. На всех диапазонах стояла полнейшая тишина. Связь восстановилась только через час с небольшим. Пуск по Марсу состоялся в 19 часов 14 мин»
"Электромагнитный импульс ядерного взрыва (ЭМИ) явился основным поражающим фактором во время испытания «К-3», 22 октября 1962 года. Его воздействие стало причиной помех в радиолокаторах системы ПВО на расстоянии около 1000 км. Подземный силовой кабель протяжённостью 1000 км, проходивший на глубине около 1 м и соединявший Целиноград и Алма-Ату, был выведен из строя. В наземных силовых ЛЭП отмечены пробои керамических изоляторов, вызвавшие короткие замыкания; на некоторых участках изоляторы были настолько повреждены, что провода упали на землю. Также электромагнитный импульс стал причиной возникновения пожаров из-за коротких замыканий в электроприборах. Один из пожаров возник на Карагандинской ТЭЦ-3, которая соединялась с подземным силовым кабелем. Была выведена из строя 570-километровая телефонная линия, проходящая над землёй. В последнем случае анализ показал наличие короткого (ок. 15 мкс) импульса тока от 1500 до 3400 ампер, вызванного быстрой, так называемой E1-компонентой ЭМИ, обусловленной синхротронным (магнитно-тормозным) излучением электронов, движущихся от места взрыва в геомагнитном поле, а также длинного (более 20 с) импульса тока в 4 ампера, индуцированного медленной E3-компонентой ЭМИ, которая вызывается магнитогидродинамическим взаимодействием возмущённой области атмосферы с геомагнитным полем. Детекторы в Карагандинской области зафиксировали скорость изменения индукции геомагнитного поля 1300 нТ/мин в течение 20 с после взрыва (E3-компонента ЭМИ); для сравнения, во время «Квебекского события» (геомагнитной бури 13—14 марта 1989 года) изменение геомагнитного поля со скоростью 480 нТ/мин в течение 92 секунд отключило всю энергосистему Квебека"
Понадобилось создать временную учетную запись для проверяющих, разблокировал свою рабочую станцию, зашел через RDP на контроллер домена под администратором, открыл оснастку добавление пользователя в домен и тут!
Т-р-р-р-р. Телефон. «Придите помогите, у нас видео конференция с министерством не конференция, а нам отчитываться надо!». Поднимаюсь из за стола, иду к двери кабинета и понимаю, что оставил разблокированную рабочую станцию с запущенным RDP сеансом котором открыт с администраторским доступом к контроллеру домена.
В кино обычно в этом момент из под соседнего стола или с потолка, выбирается злобный хакер, занимает оставленное рабочее место и быстренько делает что-то там с администраторскими правами. Задерганный админ возвращается через пять минут когда хакера и след простыл.
И вот это понимание всей киношности и одновременно реальности ситуации, остановило меня. Вернулся, отключился от контроллера домена, заблокировал сеанс пользователя на локальном АРМ, вышел из кабинета закрыл дверь на замок. И подумал: «А вот хрен вам злобные хакеры!»
И да, подключится удаленно к системе с видео конференции нельзя. Только ножками, ножками.
Да, это не самый разрушительный случай, но думаю самый киношный и в тоже время реальный.
«В жизни, как в кино? Вроде, как в кино. Но не как в кино!»(С)Наум Олев и А.Балагин
Эникей создал учетку audit c паролем 1234 для очередного бухгалтерского аудитора…
22 января
Учетка audit добавлена в групу бухгалтеров, тк аудитору нужно было сохранить какой-то отчет в общей папке бухгалтерии.
13 марта
На терминальном сервере, группа бухгалтерии добавлена в группу удаленных рабочих столов.
Терминальный сервер доступен из интернета на нестандартном порту.
15 мая
На терминальный сервер через rdp c китайского адреса заливают мешок майнеров, батников и powershell скриптов…
И ни один из них не удается запустить. Так как через групповые политики пользователям запрещено из профиля запускать все исполняемые файлы, кроме *.LNK
В тот раз пронесло…
Как-то раз пили похожую систему, только с email. 2 сервиса — первый находится в crm и отсылает api запрос, второй принимает его и шлет мыло/sms/api партнерам. Если сервис 2 (шлюз) не доступен то сервис 1 шлет запрос еще раз, после еслм не дошло откладывает сново шлет. Nginx шлюза обрубал запросы по timeout и сервис 1 постоянно слал одни и теже запросы на шлюз. В итоге 100000 одинаковых писем ушли партнерам и у одого из партнеров от этого сдох email сервер.
Как вы можете догадаться, скорость выполнения операций сотрудниками была медленная, от этого скапливались большие очереди.
В одном далеком н-ском уезде 90-е будто бы и не кончались. В скопившемся потоке ожидающих людей сначала изредка, а затем с завидной регулярностью начал выказывать своё «Фи» мужчина, щегольски одетый в кожанную куртку, наголо стриженный и носивший внушительные ювелирные украшения. С каждым разом резкость высказываний становилась выше и выше.
Война войной, а обед по расписанию. Из двух операционистов остался один. Очередь доходит до нашего недовольного героя, и вот незадача: кассира разлогинивает из тонкого клиента. Ввод пароля: ошибка. Очистка кэша-куки — без толку. Может капслок? Нет, всё в порядке. Не заходит, и всё тут.
Объясняюсь с мужчиной:
— Вы знаете, сейчас у нас внедряется новая программа, возникли технические трудности, не зависящие от нас, извините нас, пожалуйста, но сейчас не получится принять Вас.
— Вот прямо в тот самый момент, когда очередь подошла моя?
— Да, мне очень жаль.
— Ну, а*****, б**!
Он удалялся к выходу, добавляя дальше свои эмоциональные оценки происходящему.
Стоило уйти ему за дверь, как нам удалось залогиниться и начать работу, принимая более лояльных клиентов.
Эпилог:
А говорят, что у ПО нет души…
— Слушай, а через рот забеременеть можно?
— Ты че дура, нет конечно!
Финиш, мы все лежали еще минут 10.
Расчётом ведал MsSQL, ибо ERP была с толстыми клиентами и логично было вынести большую часть бизнес-логики в БД.
Разбираясь с функцией расчёта зарплат, оставшейся от внедренцев, которых почему-то выгнали на мороз не очень чистыми тряпками, задумался «А где же функция пересчёта начисления зп?» — работы почасовые, и их можно как добавить, так и убрать.
Всё оказалось просто: а нигде. Первый раз посчитали, выплатили деньги сотрудникам — и баста. А то, что договор может ещё пару лет продляться и наполняться сотнями часов (или наоборот, часы работ могут быть порезаны на порядок), внедренцы не учли.
Сообщаю восхитительную новость радостному от скорого сюрприза генеральному директору, радость улетучивается и у него.
Быстренько пишу скрипт сверки — сколько должно быть выплачено, сколько выплачено де-факто и дельту между ними по сотрудникам — и тут уже становится очень грустно: у кого-то за несколько лет скопилось несколько миллионов, у кого-то — тоже миллионы, но переплаченные и что делать — не очень понятно.
В итоге, пересчёт добавили на прод, долги простили, а невыплаченное выдали премиями в честь тёплых весенних дней или чего-то такого ( потому что объяснить, за что дают полтора млн разом, почему не дают другим и где денег взять — идея за гранью фантастики)
PS А ещё внедренцы с теста оставили чудесную кнопку на проде со стандартным названием «удалить всё» (всё, что на данном экране после применения фильтров), но удалявшую действительно всё, кроме справочников прямо в БД с правами sa. И я её нажал, думая о стандартном эффекте. Бэкапы спасли, но те 4 часа разбора «куда делись договора, клиенты и работы?!» вспоминаются совсем без удовольствия.
P.S. про вечер пятницы уточнил, потому что есть же аксиома «если кто-то рано на работе, то необязательно он рано пришел — может он еще не уходил», а значит, есть и ее обратная сторона и конец рабочего дня в пятницу может быть и утром тоже.
Вот это был стресс! Ведь как мне казалось, я потерял все семейные файлы и устроил диверсию по отношению к отцу. Он не мог работать, заказы «повисли». В итоге собравшись с мыслями и успокоившись. Нашел чужой старый компьютер чтобы с него выйти в сеть и как-то взаимодействовать с дисками. Мы жили в далёком городе, где даже не было на то время магазина с компьютерным железом, а про линукс и загрузочные CD и флешки я даже не знал. Стал читать форумы ИТ тематики с сообщениями людей, столкнувшимися с той же бедой. Оказалось, БИОС бэкапил себя на какой-то из секторов диска (деталей не помню) и убивал то ли MBR то ли FAT. И там кто-то оставил утилиту, исправляющую последствия такого кривого бэкапа. Все удалось починить, файлы оказались в сохранности. Сейчас, оцениваю насколько были глупы эти действия и как мне повезло, что утилита оказалась работающей корректно.
Был солнечный день, я сидел в своём сисадминском кабинете, читал айтишные новости, изучал новые технологии и думал о вечном —
Страшилка моей молодости:
Давным-давно, в одном местном советско-российском ВЦ (вычислительный центр), когда балом правили XT (кто-нибудь практиковал парковку головок MFM HDD дисков на них? Я — да!), но уже встречались и i386, я работал БД-программистом и автоматизировал работу бухгалтерий предприятий (да, тогда ещё не пахло 1С от слова совсем), санаториев и прочих спецавтохозяйств. У меня был отдельный кабинет с несколькими XT и одной XT286 с кнопочкой Turbo :). В тот момент я разрабатывал, дорабатывал и поддерживал программу учёта путевых листов для САХ (хозяйство по вывозу мусора), данные в программу вводили женщины-операторы машинного зала (была такая профессия) EC, а мужики, которые обслуживали эту штуку приходили ко мне и гоняли в Диггера. В один прекрасный момент, когда первичный ввод был завершён и всё было замечательно, я сел за компьютер с базой путевых листов (не за своим же это делать?) и решил поразбираться с утилитами от моего любимого программиста — Питера Нортона. В результате изучения утилит был получен огромный опыт в области уничтожения данных, форматирования диска и двухмесячного сидения за компьютером с вводом данных с нуля.
Каждый вечер делался бэкпа БД и после на нем в ручную запускали задание на обезличивание(в окошке IDE).
И вот разработчик ошибается окошком, запускает скрипт на боевой БД, смотрит в монитор и повторяет «Горшочек, не вари»
История закончилась хорошо, спасибо администраторам, которые не только делают бэкапы, но и проверяют что БД из них разворачивается.
Я позвал финдиректора, и стал ей объяснять как пользоваться программой. Финдиректор радостно кивает. Воодушевленный, я с радостью запускаю программу, на экране начинается обратный отсчет,
5...4...3…
я пафосно произношу фразу, что сейчас всё будет уничтожено если не нажать ESC.
Лихо клацаю по эскейпу и… отсчет продолжается 2...1...0…
Волосы у меня встают дыбом. Я понимаю, что всем базам данных пришел северный пушистый зверь. А сердце выпрыгивает и оказывается где-то в районе пяток. Но… ничего не происходит. Бухгалтерши также спокойно стучат по клавишам и обсуждают недоступные мне материи — что-то о проводках, счетах и этих… контрагентах.
Моё сердце впрыгивает обратно в грудную клетку. С ленцой я выдаю (выдавливаю) фразу — «Ну… вот. Примерно так. Теперь надо на боевой режим поставить и готово». Финдиректор кивает и уходит. Я открываю текст, нахожу элементарный баг, исправляю и иду на кухню успокаивать нервы чаем.
sudo rm –fr /Не вижу ничего страшного в этой команде. Это же просто удаление всех французских файлов, а они обычно не нужны.
Пссс, хотите немного ужасных IT-историй?