>Масло маслянное? В ошибках программирования, наверное тоже, виноват только программист.
Ну модно (и я был таким раньше, и иногда бываю сейчас) обвинять кого угодно, только не себя. Не те программисты — вот посыл статьи.
>Автор предыдущей статьи был абсолютно прав в том, что для каждой работы есть некий стереотип человека, который будет эту самую работу лучше всего выполнять. Грубо говоря, человеку с лидерскими и безнес-скилами работать на «конвеере сайтов» будет ни разу не интересно. Ошибкой автора было перенести свой стереотип на остальные проекты (дескать всем нужны только забитые ботаники.)
Ну и я высказал свое мнение на этот счет, насчет идеального. Цитирую: «Идеальный программист не пишет плохой код, не срывает сроков и не существует.»
>Так что — да, каждый программист уникален. Что, однако, не мешает вам выбирать из программистов тех, кто лучше всего справится с Вашими задачами, и не уйдёт раньше срока.
спасибо за замечание.
откорректировал, добавил, что это только мое мнение, плюс смягчил формулировку.
это сугубо мой опыт анализа ухода нескольких десятков программистов, и необязательно верный. но удивительным образом работающий даже в несхожих с моей управленческой практикой ситуациях. вообще, брать на себя ответственность и думать, как избежать чего-то негативного в будущем, даже если это было случайностью — хороший момент для собственного развития.
ну там уже до нас было кеширование в виде файлов. изначально структура была слишком крутая и универсальная, и все варианты показа баннеров обсчитывались в ПХП ООП :) мы упростили структуру еще к тому же, провели рефакторинг.
Мы переписывали движок баннерокрутилки, полученный от коллег. Наш хороший разработчик переписал все на ООП PHP. Мы пытались что-то оптимизировать, но оно даже под абешкой не взлетало (50 запросов в секунду должно плевать с одного сервака, получали 99% fails).
В конце-концов в результате оптимизаций на профайлинге стала очевидность важности правильной архитектуры. Ниже этапы оптимизации и вывод.
1. Сначала убрали лишнее ООП. Помогло, не сильно
2. Увидели, что крутые ООП-оболочки над БД сильно тормозят. Переписали на голом PDO
3. Но и голое PDO стало тормозить. 90% времени съедает, 400 мс.
4. По моему предложению перенесли логику в БД. Так как там была операция в цикле и ряд запросов.
5. Сначала хранимки в БД написали " в лоб" — циклы и тд. Помогло, не сильно — 50% не работало под нагрузкой.
6. С участием нашего DBA, выдающего специалиста, переделали циклы в хранимке на язык реляционной БД — в один запрос, убрали временные таблицы из логики, и так далее.
7. В итоге менее 10% фейлов, и система стала жить на нагрузке.
Вывод — правильная архитектура решает, правильный выбор инструментов для размещения логики того или иного вида.
А вовсе не тупые оптимизации, вроде давайте заменим двойные кавычки на одинарные, или там заменим кусок сишного кода на ассемблер. А умные, которые неразрывно связаны с проникновением в предметную область задачи и понимания условий, в которых приложение будет работать.
Для того, чтобы люди ассоциировали какие-то НЕХ с реальностью, часто нужно их наделять эмоциональными поступками, и нередко — антропологичностью.
Почитайте у Каганова на эту тему. Супер-повесть про кротовые норы отсасывает, а повесть про живую машину вдруг становится популярной. Хотя в первой ДОСТОВЕРНОСТИ может быть миллион. А способности ВЫЗЫВАТЬ ЭМОЦИИ у зрителя/читателя — минимум.
Такой стиль вашего коммента бесит. Это вы издеваетесь?
Значит, давайте по-порядку.
Во-первых, я в той статьей дополнил каждый пункт личным примером. Вы плохо смотрите.
Во-вторых, аяксовое сохранение по CTRL+Enter мне было не сразу понятно. Оно скидывает в черновики, хотя логичнее было бы публиковать (именно эта кнопка основная).
В-третьих, где запрещение этого правилами?
В-четвертых, я стараюсь писать содержательные статьи, и о разном. Сам не люблю воду.
Десяток, сайты визитки, средненькие и интернет магазины. Надоеоло потому, что это конвеер и рутина. Щас уже знаю, что либо нало было стандартизировать, автоматизировать и продавать в десять раз больше, либо паспозиционироваться и добиться успешых продаж за цену в десять раз больше. А тогда мыслил только как программист и интепеса не видел
Убрать в черновики может?
Ну модно (и я был таким раньше, и иногда бываю сейчас) обвинять кого угодно, только не себя. Не те программисты — вот посыл статьи.
>Автор предыдущей статьи был абсолютно прав в том, что для каждой работы есть некий стереотип человека, который будет эту самую работу лучше всего выполнять. Грубо говоря, человеку с лидерскими и безнес-скилами работать на «конвеере сайтов» будет ни разу не интересно. Ошибкой автора было перенести свой стереотип на остальные проекты (дескать всем нужны только забитые ботаники.)
Ну и я высказал свое мнение на этот счет, насчет идеального. Цитирую: «Идеальный программист не пишет плохой код, не срывает сроков и не существует.»
>Так что — да, каждый программист уникален. Что, однако, не мешает вам выбирать из программистов тех, кто лучше всего справится с Вашими задачами, и не уйдёт раньше срока.
Согласен
жалко вообще.
он же вроде не матерился, просто написал свой взгляд
Просто в эмоциях написал статью, с которой я не совсем согласен. Никто же не запрещает обмен мнениями?
откорректировал, добавил, что это только мое мнение, плюс смягчил формулировку.
это сугубо мой опыт анализа ухода нескольких десятков программистов, и необязательно верный. но удивительным образом работающий даже в несхожих с моей управленческой практикой ситуациях. вообще, брать на себя ответственность и думать, как избежать чего-то негативного в будущем, даже если это было случайностью — хороший момент для собственного развития.
Напишите эту логику на стороне БД, и работать иногда будет раз в 10-100 быстрее. :)
Иногда скорость важнее красоты
Мы переписывали движок баннерокрутилки, полученный от коллег. Наш хороший разработчик переписал все на ООП PHP. Мы пытались что-то оптимизировать, но оно даже под абешкой не взлетало (50 запросов в секунду должно плевать с одного сервака, получали 99% fails).
В конце-концов в результате оптимизаций на профайлинге стала очевидность важности правильной архитектуры. Ниже этапы оптимизации и вывод.
1. Сначала убрали лишнее ООП. Помогло, не сильно
2. Увидели, что крутые ООП-оболочки над БД сильно тормозят. Переписали на голом PDO
3. Но и голое PDO стало тормозить. 90% времени съедает, 400 мс.
4. По моему предложению перенесли логику в БД. Так как там была операция в цикле и ряд запросов.
5. Сначала хранимки в БД написали " в лоб" — циклы и тд. Помогло, не сильно — 50% не работало под нагрузкой.
6. С участием нашего DBA, выдающего специалиста, переделали циклы в хранимке на язык реляционной БД — в один запрос, убрали временные таблицы из логики, и так далее.
7. В итоге менее 10% фейлов, и система стала жить на нагрузке.
Вывод — правильная архитектура решает, правильный выбор инструментов для размещения логики того или иного вида.
А вовсе не тупые оптимизации, вроде давайте заменим двойные кавычки на одинарные, или там заменим кусок сишного кода на ассемблер. А умные, которые неразрывно связаны с проникновением в предметную область задачи и понимания условий, в которых приложение будет работать.
Почитайте у Каганова на эту тему. Супер-повесть про кротовые норы отсасывает, а повесть про живую машину вдруг становится популярной. Хотя в первой ДОСТОВЕРНОСТИ может быть миллион. А способности ВЫЗЫВАТЬ ЭМОЦИИ у зрителя/читателя — минимум.
Поэтому парень все сделал верно.
Будущее не просто рядом, а уже наступает.
Значит, давайте по-порядку.
Во-первых, я в той статьей дополнил каждый пункт личным примером. Вы плохо смотрите.
Во-вторых, аяксовое сохранение по CTRL+Enter мне было не сразу понятно. Оно скидывает в черновики, хотя логичнее было бы публиковать (именно эта кнопка основная).
В-третьих, где запрещение этого правилами?
В-четвертых, я стараюсь писать содержательные статьи, и о разном. Сам не люблю воду.
Много крутых проектов, лидируем на рынке.
я занимаюсь внутренней автоматизацией, расти еще очень много
чтобы потом его на другие города масштабировать (был успешный пример из другого региона).
в общем, там было непросто :)
стараюсь в тему и чтобы они были достаточно полезны.
данная есть изложение моего опыта