Comments 48
Вы все его материалы собираетесь копипастить на хабр со своего блога? http://step2step.highload.ru/blog/about-frameworks.html
Лучше бы сделали удобный доступ к статьям не из рассылки а напрямую с главной страницы http://step2step.highload.ru/ или сделали бы это со страницы http://step2step.highload.ru/blog/ которой не существует.
В общем, не спамьте одним и тем-же. Кому надо и так найдут, а спам бесит.
Лучше бы сделали удобный доступ к статьям не из рассылки а напрямую с главной страницы http://step2step.highload.ru/ или сделали бы это со страницы http://step2step.highload.ru/blog/ которой не существует.
В общем, не спамьте одним и тем-же. Кому надо и так найдут, а спам бесит.
Вообще да, думал самые лучшие статьи перепечатать. Для того, чтобы искать, надо знать половину ответа, как минимум — что искать. В рассылке они, по большому счёту, недоступны — если ты подписан — получил, не подписан — никогда даже не узнал о том, что не получил.
Здесь же статьи открыты, логика доступа другая.
Блог step2step.highload.ru/blog/ публично не доступен, вы один из немногих, кто получает рассылку highload.guide.
Судя по статистике её получает примерно 0.4% от пользователей Хабра.
Даже если мы его сделаем публичным, то кто знает вообще про этот сайт? И как его найти? Кому придёт в голову искать информацию на сайте платного вебинара, который умрёт через месяц?
Этак можно утрировать — те, кто захотят, и видео найдут (оно бесплатное на vimeo.com), или те, кто хотел — и на конференции были и слушали доклад.
В целом мы думаем наоборот — перенести сюда, на Хабр, первую очередь распечаток, а уже затем публиковать их в рассылке.
Здесь же статьи открыты, логика доступа другая.
Блог step2step.highload.ru/blog/ публично не доступен, вы один из немногих, кто получает рассылку highload.guide.
Судя по статистике её получает примерно 0.4% от пользователей Хабра.
Даже если мы его сделаем публичным, то кто знает вообще про этот сайт? И как его найти? Кому придёт в голову искать информацию на сайте платного вебинара, который умрёт через месяц?
Этак можно утрировать — те, кто захотят, и видео найдут (оно бесплатное на vimeo.com), или те, кто хотел — и на конференции были и слушали доклад.
В целом мы думаем наоборот — перенести сюда, на Хабр, первую очередь распечаток, а уже затем публиковать их в рассылке.
В этом и дело. Миграция «закрытый вебинар который умрёт» -> «Хабр» кривая.
Если бы по человечески рассказали о том что дескать так и так, прошло столько-то времени и появилось столько-то статей и про них никто ничего не знает… и мы вот дескать решили выложить это всё на хабр и вот вам список со ссылками на все материалы, а так же краткая аннотация, прикреплённое видео и так далее… а следующие материалы публиковать одновременно и там и там или только тут или как-то ещё.
А так складывается впечатление что вы из этого автора пытаетесь все соки выжать, подавая то с одним соусом то с другим. И ещё вам бы не делать умирающие сайты. А то глупо и впечатление портит.
Если бы по человечески рассказали о том что дескать так и так, прошло столько-то времени и появилось столько-то статей и про них никто ничего не знает… и мы вот дескать решили выложить это всё на хабр и вот вам список со ссылками на все материалы, а так же краткая аннотация, прикреплённое видео и так далее… а следующие материалы публиковать одновременно и там и там или только тут или как-то ещё.
А так складывается впечатление что вы из этого автора пытаетесь все соки выжать, подавая то с одним соусом то с другим. И ещё вам бы не делать умирающие сайты. А то глупо и впечатление портит.
Я не понял Вас :)
Эта статья — расшифровка одного из докладов наших конференций. К вебинару это всё имеет очень опосредованное отношение, вебинар пройдёт, его лендинг закроем, а статья останется. Разве это плохо?
У нас таких расшифровок много, они опубликованы на highload.guide, который не собирается умирать.
Но классных докладов, которых мы хотим расшифровать и рассказать о них — ещё больше! Мы их собираемся расшифровывать, обрабатывать и выкладывать на Хабре. Плохая схема?
Эта статья — расшифровка одного из докладов наших конференций. К вебинару это всё имеет очень опосредованное отношение, вебинар пройдёт, его лендинг закроем, а статья останется. Разве это плохо?
У нас таких расшифровок много, они опубликованы на highload.guide, который не собирается умирать.
Но классных докладов, которых мы хотим расшифровать и рассказать о них — ещё больше! Мы их собираемся расшифровывать, обрабатывать и выкладывать на Хабре. Плохая схема?
Не скажу что этот доклад прямо такой классный… если бы не общая тематика ваших конференций то как статью его надо бы заминусовать как бесполезный по большому счёту.
Доклад не в «разработку», а в «менеджмент» стоит отправить, так как о разработке тут собственно ни слова, одни критерии выбора, впечатления и прочее присущее к менеджерам которые принимают решения. Аля «а что лучше, Yii или Symphony… давайте составим табличку...» или «А где нам взять столько программистов под конкретный фреймворк… а давайте наймём вот этих...».
Этот доклад может и полезен на специальных днях для тех кому нужно, но это не разработка и совсем не техническая статья, даже для сильного доклада по управлению не подходит. Эта одна из причин почему я придрался к перепечатки материалов.
Этот доклад может и полезен на специальных днях для тех кому нужно, но это не разработка и совсем не техническая статья, даже для сильного доклада по управлению не подходит. Эта одна из причин почему я придрался к перепечатки материалов.
По результатам опроса (19 человек ответило) этот доклад набрал 4.67 баллов и 5, так что позвольте с Вами не согласиться. В оценке интересности мы ориентируемся на участников.
Ориентируетесь на участников того мероприятия где был доклад? Ну ок… Пойду от сюда туда что-ли… что бы мнение имело значение. Хотя нет, я ведь не формат под то мероприятие. Значит… всё сложно:) Пишите конечно, доклады какими бы они не были хороши, только этот так себе, только и всего. Исключительно собственное мнение как и у некоторых других людей.
Я к тому, что нет такой миграции. Статьи сами по себе.
то есть в сухом остатке — надо подумать прежде, чем думать поздно — бесспорно — не жить по принципу — сарочка была умная
Это должно быть тут:
http://blog.kpitv.net/article/frameworks-1/
:^)
http://blog.kpitv.net/article/frameworks-1/
:^)
Пожалуй, ссылка на эту ветку комментов тоже не помешает.
http://www.phpthewrongway.com/#always-use-a-framework
Даже Расмус Лердорф (отец-основатель PHP) об этом говорит.
Даже Расмус Лердорф (отец-основатель PHP) об этом говорит.
Это никак не меняет наличие простой и банальной ошибки в вашем коде на продакшене. Которая к тому же светит файловую структуру сервера. Это хорошо показывает, к чему могут привести ваши советы.
Я просто продолжил обсуждение.
Конечно, не меняет. Ошибка есть ошибка. Я даже благодарен, что ее нашли :)
>светит файловую структуру сервера
Это страшно?
Светятся только фатал ерроры.
Чтобы вдруг чего пользователь мог скинуть нормальный текст ошибки.
Возможно стоит навесить обработчик ошибок, чтобы скрывать пути, но влом.
Если бы фатал_эррора не было, я бы не пофиксил баг, потому что не предполагал бы, что кто-то захочет подписаться на комменты. :)
Почему была ошибка?
Потому что функционал подписки на комменты был реализован через фичефлаг, а сам класс-сущность, 3 строчки, не было добавлено. Функционал подписки используется на 100500 моих сайтов.
Фичефлаг включил, 3 строчки добавить забыл.
Вы усомнились в моем авторитете из-за этой ошибки?
Так их куча в том же PHP и его фреймворках. :)
П.С.
Тот сайт для лулзов больше. :)
Конечно, не меняет. Ошибка есть ошибка. Я даже благодарен, что ее нашли :)
>светит файловую структуру сервера
Это страшно?
Светятся только фатал ерроры.
Чтобы вдруг чего пользователь мог скинуть нормальный текст ошибки.
Возможно стоит навесить обработчик ошибок, чтобы скрывать пути, но влом.
Если бы фатал_эррора не было, я бы не пофиксил баг, потому что не предполагал бы, что кто-то захочет подписаться на комменты. :)
Почему была ошибка?
Потому что функционал подписки на комменты был реализован через фичефлаг, а сам класс-сущность, 3 строчки, не было добавлено. Функционал подписки используется на 100500 моих сайтов.
Фичефлаг включил, 3 строчки добавить забыл.
Вы усомнились в моем авторитете из-за этой ошибки?
Так их куча в том же PHP и его фреймворках. :)
П.С.
Тот сайт для лулзов больше. :)
у Yii вход прям чуть ли не в разы быстрее, например, чем в Symfony войти
Мне кажется, что в масштабных проектах важнее не скорость входа, а возможности фреймворка, доступные из коробки.
вам нужно уже сейчас взять и бежать-копать.
Иначе можно столько «накопать», что «въезд» в ваш legacy код будет в разы медленнее, чем в самый сложный, но общедоступный фреймворк.
Прочел название, думал будет что-то интересное про фреймворки, а тут какая-то вода…
>Например, что сделали с той же Yii на PHP. Они версию 1 сделали не совсем совместимой с версией 2. Отличия не принципиальные, но тем не менее, взять и просто обновить фреймворк с версии 1 до версии 2, чтобы поиметь все плюсы версии 2, фиг получится.
>А, например, если вы берете какой-нибудь Symfony и программируете без деприкейтед методов, которые заранее были объявлены,
Ну то есть вы программировали на Symfony 1 без депрекейт методов, а потом бац и обновились до симфони 2?
>А, например, если вы берете какой-нибудь Symfony и программируете без деприкейтед методов, которые заранее были объявлены,
Ну то есть вы программировали на Symfony 1 без депрекейт методов, а потом бац и обновились до симфони 2?
Опять этот няшка на Хабре…
так можно и не начать никогда проект.
Нужно сделать прототип проекта на нескольких разных платформах
тогда можно будет провести оценку.
Если спросить опытного разработчика — он выберет на основе своего опыта.
А его опыт возможно основывался на проектах другого плана.
А реально брать и делать на том что самое популярное на текущий момент, а лет через 10 переделывать полностью.
Так с любыми проектами в ИТ и ничего тут не поделаешь
Нужно сделать прототип проекта на нескольких разных платформах
тогда можно будет провести оценку.
Если спросить опытного разработчика — он выберет на основе своего опыта.
А его опыт возможно основывался на проектах другого плана.
А реально брать и делать на том что самое популярное на текущий момент, а лет через 10 переделывать полностью.
Так с любыми проектами в ИТ и ничего тут не поделаешь
Статью очень трудно читать. Такое оформление (слайдами с огромными буквами) подходит для презентации, когда слайды служат для дополнения лекции. В статье они только сбивают с толку.
UFO just landed and posted this here
После прочтения складывается ощущение, что веб-разработчики живут в аду.
Почему же?
Из-за проблемы выбора, которая актуальна всё время. Нельзя просто совершить один раз какой-то фундаментальный выбор и дальше спокойно работать. А ведь десижн мейкинг, как известно, — это самая сложная работа. Когда мозг её выполняет, он работает на пределе.
Ну так рядовым разработчикам этим и не надо заниматься. Например у нас, симфони = стандарт и всё, точка. Но я достаточно часто смотрю разные другие инструменты и даже другие ЯП, но пока альтернатив я не вижу.
В разработке не для веба, скажем, на С++ даже смотреть никуда не надо. Ты либо используешь чистый С++ только с STL, либо используешь ещё и boost. И так будет ещё многие годы. Возможно, всегда…
Но это же скучно.
За 15 лет работы мне ещё ни разу не было скучно. Особенно с boost'ом :)
Думаю, скука возникает тогда, когда задача слишком проста. Это никак не зависит от используемых инструментов.
Думаю, скука возникает тогда, когда задача слишком проста. Это никак не зависит от используемых инструментов.
Ну сложных задач много, но ведь интересно когда появляются новые инструменты, возможности и т.д.
Я конечно сильно далеко от ++, изучал их в школе и в универе win api, ну и всякую мелочь писал.
Я конечно сильно далеко от ++, изучал их в школе и в универе win api, ну и всякую мелочь писал.
Когда появляются именно новые возможности, позволяющие решать такие задачи, которые раньше было решать трудно, тогда да… это интересно. Но такие инструменты появляются крайне редко. В основном все новинки — это вариации одного и того же с чуть-чуть разным набором фич. Типа, как на смену обычному молотку приходит молоток с эргономичной рукояткой, сменными насадками под разные виды гвоздей и приятным звуковым сигналом во время удара. Суть же работы с переменой инструмента не меняется.
Так и есть. Все, я побежал писать GUI-приложения, 3D-игры и системные утилиты на stl и boost.
Спасибо, капитан!
Ждем статью про вред глобальных переменных и правила структурного программирования.
P.S.
«Скрывает детали реализации» в минусы — это сильно!
Ждем статью про вред глобальных переменных и правила структурного программирования.
P.S.
«Скрывает детали реализации» в минусы — это сильно!
Пожалуйста:) Рад, что понравилось. Про вред глобальных переменных статей много, а переменных при этом меньше не становится. Про структуру программ тоже все знают, но код говорит про обратное. Про фреймворки рассказывали немало, а проблем при этом меньше не стало.
Про детали: когда вы упрётесь в проблему, что тормозит не тот код, который вы писали, а то, что под ним — тогда вы почувствуете этот минус.
Про детали: когда вы упрётесь в проблему, что тормозит не тот код, который вы писали, а то, что под ним — тогда вы почувствуете этот минус.
Кого-нибудь еще бесит, что на слайдах в последних пунктах списков стоят точки с запятой, вместо точек? :)
Sign up to leave a comment.
О фреймворках