Читать «Bash IT Happens Истории ## 12101 – 12200» онлайн - страница 20

Bash.org.ru IT

Кого-то задолбали провайдеры, навязывающие свои услуги, а я этим людям даже немного завидую.

Дело в том, что мой дом находится в недавно построенном коттеджном посёлке. Конечно, тут работает и 3G, и 4G, и мобильники — но всё-таки это не сравнить с быстрым интернетом по оптике или витой паре.

Уважаемые провайдеры! Может быть, вы перестанете задалбывать жителей многоэтажек, тратя миллионы на колл-центры, а вложитесь немного в прокладку «последней мили» в подобные посёлки, которых тут вокруг великое множество? До ближайшего города — прямая видимость и какие-то коммуникации. Наверняка можно либо договориться с энергетиками и кинуть оптику, либо повесить приличные радиомодемы.

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

#12142: Лучший антивирус — мухобойка

16:00 26.04.2014, IT happens

Здесь очень много историй про хороших и плохих бухгалтеров, монтажников, программистов, админов, юзеров и начальников. А мне достался главный инженер… Если честно, после каждой планёрки хочется взять тетрадку и записать его перлы и безумные идеи. И этот случай явно займёт достойное место.

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

#12143: Иногда они всё-таки лажают

12:00 27.04.2014, IT happens

Я предпочитаю начинать решение проблем в программах с вопроса «а где я ошибся?», так как мой опыт показывает, что в большинстве случаев ошибка именно моя. Но иногда…

Случилось мне заниматься разработкой программного комплекса, один из компонентов которого вертелся в MySQL. При этом всю логику взаимодействия с БД я по возможности перенёс в хранимые процедуры внутри БД. Возникла необходимость оптимизации одной из хранимых процедур, которая при попытке всунуть в БД жалкие 10К строк зависала на два часа. Нужно было найти узкое место этой процедуры. Поиск «бутылочного горлышка» довольно прост: засекаем, сколько миллисекунд уходит на каждый шаг, смотрим, где проблема…

Проблема нашлась гораздо раньше: СУБД категорически отказалась выдавать нам информацию о миллисекундах. Даже под пытками. И даже с Гуглом. При этом информации в интернете было на удивление мало; у меня даже закралось страшное подозрение, которое со временем окрепло, что народ свои базы вообще не оптимизирует. В конце концов Гугл раскололся и выдал ссылку на точное описание проблемы… в багрепорте разработчиков. Читая добросовестное описание проблемы, я испытывал невероятное умиление: моя ситуация один в один! Сейчас дочитаю до ответа разрабов, пойму, где я дурак, всё сделаю как надо… Ответ разрабов был как ушат холодной воды: «Да. Такая проблема существует. MySQL не умеет возвращать миллисекунды».