Pull to refresh
4
0
Валерий Крутов @accentenal

Пользователь

Send message
не много и не мало прошло с момента данного поста.
случайно забрёл в свои записи на Хабре, чего не делал уже давно, и вот не могу удержаться от вопроса.
Как в итоге сложилось-то? Что выбрали? К чему пришли? 5 лет прошло как никак. Интересно всё-таки сделать ретроспективу :)
нет варианта «меня укусил другой программист» =)
ты б дал ссылочку на презенташку свою с докладом или на текстовый его вариант, если таки написал уже +)
а я знаю тайное знание где за 120 стригут не практиканты )))

но да не в этом дело.
Дело в том, что у программистов не развито практически чувство старшего мастера.
Мы все сами с усами. И сами рвёмся в бой с пылким взором!
В итоге и получается то, что получается.

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

Но есть одно НО.
Есть задачи в которых требования меняются со временем. Увеличивается нагрузка посещаемостью, требования по оформлению и т.д. и т.п.
И чертовски обидно когда приходят и говорят «что же ты зараза сделал всё так плохо, что вот N месяцев спустя у нас ничего не работает». Упуская момент что N месяцев оно всё работало, а сейчас изменились бизнесс требования.
Архитекторов, например, не заставляют перестроить здание в краткие сроки через пару лет, существенно изменяя изначальные требования.

Текст написан с одной стороны, и да, нужно быть профессионалом и не увлекаться, когда речь идёт о реальном проекте, реальных деньгах и ограниченном времени.
Однако, к ИТ специалистам, как к футболистам и политикам, есть такое отношение со стороны народа, что народ всегда знает как сделать лучше. Что фигнёй мы занимаемся и сложного-то ничего в работе нет.
Вот это заблуждение так же надо искоренять из работодателей, заказчиков и менеджеров. Тогда будут и повышения квалификации и нормальное отношение программистов к выполнению своих обязанностей, без чрезмерного увлечения технологиями.
У нас же в ИТ порой каждый менеджер «знает как лучше» и «знает как быстрее», о чём обязательно уведомляет программиста, рассказывает ему своё мнение, заставляет выслушать, отъедая тем самым рабочее время, а потом ещё за это же время пеняет, что мол не уложился, дурью маялся.
а что делать? врачами знаете ли тоже сразу не становятся. и рано или поздно те же интерны начинают ставить эксперименты на живых пациентах, точнее тренироваться.
Так же как и парикмахеры и прочие специальности.
на дорогой сердцу Хабре
всё таки Хабр он мужского рода, не? =)
хочется надеяться на представительные данные )
а вы пишете о 30-40 секундах на загрузку? так это проблема канала а не браузеров )
imho, результаты не могут быть взяты на веру, так как у вас слишком много случайных факторов (медленный канал со скачками скорости, нагрузка на сервер и разница в скорости выдачи им результатов, другие процессы на вашей машине с браузером)
и к тому же
" Прогонял каждый сайт по одному разу "
Бенчмарк подразумевает многократные повторения и сбор статистической информации.

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

В любом случае, пользователь не готов видеть чистый не отрендереный html, который дёргается и извивается по мере загрузки стилей и скриптов, пользователя это напугает и он начнёт звонить администратору с криками «Алярма! Алярма! Вирусы!»
ну как один из вариантов…
1-ая кружка/стопка
2-ая кружка/стопка

9-ая кружка/стопка
0 — ну и уже в ноль к этому моменту и спать )))
в таком случае к своему дню рождения в этом году отнеситесь особенно и/или с осторожностью.
Кто его знает к чему это )))
уже упоминалось на Хабре подзамочная запись в блоге «Юмор на Хабрахабре». Думаю, что если заджоинитесь туда, то увидите её.
ХабраДно хабрасообщества )
Лишать доступа даже в персональный блог. Это уже статус ХабраБомж будет.
поделитесь задачкой в личку, пожалуйста… жуть как любопытно помучать мозг…
Исследование бред.
Даже если это поп-ап и при нажатии на ОК чтото зловредное произойдёт, неужели там в тексте будет написано чтото вроде
«А вы (0xff6729cd) не возражаете if мы вам %username% винт форматнём rightnow потому что он can not be 'read'?»

А исходя из выводов, которые делают авторы исследования, можно сделать вывод, что авторы исследования линуксоиды холиварщики ))))))))))
Кстати, справедливости ради следует добавить, что чем меньше данных надо за раз залить, то разница соответственно будет чувствоваться меньше.
И, конечно же, зависит от того, что является приемлемым временем выполнения задачи заливки.
импортировались записи блоками разных размеров, 1000, 5000, 10000, 25000 и 50000, выходило, что чем меньше размер пакета данных, тем больше времени затрачивается на заливку данных.

Пробовалось как на InnoDB так и на MyISAM. На последнем при отключенной перестройке индексов скорость была выше, норазница сохранялась.

Точных цифр не скажу, так как было это больше полугода назад, но переход на генерацию sql-файла и его заливку вместо прямой передачи генерируемых данных в БД уменьшил время заливки данных в БД на порядок, а переход с sql-файла на CSV и LOAD DATA INFILE ещё на 30%.

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

но даже если просто логически подойти к этому вопросу, то получается 10 000 запросов, а это 10 000 разборов запроса, 10 000 — 1 ожиданий для каждого следующего запроса пока выполнится предыдущий, не говоря уже о затратах на межпроцессное взаимодействие при передаче данных.
лучше запихивать в файл, чтобы не тормозить при генерации следующего пакета данных пока будет передаваться сделанный =)

Information

Rating
Does not participate
Location
Nordrhein-Westfalen, Германия
Date of birth
Registered
Activity