Пссс, хотите немного ужасных IT-историй?

    Боитесь ли вы темноты? Может быть, зомби-апокалипсиса или чудовища под кроватью? Мы знаем, что нет. У нас, айтишников, свои источники ужаса: криворукие пользователи, далёкие от IT начальники, упавшие сервера, пропавшие или не сделанные бэкапы, легаси код и Agile-митинги, когда на самом деле вся разработка управляется вскриками «ещё вчера», «заказчик мечет», «там критикал на проде». Накануне Хэллоуина мы решили найти самые ужасные истории, рассказать пару своих, а заодно услышать ваши. Ну что, готовы рассказать холодящие душу байки? 


    Лёгкая разминка до мурашек


    Начнём с одной очень простой функции. По идее она должна проверять, является ли число простым. 

    bool primeCheckUgly(unsigned long long int n){//good luck
        ...

    Ну раз комментарий пожелал нам удачи, то вы точно готовы увидеть скриншот полного кода этой функции. Готовы? Ну?


    А что делает фрагмент кода на следующем скриншоте?


    Бу!
    Проверяет, является ли число нечётным. А вы что подумали?

    Время страшных историй с Reddit


    История 1


    Очень длинный и страшный листинг - мы предупредили!


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

    • кошмарные угрозы безопасности, SQL-уязвимости
    • проблемы с поддержкой кода (монолит на 3,5 тыс. строк)
    • проблемы с масштабированием
    • ужасные приёмы, функции и организация кода (автор не пожалел пробелов)
    • плохая структурированность и читабельность кода.

    Суровые читатели посоветовали оставить как есть и извлечь урок для бизнеса (да-да, мы как хостинг-провайдер тоже знаем, какие бедовые клиенты приходят от «бесплатных» провайдеров от сохи). Ну и точки над i расставил лучший комментарий: «If not for alcohol, most code I see would keep me up too» (Если бы не алкоголь, большая часть увиденного кода мне тоже не дала бы уснуть). 

    История 2


    Онлайн-учебник рассматривает каждое слово как отдельный HTML-элемент, поэтому копировать и вставить более 10 слов на параграф невозможно. Однако местами Реддит это почти как Хабр, поэтому в комментариях лишь несколько пользователей отозвались об авторе кода как о му**ке, остальные дали множество советов как обойти эту фичу и заполучить весь текст в лучшем виде. Если кому-то нужны способы, о них можно прочитать в самом треде.


    История 3


    Этому парню платили за такой код 50$ в час, и он сотворил (наговнокодил) целый файл длиной более 3000 строк. 

    Заказчик сам виноват, порешило сообщество, потому что 50$ это копейки, а значит, рассчитывать можно только на найм «обезьяны». Некоторые решили, что это просто плохая шутка и парень нагонял себе часы. Ну а подробный разбор того, что в коде не так, в треде


    История 4


    Это, конечно, рассказ, граничащий с фантастикой, но кто на заре прекрасной юности не творил что-то подобное. 

    Парень был слишком ленив, чтобы выбрать все файлы в директории и не придумал ничего лучше, как воспользоваться утилитой 

    rm -rf /* 

    Но что-то, видимо, в душе ёкнуло и он обратился к своему СТО, правильный ли выбран ход мысли, парень получил подтверждение и… ну вы поняли. Комментарии доставляют на сто процентов: «как вкусны твои слёзы» «бессмысленно спрашивать технического управленца, как удалять файлы в Linux», «вы, должно быть, не очень освоились с Linux» (нам думается, там ещё нелады с гуглом и здравым смыслом), «фейл!». Нам думается, что история больше похожа на байку, но именно от неё прошёл по спине недобрый холодок и как-то сразу захотелось выйти из-под root. Кстати, несколько полезных советов там тоже есть.

    История 5


    Байка, похожая на предыдущую. Одной командой :-)

    sudo rm –fr /

    Бу!
    А ничего здесь страшного нет.

    История нашего знакомого из его прошлого опыта


    «2008 год. Наш сайт взломали. Это был нормальный, защищённый сайт, на который заходило более 5000 человек в сутки. И вот на главной появился текст с ошибками, про Пентагон и угрозы забрать у нас сто миллионов (к слову, это была лишь часть выручки компании). СБ-шники на ушах, директор в панике, СТО мылил верёвку, разработчики бежали за вазелином. Ничего. Закрыли сайт, повесили 404, получили шквал звонков. На следующий день пришла мама а-ля Анфиса Чехова в лучшем соку и привела совершенно замученного пацанчика 16 лет в очках. Говорит: «Это мой сын, он хакер,  возьмите его на работу». СТО вылез из петли, взял малого за плечико и заставил показать брешечку (подробности нам уже не огласили), маме рассказали про УК РФ, но парню что-то подарили». 

    В общем, человеческий фактор — причина того, что у каждого из нас в любой рабочий день может случиться свой персональный Хэллоуин.

    Как не стать героем таких историй для своих коллег


    Советы программистам


    • Комментируйте код, особенно если вы новичок в разработке. Это поможет и вам, и коллегам, и тем, кто войдёт в проект намного позже.
    • А ещё лучше пишите читабельный код. Код — ни что иное, как особый язык общения команды программистов. Хороший код самодостаточен, помните об этом. Пусть в нём разберутся даже те, кто придёт в команду после вас. 
    • Называйте переменные и функции нормальными лексическими единицами, чтобы можно было понять, что они должны делать. FsskdQwertZeta плохо MoveEmployeeFromList нормально. 
    • Следуйте принятому в компании code style — благодаря этому проект будет не только понятным, но и безопасным: любой разработчик команды сможет в экстренной ситуации внести правки, не тратя время на распутывание то ли обфускации, то ли плохого стиля.
    • Не плодите мусор в коде, модулях, проектах. Удаляйте ненужные модули, не тащите за собой нерабочий легаси, по возможности рефакторьте, чтобы выкинуть костыли и переплавить велосипеды на хороший код.
    • Тестируйте свой код, проверяйте реальные сценарии. Если вы не протестируете код, его протестирует прод :-)

    Советы системным администраторам


    • Документируйте свою работу, чтобы вашим коллегам, сменщикам и вам самому было проще разобраться в стандартных сценариях.
    • Делайте бэкапы. Делайте, мать их, бэкапы!
    • Автоматизируйте свою работу, используйте тикет-системы и системы мониторинга.
    • Работайте только по заявке — так вы сможете доказать, что вы работаете, а не гоняете в Доту, и «просто перезалить базу 1С» это не «просто».
    • Выстраивайте систему информационной безопасности в компании, предупреждайте правонарушения со стороны коллег и особо ретивых «продвинутых пользователей».
    • Логируйте, журналируйте, храните записи.
    • Имейте подменный фонд периферии и железа, управляйте лицензиями, бюджетируйте — будьте ИТ-менеджером, а не просто парнем «по вызову».

    Очевидно, не правда ли? Но соблюдение этих нехитрых принципов закроет больше ⅔ возможных проблем, которые рискуют обратиться в леденящие душу истории на Хабре, Реддите и других ресурсах, где готовы обсудить ваш лютый факап.  

    Друзья, сегодня, в Хэллоуин, мы жаждем леденящих душу историй и вашей IT-практики. От чего у вас потели ладони, темнело в глазах и холодело внутри? За лучшую историю (с самым высоким рейтингом комментария) вручим призы. За первое место — толстовку с автографом thelevelord, создателем Duke Nukem:


    За второе место — запас носков на целый год :)
    RUVDS.com
    1 297,16
    RUVDS – хостинг VDS/VPS серверов
    Поделиться публикацией

    Комментарии 105

      +15
      Из недавнего.
      «Матрешка» RDP на тестовый стенд с БД.
      Нужно быстро почистить тестовые данные для того чтобы уместилась новая порция.
      Пишу truncate table оченьважнаятаблица

      В последний момент перед запуском решаю проверить, а много ли данных и нужно ли вообще очищать стенд?
      Пишу count(*) from оченьважнаятаблица
      И тут у меня потеют ладошки. Возвращаемое значение превышает на пару порядков возможности тестового стенда.

      В последнем уровне «матрешки» -на стенде БД кто-то оставил RDP во весь экран на продуктовый сервер БД.

      Вот так обычное число может напугать не хуже фильма ужасов.

      PS: Доступ закрыли, невиновных наказали, а непричастных наградили, конечно :)
        +5
        Я на такой случай консольки боевых серверов и всяких phpmyadmin'ов раскрашиваю в красные цвета…
          0
          А я, однажды, таки сделал…
          :-))))
            0
            Напомнило, похожую историю. Мониторинговый центр одного из опсосов.
            На каждый комп, обычно по 2 монитора, на которых во весь экран обычно работает какая-то система мониторинга.
            На одной из систем, возникает авария и инженер центра по процедуре делает скрин и отправляет кому следует, со второго монитора.
            Дальше, спокойно сдает смену забыв свернуть скрин и идет домой. О, том что с системой мониторинга что-то не так, заметили аж под утро :))) (благо, что ничего серьезного не произошло).
            +4
            Автор круто продумал. От первого скримера (спойлер с большим кодом нахождения простого числа) я чуть со стула не упал.
              0
              Первый довольно просто в excel сгенерить и скопипастить, зато работает быстро )))
              А вот второй — нечётное число… Ухххх… Это был великий индус…
                0

                так там прога упадёт от переполнения стёка. так что это нереальный, выдуманный пример.

                  0

                  Эта рекурсия вполне может развернуться в цикл.

              +8

              Страшилка про современный уровень разработчиков.


              На собеседование пришел Senior Frontend React-Rocket-Cosmic разработчик с серьезными запросами по компенсации его труда.
              После устной беседы решили дать ему задание: написать какой-то банальный reducer коллекции.
              Он написал, показал интервьюерам.
              Потом у него спрашивают:
              — Можно этот reducer упростить до O(log n)?
              Он говорит:
              — Нет, нельзя.
              — Почему? — интересуются интервьюеры.
              И тут гениальный ответ:
              — Потому что интерпретатор JS не понимает такой синтаксис и будет ошибка.

                +18
                оценка сложности алгоритма? неужто этим кто-то еще страдает в мире фронтенда?
                  +1
                  не в обиду будет сказано, но это как задать питон разработчику «Любите ли вы красный цвет в своем интерфейсе на qml?»
                  p.s. для тех кто не вкурсе, большинство служителей питона, чихать хотели на интерфейс своих решений. Пашет и ок. Нейросетка распознала лицо? выведем табличку и ок. Остальное отдадим на фронт RestApi-шкой фронтендщикам и запакуем в Electron(зато красиво и везде пашет).
                    0

                    Это сильно! :)

                      0
                      А фронтендер у вас конечно каждый день пишет редьюсеры и оценивает алгоритмическую сложность алгоритмов?
                        0
                        Не знаю насчет пишет, но использует он алгоритмы(поиск, сортировка, деревья всякие) каждый день и было бы неплохо оценить их сложность. То есть оценку асимптотики любой фронтендер делает каждый день. Если знает что это такое конечно. А ответ соискателя подсказывает, что он вообще не знает что это.
                          0
                          И что? Вы в курсе сколько раз менялась скорость работы javascript foreach? Я к тому, что вы можете хоть запереоценивать ваши алгоритмы, но один вот такой форич запросто может сожрать весь профит который вы на этом получили и не получили. Для этого есть профайлер.

                          А вообще: хороший программист пишет глупым кодом гениальные вещи, а не наоборот.
                          +5

                          Когда нанимают человека на позицию 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 лет "продакшн опыта". А он просит квадратные деньги и его резюме переполнено модными базвордами.

                            0
                            Да ладно. Неужели текущее значение индекса цикла не догадаться на каждой итерации умножать на 100? Уж на что я не настоящий сварщик и то на пятой секунде сообразил…
                              0

                              Проблема обычно не с этим. Проблема с замыканиями и областью видимости. Народ упорно пишет решения которые выводят 9, 9, 9, 9… А когда понимают, что так дальше нельзя и надо пробросить в таймаут корректное значение — они начинают писать такое, что цензурными словами это не описать. Придумывают новый синтаксис, делают многоуровневые обёртки из самозапускаемых функций...


                              До того чтобы это ещё и выводилось с правильными интервалами доходят далеко не все. Задача вывести просто числа от 1 до 9 уже становится едва преодолимой преградой :)

                                0
                                Мда, какая-то жесть…
                            0

                            Да. При написании SPA очень часто много обработки данных, трансформации их из одного в другое и пр… И там полно самых разных reducer-в, фильтров, map-ов и прочего. И разумеется надо понимать их алгоритмическую сложность.


                            Вы считаете что Frontend разработчик всего этого знать и уметь не должен? Вы его с верстальщиком не перепутали? :)

                              0
                              Хотя в последнее время народ, претендующий на Senior позицию, не может решить даже задачу: выведите числа от 1 до 9 с интервалами 100ms, 200ms, 300ms… соответственно. Пишут такое, что у меня глаза на лоб лезут.

                              И даже хуже. Сам в ужасе

                              Когда нанимают человека на позицию Senior Software Developer а он пишет O(n!), вместо O(n), то такого человека не лучше не брать.

                              А вы можете оценить сложность CSS селекторов? А парсинга JSX? А парсинга `template {var}`? Вообще о какой части времени выполнения мы говорим?

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

                              Это хорошо, правда, и я в восторге, что еще остались люди, которые занимаются оптимизацией. Но! Я про алгоритмическую сложность слышу из каждого утюга очень давно, а вижу десятки слоев абстракций с жутким оверхедом, тормоза на отрисовке 20 строчечных таблиц, жуткие утечки памяти и отчеты, формируемые по 10 минут.

                              При написании SPA очень часто много обработки данных, трансформации их из одного в другое и пр…

                              Пока вы между итерациями не перерисовываете DOM, плевать в принципе как вы обрабатываете данные.
                              Кроме того, при написании SPA, вы как правило работаете с очень ограниченным множеством объектов, не на что там по сути процессорное время тратить.
                                +1
                                Это хорошо, правда, и я в восторге, что еще остались люди, которые занимаются оптимизацией. Но! Я про алгоритмическую сложность слышу из каждого утюга очень давно, а вижу десятки слоев абстракций с жутким оверхедом, тормоза на отрисовке 20 строчечных таблиц, жуткие утечки памяти и отчеты, формируемые по 10 минут.

                                Потому что сначала нанимают «крутых» сеньёров, которые заметят, что в reduce лучше не копировать массив через спред, а потом эти крутые сеньёры напишут что-нибудь не согласующееся с жизненным циклом либы/фреймворка, который они используют, и будут перерисовывать таблицу на 20 строк 20 же раз (и хорошо если не 20 * количество столбцов). И это они не заметят, потому что в их собственном коде всё прекрасно и оптимизировано жеж, и работает за O(1).
                                  0

                                  Тссс. Пусть наш друг и дальше пребывает в плену неведения того, как кривые алгоритмы в сочетании с другими кривыми алгоритмами и подходами, способны ронять как по памяти, так и по производительности — даже тривиальные задачи, чего уж там говорить про крупные SPA обрабатывающие бОльшие данные. А учитывая что товарищи не умеющие в это ^ практически всегда не умеют и в архитектуру, то поручить им что-то сложнее вёрстки (без тщательного присмотра) уже нельзя. Только рутину, и только под надзором. А кому нужен такой "senior"?

                                    0
                                    Уронить что-то даже с прекрасными алгоритмами — дело нехитрое. Тут речь как раз о том, что в первую очередь фронтэнд-сеньёру надо совсем другие вещи иметь в виду, нежели big O.
                                      0
                                      Тссс. Пусть наш друг и дальше пребывает в плену неведения того, что никакой алгоритм не спасет от утечки памяти, если не знать как работает сборщик мусора JS, а уж по производительность и говорить нет смысла, ведь нигде не прописана точная сложность селекторов и перерисовки DOM. А учитывая, что наш друг похоже адепт размешивания на клиенте невменяемого объема данных, совсем грустно становится.
                                        +1
                                        А учитывая, что наш друг похоже адепт размешивания на клиенте невменяемого объема данных, совсем грустно становится

                                        Я писал системы которые на входе принимают несколько сотен мегабайт 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 эти задачи упростились на порядок.

                                          0
                                          Я писал системы которые на входе принимают несколько сотен мегабайт JSON-а в gzip

                                          Я тоже, и что?)

                                          И таки оно прекрасно работало

                                          Вот это круто

                                          В частности от Vue пришлось отказаться ввиду того как он осуществляет обработку выяснения зависимостей одного computed значения от другого

                                          Не аргумент, используйте методы.

                                          Работал также над системой построения расписаний.

                                          Банальность, все работали.

                                          Было много работы с данными.

                                          Переусложняете

                                          До тех пор пока вы не отображае десятки тысяч элементов на одной странице разом даже вмеру сложные CSS-селекторы не будут бутылочным горлышком вашего приложения

                                          Вы уверены? document.querySelectorAll('tag[data-test=test]') не выглядит сильно простым селектором. К тому же в современном вебе 3к спокойно на ровном месте набегает за счет тучи оберток.

                                          Это всё о тех же алгоритмах и структурах данных.

                                          Не совсем.

                                          когда css-селекторы начнут тормозить

                                          что есть тормозить? если селектор выполняется дольше вашего кода это уже повод для беспокойства?

                                          Если человек претендует на должность senior разработчика, то он должен сам всё это понимать и решать. Никто его за ручку водить не будет. Ожидается что он уже сформировавшийся программист.

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

                                          Мне вот не очень важно умеет ли человек в css3-анимации и знает ли он 210 способов центрировать блок по вертикали.

                                          А зря, эта важная часть UX

                                          Этому можно и обезьяну научить.

                                          А попробуйте. Это очень увлекательно я вам скажу.

                                          К чему был этот пассаж?

                                          Я вам уже говорил, про bigO и прочее я слышу из каждого утюга, вот натурально, отовсюду, а на практике за всей этой мишурой на выходе получаем тормозящее глючное непродуманное нечто. Я вон даже яндексу вагонами багрепорты кидаю (и еще полсотни просто кинуть влом)

                                          Это попросту невозможно если человек не умеет в простые алгоритмы, в простые структуры данных, в паттерны проектирования, в архитектуру приложений в целом и т.д…

                                          Да запросто.

                                          На ровном месте эти вещи не берутся.

                                          А на основе опыта — легко.

                                          Вот уметь при этом решать CSS-головоломки не так уж и важно. С приходом flexbox и grid эти задачи упростились на порядок.

                                          Серьеезно? А таблички с фиксированной шапкой работающие как таблицы а не как прибитые гвоздями поделки уже научились делать? Или, возможно, печать в броузерах поднялась с уровня win95?
                                            0
                                            Не аргумент, используйте методы

                                            ? с этим лучше в личку. Не понимаю причём тут методы. Там у меня древо вычислений. Одно базируется на втором, второе на третьем, третье на четвёртом, разные валидации. Очень сложная связанность данных.


                                            Банальность, все работали

                                            Не знаю никого кто бы работал. Да и хороших решений готовых не встречал. Точно не банально :)


                                            Вы уверены? 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?

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

                                              0
                                              ? с этим лучше в личку. Не понимаю причём тут методы. Там у меня древо вычислений. Одно базируется на втором, второе на третьем, третье на четвёртом, разные валидации. Очень сложная связанность данны

                                              Меня тоже не всегда устраивает поведение computed, но нужно понимать, что они придуманы для реактивности и вы платите за это, если не устраивает то отказываемся от реактивности и реализуем на методах.

                                              Да и хороших решений готовых не встречал

                                              с этим влюбой области напряженка)

                                              Конечно до тех пор пока вы эти querySelectorAll в двойных циклах не вызываете.

                                              ужас какой

                                              Зачем мне в команду «синьор» которые не умеет решать такие задачи?

                                              Ну вот я например могу решить вашу задачу, почти наверняка, алгоритмическую сложность посчитать не могу и не хочу.

                                              Это обычно легко гуглится. Меньше всего вызывает проблем вёрстка. Времена IE6-7-8 позади

                                              UX это не только верстка знаете ли, это много чего еще. И нет, это не гяглится. И спецов по ux найти почти нереально ни за какие деньги.

                                              Откуда такие выводы?

                                              Дак вы чего, в яндексе как раз такие вещи спрашивают в первую же очередь) Ну и что что от их интерфейсов я устал плеваться, там же лучшие из лучших!

                                              Нет правда, вы правда считаете что со времён inline-block и float вёрстки ничего не поменялось?

                                              Немного упростили, да. Но для меня особо ничего не поменялось. Я и раньше не страдал, а находил изящные и рабочие решения.

                                              Прошлый раз когда я сталкивался с ней там уже были разрывы страниц и умные переносы

                                              Попробуйте в таблицу разрыв воткнуть. Обычная tfoot/thead/tbody таблица, и разрыв, да) А потом еще проверье в firefox/chrome. Подскажу сразу: в хром будет все хуже)
                                                +1
                                                если не устраивает то отказываемся от реактивности и реализуем на методах.

                                                А если я не хочу отказываться от реактивности? Я ради неё всё и затеял. Я переписал приложение на 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 попади к нам попал бы в рай )

                                                  0
                                                  Т.е. если вы понимаете это в подкорке головного мозга, то этого уже хватает. Знание терминологии вторично.

                                                  Знаете в чем проблема с этим? Я обычно даже читать ленюсь, поскольку такие примеры довели до абсурда: то параметры местами поменяют, то опечатку в имени функции сделают, то вообще магию какую в магических методах __set, __get, то притащат какую то редко используемую функцию и потребуют знать как в этом случае она работает.

                                                  Хороший UX это тонны времени на нюансы.

                                                  Сажаем заказчиков пользовать это приложение и показываем им альтернативу. Сразу увидите как они запоют.

                                                  В итоге каждый раз приходилось решать эти головоломки почти с нуля. Сейчас число головоломок сократилось в разы.

                                                  А у меня каркас для SPA со времен iframe и я его только корректирую и дополняю, вся магия происходит без моего участия)

                                                  что вы хотите доказать

                                                  Не стало, как нельзя было css print использовать полноценно так и до сих пор нельзя. За 20 лет поменялось почти нифига в этом плане. Даже простейшая альбомная ориентация так и является камнем преткновения.

                                                  Чего только css-variables + calc стоят

                                                  Calc крутая штука, а css переменные конечно забавны, но не убер фича, если правильно и красиво организовывать css.

                                                  Разработчик из 2005 попади к нам попал бы в рай

                                                  Убедили) Но дело в том, что многие моменты десятилетиями без решений. У меня вот например есть крутая интерактивная таблица работающая на ваниле + data-, сейчас на vue.js для нового проекта делаем нечто похожее. И я вижу что многие вещи не сдвинулись. Разработчики как будто любят побольше ручного труда. Как пример я не возьму в толку почему нельзя компонент vue.js прибить к конкретному слоту прямо в его описании, чтобы не вынуждать пользователя твоего кода помнить слоты связанных компонентов.

                                                  Наглядно это кстати видно по шаблонам и дизайну. Возьмите любой: вот вам граффики вот свистелки, а футер для суммы таблицы мы сделать забыли да, и тулбар, и подружить это с пагинацией.
                                                    +2
                                                    Наглядно это кстати видно по шаблонам и дизайну. Возьмите любой: вот вам граффики вот свистелки, а футер для суммы таблицы мы сделать забыли да, и тулбар, и подружить это с пагинацией.

                                                    Я за все эти годы пришел к выводу, что в хорошие компоненты никто не умеет не потому, что прям с технологиями плохо и заморочек много, а в том, что сделать хорошие расширяемые и настраиваемые компоненты UI — это на самом деле адский труд и очень серьезный rocket science. Ну, то есть, кнопочку сделать — еще как-то несложно. Табы там какие — чуть сложнее, но тоже могут. Таблицу? Тушите свет. Графики? Вообще забыть можно.

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

                                                    Поэтому хоть на дворе и 2019 год, а шаг влево или вправо — и уже всё самому делать. Ну и конечно не улучшает ситуацию то, что бизнес-модели за этим не видно никакой — профита делать крутую либу компонентов ради уменьшения труда интерфейсников — вообще никакого. В лучшем случае есть большая контора, которая этот свой труд у себя и сможет использовать, но это в отсутствие конкуренции идей и решений тоже всякую хрень порождает. Любой, кто material UI в руки брал — знает.
                                                      0
                                                      Сажаем заказчиков пользовать это приложение и показываем им альтернативу. Сразу увидите как они запоют

                                                      Никак не поют, всё наоборот. Как называешь цену решения — готовы на всё, лишь бы стоило дешевле. Одна и та же песня. Особенно если продукт вообще свой. Я сейчас работаю в стартапе. Никого не волнует что продукт сырой. НАШ продукт. Так задумано. Пока не взлетим — качество вторично

                                              0

                                              Вот ты это писал и слился, а поддерживать нам ...

                                      0

                                      Вас не смущает что вы в одном и том же комментарии жалуетесь на протекающие абстракции и утверждаете, что во фронтенде bigO не нужен?


                                      Пока вы между итерациями не перерисовываете DOM, плевать в принципе как вы обрабатываете данные.

                                      Кроме того, при написании SPA, вы как правило работаете с очень ограниченным множеством объектов, не на что там по сути процессорное время тратить.

                                      О как. Вы знаете я пожалуй на этом спор закончу. У нас с вами очень разные фронтенд. И стало быть разные требования к программистам.

                                        0
                                        Вас не смущает что вы в одном и том же комментарии жалуетесь на протекающие абстракции и утверждаете, что во фронтенде bigO не нужен?

                                        Ну, лично я это понял примерно так: "мы всё равно ни черта не знаем про bigO в алгоритмах внутри браузера, но видим, что чаще всего они оказываются медленнее любого нашего кода, а если вдруг это не так — профилировщик нам в помощь".

                                          0
                                          Примерно так. На самом деле вопрос шире. У меня вот перед глазами пример большого популярного сервиса, странички которого, могут запросто скушать гигабайт (одна) при смешной функциональности.
                                          0
                                          Вас не смущает что вы в одном и том же комментарии жалуетесь на протекающие абстракции и утверждаете, что во фронтенде bigO не нужен?

                                          Вы можете сколько угодно оптимизировать ваши алгоритмы, но если, например, вы через все слои протащите ссылку на здоровый объект/текст полученный их xhr, то память у вас будет течь всегда. Я такое вижу очень и очень часто.
                                          Кроме того, спрошу еще разок: у вас есть данные по скорости работы css селекторов? Правда интересно. Другое вопрос: вы в курсе, например, насколько медленная штука forEach?

                                          О как. Вы знаете я пожалуй на этом спор закончу. У нас с вами очень разные фронтенд. И стало быть разные требования к программистам.

                                          Действительно. Вы, уж извините, вероятно, из тех адептов, что кидают клиенту пол гига данных и весело их там размешивают? Тоже часто встречаю.
                                            0
                                            вы через все слои протащите ссылку на здоровый объект/текст полученный их xhr, то память у вас будет течь всегда.

                                            В чём проблема в больших объектах полученных через xhr? Со строками там есть сложности, известная проблема. Но что вас смущает в объектах? Не храните лишних ссылок и не будет у вас утечек памяти. Если будут — репортите баги в v8.


                                            Я кстати никсолько не отрицаю важности понимания работы сборщика мусора. Это снова алгоритмы. В некоторых задачах важно знать даже такие вещи как избегать stop-world (например держать пулы объектов). Про это были материалы.


                                            Вы, уж извините, вероятно, из тех адептов, что кидают клиенту пол гига данных и весело их там размешивают?

                                            Могу и так, если задача это подразумевает. Когда надо цельно работать с этим графом данных на стороне клиента. Стоит правда сразу уточнить что это в 99% случав или какой-нибудь редактор и/или закрытое приложение на заказ под конкретную контору и её сотрудников. Ныне web позволяет это решать. И если раньше сотни мегабайт грузили приложения на Delphi/C++/C#, то теперь их пережовывает и web. При условии что над этим работают не верстальщики.

                                              0
                                              В чём проблема в больших объектах полученных через xhr? Со строками там есть сложности, известная проблема. Но что вас смущает в объектах? Не храните лишних ссылок и не будет у вас утечек памяти. Если будут — репортите баги в v8.

                                              Меня — ничего. Но вот современный веб нам показывает что как с этим работать не знает почти никто. С текстом кстати примерно тоже самое, что и с объектами, но менее очевидное.
                                                0
                                                Но вот современный веб нам показывает что как с этим работать не знает почти никто

                                                Вероятнее всего, ни современный веб, ни сами разработчики этому виной не являются. Сам концепт разработки другой: разрабатывать продуманный и оптимизированный софт дорого, глючный и кривой, но полный "фич" — дешевле и выгоднее. А пользователи давно свыклись и с тормозами на пустом месте, и с мириадами багов. Бизнес конкурирует с другими бизнесами и играет по тем же правилам. В итоге если это не какой-нибудь очень критичный к багам и\или скорости софт, то скорость разработки сильно превалирует над качеством. Пока ты делаешь фичу хорошо она уже успевает устареть, конкуренты выпустили 3 других.


                                                Грустно это или нет, другой вопрос. Но сглаживают углы уже почти все. Деньги с неба не берутся.


                                                Это касается почти всех отраслей разработки ПО.

                                                  0
                                                  В итоге если это не какой-нибудь очень критичный к багам и\или скорости софт, то скорость разработки сильно превалирует над качеством. Пока ты делаешь фичу хорошо она уже успевает устареть, конкуренты выпустили 3 других

                                                  Чуднсно, и пока будет так, у меня всегда будет работа)

                                                  Вероятнее всего, ни современный веб, ни сами разработчики этому виной не являются

                                                  Являются. Потому что НИКТО не использует собственный софт.
                                                    0
                                                    Потому что НИКТО не использует собственный софт.

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

                                                      0
                                                      Можно написать хорошо и быстро. Просто ради этого нужно посадить разработчика пользоваться тем же яндекс.connect, за ту же кассу в маке, заставить его обувь пару часов попродавать и алкоголь.
                                      +1
                                      Но это не значит что не надо уметь это делать если потребуется.
                                      Вот недавно вспоминается один проект (там правда мобилки а не веб):
                                      есть сервис, у него есть клиенты, есть приложения на iOS и Android
                                      одна из задач:
                                      открывается экран, дергается REST API, приходит список телефонных номеров других пользователей сервиса. пользователь вводит частичный номер и надо показывать подпадающий под него список из контактов, но если это тоже пользователей — с особым значком, означающим что можно выполнить через сервиса определенную операцию с этим контактом. Разумеется этот экран должен летать всегда и везде, по крайней мерее быстрее чем пользователь вводит.

                                      Была наивная реализация но появились жалобы что на адресной книге где то в 300 записей ощущаются некоторые лаги.
                                      В наивной было много веселого вроде компиляции одного и того же регэкспа и потом поиска по этому регэкспу (а что — регэксп это ж дешево), в нескольких вложенных цикле и других милых особенностей. Причем писал вроде хорошо разбирающийся человек, решил что не надо преждевременно оптимизировать и надо решение в лоб(спросить нет возможности уже)?

                                      Пришлось разбираться и анализировать какие и как операции выполняются, и какие из них — где надо бы выполнять.
                                      Поиск получилось ускорить с 1 мс (на тестовом устройстве) на контакт до 0.02 мс + примерно 2 мс на подготовку, задача почти решена но начальство говорит что еще бы хоть раза в два быстрее на пользователях с кучей контактов в адресной книги, мол это VIP-пользователи и вообще не красиво, в итоге выяснилась небольшая особенность андроидного ContactProvider'а (и пришлось делать хитрить с кешем). Вот только без анализа алгоритмической сложности не получилось бы найти и решить главную проблему.

                                      (То что клиентское приложение (из-за данной фичи) технически знает телефоны большинства других пользователей сервиса… ну знает, да, но не такая уж проблема, вот так просто трафик почитать не получится, у конкурентов есть аналоги данной фичи).

                                        +1
                                        Была наивная реализация но появились жалобы что на адресной книге где то в 300 записей ощущаются некоторые лаги.

                                        в нескольких вложенных цикле

                                        Слабо представляю наивную реализацию в том виде, как вы ее описываете. Но увы и ах я с мобилками не работаю, хотя звучит интересно. Но в моем мире обычно вложенный цикл это либо крайне редкий и сложный случай, либо секира ждет писатели тех строк.

                                        Вот только без анализа алгоритмической сложности не получилось бы найти и решить главную проблему.

                                        Получилось бы, профилированием. Поймите меня правильно, все, кто так хорошо работает с UX — герои. В наше время — без преувеличений. Но для этого требуются знания, далеко выходящие за рамки оценки сложности алгоритмов. Мне лично оценка сложности последний раз потребовалась лет 9 назад, там был очень производительный серверный код, но по сути, это было баловство, поскольку с сетью и бд проводилась куда более тщательная работа. Можно вообще сказать, что про сложность алгоритма я не знаю ничего вообще, как и многие хорошие разработчики, но неоптимальный код вижу сразу, а если сомневаюсь — всегда проверю. И наконец: я пользуюсь своим продуктом, всегда, чего 95% программистов не делают вообще.

                                        То что клиентское приложение (из-за данной фичи) технически знает телефоны большинства других пользователей сервиса… ну знает, да, но не такая уж проблема, вот так просто трафик почитать не получится, у конкурентов есть аналоги данной фичи

                                        Почему не сделать наоборот? кинуть на сервак адресную книжку?

                                        ЗЫ то что получилось это здорово, вот у меня сейчас проблема: страничка подтягивает к себе 200-2000 строк, рисует быстро, ui летает, но сервак отдает данные примерно за 350мс. Записей в базе — миллиарды, структуру не поменять от слова совсем, кэширование не вариант (вопрос инвалидации в данном случае не решаем), печаль в общем лютая.
                                          0
                                          Но в моем мире обычно вложенный цикл это либо крайне редкий и сложный случай, либо секира ждет писатели тех строк.

                                          Человек без понимания основ легко пишет и тройные и какие-угодно другие вложенные циклы. И вообще строят n! на пустом месте. Принцип простой — "оно же работает". Делают последовательные запросы вместо параллельных, делают сотни запросов вместо одного. И многие другие грабли.


                                          Получилось бы, профилированием

                                          Очень велика вероятность, что когда профилирование UI проблемы выяснит где проблема — уже поздно. Поворотная точка бесповоротно позади. У приложения сломана сама архитектура и оно орудует данными не в том виде и не таким образом каким надо. Проблемы решались по мере их поступления без анализа предметной области. Человек решал задачу шаг за шагом не видя её в целом (как минимум кругозора\желания\навыков не хватило). В итоге под снос всё кроме favicon.ico.


                                          Профилирование это не панацея.

                                            0
                                            И вообще строят n! на пустом месте.

                                            Видел, знаю, проходил, для решения таких проблем (в том числе) есть код ревью.
                                            Вообще я вот смотрю на ваше n-факториал и с трудом понимаю о чем вы. Хотя очень много лет посвятил решению проблем быстродействия и оптимизации скорости работы интерфейса и с интерфейсом.

                                            Кроме всего прочего, поймите меня правильно, вот вы работаете с массивом, у вас варианты: for(;;), for(in), for(of), forEach(), Array.map(). И тут возникает моментик: разница в скорости работы между ними — 20 раз. Вероятно, можно даже выяснить почему, хотя не всегда. Оценка сложности алгоритма вам в данном случае не поможет никак.
                                            Ну и как вишенка на торте: Array.prototype методы могут работать некорректно с объектами среды исполнения ибо зависят от реализации HasProperty.

                                            оно же работает

                                            Если пользователь ощущает как оно работает, значит нихрена не работает.

                                            Делают последовательные запросы вместо параллельных, делают сотни запросов вместо одного.

                                            А вот тут, кстати, привет от ORM с дикими оверхедами. И никого это в современном мире не парит. Я уж молчу про @аннотации, где такая магия происходит, что какая либо оценка алгоритмов вообще теряет всякий смысл.

                                            Профилирование это не панацея.

                                            оверинжиниринг тоже
                                              0
                                              для решения таких проблем (в том числе) есть код ревью.

                                              Вы серьёзно предлагаете нанимать senior разработчика а потом изучать под микроскопом каждую строку кода? Code-review хоть и must have, но ни разу не silver bullet.


                                              оверинжиниринг тоже

                                              Про него я и не заикался. Сейчас мало кто на него способен. Уже лучше я остановлю коллегу от оверинжиниринга (да и себя порой надо), чем буду менторить каждый 1-ый "синьорский" шаг под микроскопом.


                                              Вы определитесь с тем, что вы хотите мне доказать. Я пока решительно не понимаю. Я ведь не Kwisatz Haderach :)

                                                +1
                                                Вы серьёзно предлагаете нанимать senior разработчика а потом изучать под микроскопом каждую строку кода? Code-review хоть и must have, но ни разу не silver bullet.

                                                Каждую строчку — нет. А общий принцип, именования и комментарии — да. Меня уже трясет от свойств/полей типа anal от «сеньеров» и сэтим можно только смириться.

                                                Вы определитесь с тем, что вы хотите мне доказать.

                                                Хочу доказать что оценка сложности алгоритмов не silver bullet и нафиг не уперлась. Поймите меня правильно, я ровно с той же проблемной постоянно сталкиваюсь, только сейчас мне нужен мидл. У меня волосы на голове шевелятся от ужаса, половину спрашивать неочем, 10-15 лет опыта в резюме а человеку вообще не очем рассказать. У всех заявлен опыт работы с SQL а простейший запрос с union/join написать не могут.
                                                И это при том, что когда я прихожу на собес, меня спрашиваю от уровня изоляций транзакций до алгоримтов работы кеша линуха.

                                                ЗЫ шустро вы отвечаете, пока дописывал уже и ответ О_О

                                                Kwisatz Haderach

                                                Зачет)
                                                  0
                                                  И это при том, что когда я прихожу на собес, меня спрашиваю от уровня изоляций транзакций до алгоримтов работы кеша линуха.

                                                  Меня в Германии пока ни разу не спрашивали ни про какие кеши линукса. Спрашивают про "расскажите о том, как вы решаете рабочие конфликты", "вы не согласны с коллегой, что вы будете делать", и всякую дурь про BEM. Нормальных вопросов почти не было. В лучшем случае я обсуждал с интервьювером какие-нибудь нюансы современных фреймворков и es-next.

                                                    0
                                                    BEM

                                                    Че это?
                                                    es-next

                                                    А это?)

                                                    Спрашивают про «расскажите о том, как вы решаете рабочие конфликты», «вы не согласны с коллегой, что вы будете делать»

                                                    Ну тоже неплохо на самом то деле. Хотя такие вопросы лиду больше.
                                                0
                                                Видел, знаю, проходил, для решения таких проблем (в том числе) есть код ревью.

                                                Код ревью — не панацея. Во время pull request review видна только часть кода. Чтобы на самом деле понять, не превратилось ли в нем O(n) в O(n²) необходимо очень долго и вдумчиво исследовать исходники.


                                                Если оригинальный разработчик не понимает, то в ревью запросто может пролететь, потому что настолько досконально изучать ревью требует почти столько же времени, сколько написать самому. Поэтому все патологические случаи отловить не удастся.

                                      +4
                                      У нас как-то был цирк с AWS. Кто-то взломал аккаунт клиента, и наплодил кучу топовых инстансов в нескольких регионах. Тупо случайно обнаружили это (никто не заглядывает ежедневно в консоль авс) — сменили пароли, и начали руками выпиливать. Но… Они начали появляться обратно! Минут 30 впятером сидели, под дикий мат руками терминейтили кучи инстансов по всем регионам, пока шестой искал причину. Оказалось что хакер оставил кучу заявок на серверы On-Demand, и они плодились автоматически. Клиент, к счастью, на деньги не попал)
                                        +3

                                        Один одногрупник как-то в году эдак 2013 запустил 20 самых больших инстансов AWS и не додумался их вырубить. Они проработали часов эдак 12.


                                        В итоге 500$ на его карте уплыли мигом, но вся боль была в том что у карты был открыт overdraft и парень ушел в минус на 4000$. Последний раз когда его видел — он сказал уже расчитался с ним.

                                      +2
                                      Когда-то давным-давно, в далекой Галактике… ушло часов 5 чтобы понять причину, почему ФТП клиент упорно не видит файлы на ФТП сервере, хотя они там есть! Их всего-то было три: abc.1с, def.1с и xyz.1c, так почему же эта Apache Commons FTPClient сволочь их не видит то?
                                      Кстати дело было в ночь с 30 на 31 декабря, так что это реальный ужастик был.
                                        +1
                                        А в чем дело было?
                                        (спрашиваю как человек далекий от Apache Commons FTPClient)
                                          +7
                                          Да фтп вожди то апачей, как раз оказались ни при делах… Хотя изначально на них грешили, так как буквально за неделю до этого обновили версию этой либы.
                                          «Но дело было не в бобине»
                                          … Что делает опытный прожженный временем и бухгалтерами, 1С-разработчик, получив четкое формализованное задание «создать и выложить 3 файла с указанными именами»? Он пишет код который генерит содержимое файлов и код который их выкладывает на удаленный ФТП. Он даже имя им дает такое же, как в задании, прям буква в букву латинские!
                                          А вот расширение файла… расширение файла он пишет с русской буквой «эс»…
                                          ну он же в 1эс код пишет? в 1С, а не в 1си
                                          логика железная надо заметить.
                                          Ну как обычно :)
                                            +2

                                            Ах, классика:) В первый раз не мог понять, почему не могу найти запись в базе, хотя копировал прямо из емайла. А потом понял, что русская А и английская A выглядят почти одинаково:)

                                              +1
                                              Блин, красиво :)
                                                0
                                                Чего красиво то? KeyRus вполне себе штатно вместо русской эр-маленькой выводил английскую пэ-маленькую.
                                                Так что «в Азии приучены к засаде» (С) уже давно.
                                                :-)))
                                                  0
                                                  Красиво то, что в имени файла с — латинская, а в расширении — русская.
                                                  Это насколько «красиво», что 1с-ников от праведного гнева, спасли тока наступившие новогодние каникулы :)
                                                    +1
                                                    Не штатно. Вам попался модифицированный под фидонет.
                                                      0
                                                      Эта засада ещё со времён Norton Commander 3.0 длится. Он не воспринимал в своём редакторе (по F4) русскую «эр». Часто прямо в бинарниках разных русификаторов с помощью тех же Norton Utilities (Disk Editor) исправляли «р» на «p».
                                                      Уж потом появился Norton Commander с исправленным этим багом.
                                              +1
                                              Заказчик сам виноват, порешило сообщество, потому что 50$ это копейки

                                              Сколько принято сейчас платить разработчикам? Потому что рейт $50/час превращается в сумму, заметно превышающую максимальную вилку зарплат, которую вижу вокруг себя.

                                                0
                                                Мне это тоже показалось странным. В штатах, конечно, зарплаты совсем другие, но даже там 50$ в час это неплохие деньги
                                                  0

                                                  Если для кого-то это копейки и он хочет код на порядки лучшего качества или исправить код как в приведенном примере, с удовольствием возьмусь за написание/исправление за указанные «копейки». Контакты есть в профиле.

                                                  +2

                                                  Так это наверное gross. А у нас социалку платит работодатель и вы её в бумагах не увидите. Их 50 в час, это что-то около 30 чистыми в час у нас, если наемным сотрудником.

                                                    +3
                                                    Да даже если гросс. при полном рабочем дне это около 8к долларов в месяц, 96к в год. Хотя для аутсорса, возможно, это и мало — когда выкупаются реальные часы работы, стоимость часа обычно выше чем у фултайм разработчиков.
                                                      0
                                                      Именно так. ~100-120к в месяц — нормальная зарплата мид-сениора на полный рабочий день, если в средней полосе США (не Калифорния и не Нью-Йорк). Контрактные расценки обычно куда выше. Если по недолгому контракту нанимают за $50 в час, то оттуда вычитается не только подоходный налог по прогрессивной ставке, но еще и социалка в размере 15.3%, так что на руки остается процентов 60-65, т.е. 30 долларов в час, плюс-минус. За эти деньги работать будут только джуны с соответствующим качеством. Адекватные специалисты по контракту начинаются от 100-150 в час, и кстати, далеко не только в IT — на тех же автосервисах работа механиков проводится из расчета 120 в час в среднем (данные по Техасу). Так что если ты сениор (не важно, разработчик, или админ), то брать 150 в час на контракте совершенно не странно и не зазорно.
                                                        0

                                                        Прям не верится. "Адекватные специалисты" от 16 килобаксов в месяц?
                                                        Если не ошибаюсь, в примере было что-то из Джанго. Я с ним сталкивался немного, ну… Не рокет сайенс. С Питоном (PyQt) работал плотно года три, (здесь даже осталась статья, по которой видно, как я наивно юзал кьютовские потоки в питоне, теперь смешно). Сейчас эмбеддед: Линукс, С, ядро, драйвера, юзерспейс. Изредка пишу для коллег гуевые/веб тулзы на Питоне. Как раз именно так изучил (поверхностно) Джанго и вообще ORM (понравилось, но привык иметь больший контроль над БД и писать все руками, оставляя доступ только через встраиваемые функции, догадываюсь, что это тоже возможно, но не дошел). Прям отдыхаю на таких вещах — как же все здесь проще. То задалбываешься без каких-либо доков искать, почему драйвер хост-контроллера не видит USB-устройство или пытаться понять, почему скорость работы связки samba/ntfs-3g ниже на 30%, чем у конкурентов, а то сидишь спокойно, читаешь доки и просто делаешь, что нужно.
                                                        Это я к чему… Моя зарплата даже не в 10 раз меньше.

                                                          0
                                                          «Адекватные специалисты» от 16 килобаксов в месяц?

                                                          В пересчете — да. Это если бы их нанимали на месяц на почасовой ставке… что если и происходит, то только в мегакорпорациях. Обычно же такие почасовые ставки характерны для сравнительно коротких проектов. Ну и чтобы совсем уточнить — 16 штук в месяц для разработчика-сениора в некоторых городах США — это не космос на постоянной основе. В том же Сан-Франциско это вообще скорее медиана, учитывая местные цены. Для какой-нибудь Оклахомы это скорее будет 8-10 в месяц сеньору, 5-6 джунам, но там и жизнь дешевле сильно. В среднем, на дом в ипотеку, пару машин (в кредит, если надо) и раз в год отпуск с семьей среднему айтишнику хватает, особенно если супруг/а работает.

                                                          Моя зарплата даже не в 10 раз меньше.

                                                          Это обидно. В этом году еще неделю будет работать DV visa program (она же «лотерея грин-карт»), попробуйте. Ну и параллельно учите язык и ищите места работы — руки тут нужны, деньги найдутся.
                                                            0

                                                            Английский подтянул до upper intermediate, продолжаю учить. В следующем году думаю попытаться в чешский Red Hat устроиться.

                                                        0
                                                        при полном рабочем дне это около 8к долларов в месяц, 96к в год

                                                        Делите часы сразу на два) При почасовке оплачивается только кодинг, а все остальные ваши активности связанные с работой(переговоры, поиск новых клиентов и тд) — за свой счет. Также не забудьте вычесть отпуск и больничные, которые при почасовке тоже за свой счет. Именно же набор кода занимает хорошо если половину от 8 часового дня
                                                      0

                                                      Только я сильно не уверен, что там не просто 50$ за разработку.

                                                      +4

                                                      «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 секунд отключило всю энергосистему Квебека"


                                                      https://ru.wikipedia.org/wiki/Операция_«К»

                                                        +2
                                                        Был обычный день, из тех что бегаешь с утра с высунутым языком и думаешь: «Ну что за день заполошный! Словно понедельник!», потом понимаешь, что да, сегодня понедельник и значит всё нормально, бежишь дальше.

                                                        Понадобилось создать временную учетную запись для проверяющих, разблокировал свою рабочую станцию, зашел через RDP на контроллер домена под администратором, открыл оснастку добавление пользователя в домен и тут!
                                                        Т-р-р-р-р. Телефон. «Придите помогите, у нас видео конференция с министерством не конференция, а нам отчитываться надо!». Поднимаюсь из за стола, иду к двери кабинета и понимаю, что оставил разблокированную рабочую станцию с запущенным RDP сеансом котором открыт с администраторским доступом к контроллеру домена.

                                                        В кино обычно в этом момент из под соседнего стола или с потолка, выбирается злобный хакер, занимает оставленное рабочее место и быстренько делает что-то там с администраторскими правами. Задерганный админ возвращается через пять минут когда хакера и след простыл.

                                                        И вот это понимание всей киношности и одновременно реальности ситуации, остановило меня. Вернулся, отключился от контроллера домена, заблокировал сеанс пользователя на локальном АРМ, вышел из кабинета закрыл дверь на замок. И подумал: «А вот хрен вам злобные хакеры!»

                                                        И да, подключится удаленно к системе с видео конференции нельзя. Только ножками, ножками.

                                                        Да, это не самый разрушительный случай, но думаю самый киношный и в тоже время реальный.

                                                        «В жизни, как в кино? Вроде, как в кино. Но не как в кино!»(С)Наум Олев и А.Балагин
                                                          +4
                                                          21 января
                                                          Эникей создал учетку audit c паролем 1234 для очередного бухгалтерского аудитора…
                                                          22 января
                                                          Учетка audit добавлена в групу бухгалтеров, тк аудитору нужно было сохранить какой-то отчет в общей папке бухгалтерии.
                                                          13 марта
                                                          На терминальном сервере, группа бухгалтерии добавлена в группу удаленных рабочих столов.
                                                          Терминальный сервер доступен из интернета на нестандартном порту.
                                                          15 мая
                                                          На терминальный сервер через rdp c китайского адреса заливают мешок майнеров, батников и powershell скриптов…
                                                          И ни один из них не удается запустить. Так как через групповые политики пользователям запрещено из профиля запускать все исполняемые файлы, кроме *.LNK
                                                          В тот раз пронесло…
                                                          +2
                                                          Прекрасным зимним днём, выполнял тестовый заказ и в процессе отошёл(или отвлекли) вернулся через час. Каково же было моё удивление, когда тестовый заказ через час оказался уже оплачен, хотя его никто не оплачивал. Немного подумав и сделав ещё пару тестовых, нашёл уязвимость которая позволяла бесплатно заказывать всю продукцию онлайн магазина. О баге в компании не знал никто и сколько она существовала(месяцев, лет???) никто не знает, но я в тот день приуныл знатно.
                                                            +2
                                                            Как то раз делал интернет магазин, где то сделал ошибку и одному клиенту каждые 5 мин в течении суток уходили смс о прибытии товара) Хорошо что одному, а не всем)
                                                              +3

                                                              Как-то раз пили похожую систему, только с email. 2 сервиса — первый находится в crm и отсылает api запрос, второй принимает его и шлет мыло/sms/api партнерам. Если сервис 2 (шлюз) не доступен то сервис 1 шлет запрос еще раз, после еслм не дошло откладывает сново шлет. Nginx шлюза обрубал запросы по timeout и сервис 1 постоянно слал одни и теже запросы на шлюз. В итоге 100000 одинаковых писем ушли партнерам и у одого из партнеров от этого сдох email сервер.

                                                              +4
                                                              Это было в далеком 2014 году — начало моей карьеры в IT. Очень внезапно и спонтанно устроился на интересный проект: внедрял софт Сбербанка в отделениях, путешествуя по городам и весям нашей необъятной. В задачи входило открыть и закрыть операционный день и помочь сотрудникам освоиться с новым продуктом.
                                                              Как вы можете догадаться, скорость выполнения операций сотрудниками была медленная, от этого скапливались большие очереди.
                                                              В одном далеком н-ском уезде 90-е будто бы и не кончались. В скопившемся потоке ожидающих людей сначала изредка, а затем с завидной регулярностью начал выказывать своё «Фи» мужчина, щегольски одетый в кожанную куртку, наголо стриженный и носивший внушительные ювелирные украшения. С каждым разом резкость высказываний становилась выше и выше.
                                                              Война войной, а обед по расписанию. Из двух операционистов остался один. Очередь доходит до нашего недовольного героя, и вот незадача: кассира разлогинивает из тонкого клиента. Ввод пароля: ошибка. Очистка кэша-куки — без толку. Может капслок? Нет, всё в порядке. Не заходит, и всё тут.
                                                              Объясняюсь с мужчиной:
                                                              — Вы знаете, сейчас у нас внедряется новая программа, возникли технические трудности, не зависящие от нас, извините нас, пожалуйста, но сейчас не получится принять Вас.
                                                              — Вот прямо в тот самый момент, когда очередь подошла моя?
                                                              — Да, мне очень жаль.
                                                              — Ну, а*****, б**!
                                                              Он удалялся к выходу, добавляя дальше свои эмоциональные оценки происходящему.
                                                              Стоило уйти ему за дверь, как нам удалось залогиниться и начать работу, принимая более лояльных клиентов.

                                                              Эпилог:
                                                              А говорят, что у ПО нет души…
                                                                +3
                                                                Из сисадминских баек) Лет 10 назад работал в банке, у нас был маленький отдел — 3 человека. Один раз звонят из бухгалтерии, просят что то сделать. У нас radmin был везде установлен, но проще самому сходить, пообщаться. Сходил, сделал, прихожу обратно, наши пацаны на полу лежат от смеха. Че вы ржете спрашиваю. Оказывается они по удаленке подключились к компу той бухгалтерши, чтоб посмотреть что я буду делать, а она в это время по аське общалась с коллегой. И вот они стали свидетелем такого разговора:

                                                                — Слушай, а через рот забеременеть можно?
                                                                — Ты че дура, нет конечно!

                                                                Финиш, мы все лежали еще минут 10.
                                                                  +6
                                                                  Был прекрасный день и мы тихонько кодили повышение почасовой ставки коллегам (сюрприз!).
                                                                  Расчётом ведал MsSQL, ибо ERP была с толстыми клиентами и логично было вынести большую часть бизнес-логики в БД.
                                                                  Разбираясь с функцией расчёта зарплат, оставшейся от внедренцев, которых почему-то выгнали на мороз не очень чистыми тряпками, задумался «А где же функция пересчёта начисления зп?» — работы почасовые, и их можно как добавить, так и убрать.
                                                                  Всё оказалось просто: а нигде. Первый раз посчитали, выплатили деньги сотрудникам — и баста. А то, что договор может ещё пару лет продляться и наполняться сотнями часов (или наоборот, часы работ могут быть порезаны на порядок), внедренцы не учли.
                                                                  Сообщаю восхитительную новость радостному от скорого сюрприза генеральному директору, радость улетучивается и у него.
                                                                  Быстренько пишу скрипт сверки — сколько должно быть выплачено, сколько выплачено де-факто и дельту между ними по сотрудникам — и тут уже становится очень грустно: у кого-то за несколько лет скопилось несколько миллионов, у кого-то — тоже миллионы, но переплаченные и что делать — не очень понятно.
                                                                  В итоге, пересчёт добавили на прод, долги простили, а невыплаченное выдали премиями в честь тёплых весенних дней или чего-то такого ( потому что объяснить, за что дают полтора млн разом, почему не дают другим и где денег взять — идея за гранью фантастики)
                                                                  PS А ещё внедренцы с теста оставили чудесную кнопку на проде со стандартным названием «удалить всё» (всё, что на данном экране после применения фильтров), но удалявшую действительно всё, кроме справочников прямо в БД с правами sa. И я её нажал, думая о стандартном эффекте. Бэкапы спасли, но те 4 часа разбора «куда делись договора, клиенты и работы?!» вспоминаются совсем без удовольствия.
                                                                    +3
                                                                    Пятница. Вечер. Конец рабочего дня. Я убиваю базу на продакшене. В предпаническом состоянии со сверхзвуковой скоростью чиню ее в течение получаса. Не помню, как мне это удалось, помню только, что так быстро я никогда не работал :-)

                                                                    P.S. про вечер пятницы уточнил, потому что есть же аксиома «если кто-то рано на работе, то необязательно он рано пришел — может он еще не уходил», а значит, есть и ее обратная сторона и конец рабочего дня в пятницу может быть и утром тоже.
                                                                      +1
                                                                      Есть такой ресурс ithappens.me, так вот на нем 13494 подобных историй. Жаль, правда, уже более 4-х лет не появлялось ничего нового.
                                                                        +4
                                                                        Да, и это страшно: кажется, 13495-я история случилась у них, и — фатально!
                                                                        +1
                                                                        sudo rm -rf /* 

                                                                        Так же не выдаст предупреждений. Как и наоборот
                                                                        rm -rf /
                                                                        от root выдаст предупреждение. (проверил на debian)
                                                                          +3
                                                                          Такая байка. Я не программист, а чуть продвинутый пользователь занимающийся дизайном. Был в гостях у отца (во времена студенчества), работал с его компьютера, подключая свой HDD со всеми файлами и установленной ОС. Однажды, при загрузке увидел надпись «Для бэкапа BIOS нажмите F8» (в точности воспроизведения надписи не уверен) ну я и нажал просто из любопытства. Комп перестал загружаться с диска. Затем я (почему я тогда так глупо себя вел? Зачем я снова наступил на эти грабли?) отключил свой диск и то же самое сделал с отцовским и получил два «винта» которые определялись как неразмеченные.

                                                                          Вот это был стресс! Ведь как мне казалось, я потерял все семейные файлы и устроил диверсию по отношению к отцу. Он не мог работать, заказы «повисли». В итоге собравшись с мыслями и успокоившись. Нашел чужой старый компьютер чтобы с него выйти в сеть и как-то взаимодействовать с дисками. Мы жили в далёком городе, где даже не было на то время магазина с компьютерным железом, а про линукс и загрузочные CD и флешки я даже не знал. Стал читать форумы ИТ тематики с сообщениями людей, столкнувшимися с той же бедой. Оказалось, БИОС бэкапил себя на какой-то из секторов диска (деталей не помню) и убивал то ли MBR то ли FAT. И там кто-то оставил утилиту, исправляющую последствия такого кривого бэкапа. Все удалось починить, файлы оказались в сохранности. Сейчас, оцениваю насколько были глупы эти действия и как мне повезло, что утилита оказалась работающей корректно.
                                                                            +1
                                                                            Затем я отключил свой диск и то же самое сделал с отцовским
                                                                            Это великолепно! :D
                                                                              0
                                                                              Я сейчас не могу объяснить себе причину такой тупости, действовал в стрессе, видимо, мне показалось что я пропустил какой-то пункт меню и стоит попробовать еще раз. Не помню :(
                                                                            +4
                                                                            Свежая страшилка:
                                                                            Был солнечный день, я сидел в своём сисадминском кабинете, читал айтишные новости, изучал новые технологии и думал о вечном — как усложнить жизнь юзерам, как улучшить безопасность своей инфраструктуры. В этот момент ход моих размышлений был прерван звонком от юзера с невнятным описанием возникшего недопонимания компьютера и юзера. Так как день был прекрасный, я решил размяться и зайти к юзеру лично. Как оказалось, недопонимание было небольшим и решилось быстро, но вовремя разговора с юзером я узнал одну шокирующую вещь, о которой я только читал… он хранил важные документы в корзине!!!
                                                                            Страшилка моей молодости:
                                                                            Давным-давно, в одном местном советско-российском ВЦ (вычислительный центр), когда балом правили XT (кто-нибудь практиковал парковку головок MFM HDD дисков на них? Я — да!), но уже встречались и i386, я работал БД-программистом и автоматизировал работу бухгалтерий предприятий (да, тогда ещё не пахло 1С от слова совсем), санаториев и прочих спецавтохозяйств. У меня был отдельный кабинет с несколькими XT и одной XT286 с кнопочкой Turbo :). В тот момент я разрабатывал, дорабатывал и поддерживал программу учёта путевых листов для САХ (хозяйство по вывозу мусора), данные в программу вводили женщины-операторы машинного зала (была такая профессия) EC, а мужики, которые обслуживали эту штуку приходили ко мне и гоняли в Диггера. В один прекрасный момент, когда первичный ввод был завершён и всё было замечательно, я сел за компьютер с базой путевых листов (не за своим же это делать?) и решил поразбираться с утилитами от моего любимого программиста — Питера Нортона. В результате изучения утилит был получен огромный опыт в области уничтожения данных, форматирования диска и двухмесячного сидения за компьютером с вводом данных с нуля.
                                                                              +2
                                                                              Причем эти 286 с «кнопочкой турбо» обязательно стояли в помещении без окон, и за толстой железной дверью. Потому что 1 такая машина с EGA монитором, тогда стоила дороже, чем 3х летнее зубило «с длинным крылом». :)
                                                                                +1
                                                                                В моём кабинете были окна :), но решётка на окнах была из железных прутьев. А дверь, как и во всех помещениях с техникой была деревянная, но оббитая металлическими листами и на усиленном каркасе. Вот про вторую железно-решётчатую дверь не помню, зато было две двери на этаж — решётка и металлическая дверь.
                                                                                  0
                                                                                  Эх… Тёплые были времена… ламповые ©
                                                                              +2
                                                                              Ковырял я некий датасет в виде базочки SQLite с двумя столбцами: ид и некий большой не особо структурированный JSON, который содержал в себе ссылки на айдишники других строк. И надо было отладить функцию, которая ходила по этим ссылкам. Так что копипастил джейсон в какой-то онлайн-редактор, вручную находил там поле со ссылкой и дергал его запросом к БД. Результаты наглухо не совпадали с результатом питоньей функции, которая делала ровно то же самое.

                                                                              Заголовок спойлера
                                                                              Продолжение во второй серии
                                                                                +3
                                                                                Как оказалось, айдишник не помещался в джаваскриптовкий Number длиной 56 бит, и втихаря округлялся
                                                                                  0
                                                                                  Любой, кто что-то больше int передаёт как число в JSON — достоин гильотинирования.
                                                                                +1
                                                                                Однажды один разработчик Oracle работал в одном большом банке.
                                                                                Каждый вечер делался бэкпа БД и после на нем в ручную запускали задание на обезличивание(в окошке IDE).
                                                                                И вот разработчик ошибается окошком, запускает скрипт на боевой БД, смотрит в монитор и повторяет «Горшочек, не вари»

                                                                                История закончилась хорошо, спасибо администраторам, которые не только делают бэкапы, но и проверяют что БД из них разворачивается.
                                                                                  +1
                                                                                  Помнится зеленым джуном дописывал какие-то модули для гостиничной системы и начальник попросил под вечер проверить, что интерфейс с другой нашей системой внесения денег работает корректно после каких-то правок. Я торопился, кинул пару платежей в первой системе, увидел, что они вроде пролетели во второй без ошибок, сказал, что все ок и свалил на свиданку. Апдейт отправили клиенту и оказалось, что программист напутал со знаками и при внесении средств в первой системе в нашей счет ДЕБЕТОВАЛСЯ. Счастье, что там это быстро заметили, откатили апдейт, деньги клиенту вернули. А мне тогда вкатили по первое число.
                                                                                    +5
                                                                                    Далекие 90-е. Я работаю в некой конторе приходящим сисадмином всея конторы решая все возникающие проблемы. Одной из проблем оказалось, что в контору могут наведаться некие вежливые (а может и не очень) люди и поинтересоваться бухгалтерскими базами данных. В связи с чем требовалось решение которое могло бы быстро удалить весь компромат и которое было бы по силам для освоения тамошним бухженщинам. В результате была сооружена дьявольская программа, которая после запуска давала пять секунд на размышление сотруднику возомнившему себя антидемиургом и затем уничтожала ВСЁ если не успеть нажать ESC.
                                                                                    Я позвал финдиректора, и стал ей объяснять как пользоваться программой. Финдиректор радостно кивает. Воодушевленный, я с радостью запускаю программу, на экране начинается обратный отсчет,
                                                                                    5...4...3…
                                                                                    я пафосно произношу фразу, что сейчас всё будет уничтожено если не нажать ESC.
                                                                                    Лихо клацаю по эскейпу и… отсчет продолжается 2...1...0…
                                                                                    Волосы у меня встают дыбом. Я понимаю, что всем базам данных пришел северный пушистый зверь. А сердце выпрыгивает и оказывается где-то в районе пяток. Но… ничего не происходит. Бухгалтерши также спокойно стучат по клавишам и обсуждают недоступные мне материи — что-то о проводках, счетах и этих… контрагентах.
                                                                                    Моё сердце впрыгивает обратно в грудную клетку. С ленцой я выдаю (выдавливаю) фразу — «Ну… вот. Примерно так. Теперь надо на боевой режим поставить и готово». Финдиректор кивает и уходит. Я открываю текст, нахожу элементарный баг, исправляю и иду на кухню успокаивать нервы чаем.
                                                                                      +1
                                                                                      sudo rm –fr /
                                                                                      Не вижу ничего страшного в этой команде. Это же просто удаление всех французских файлов, а они обычно не нужны.
                                                                                        0
                                                                                        Без sudo в начале и золотого ключика --no-preserve-root патч товарища Бармина не сработает.
                                                                                        0
                                                                                        Подводим итоги нашего конкурса. Победил Frenology его история набрала 15 плюсов, он получает толстовку от Levelorda, второе место занял webdevium с 8 баллами, ему отправляется годовой запас носков в подарок. Подробности получения призов написали в личку победителей. Всем спасибо за участие в конкурсе.

                                                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                        Самое читаемое