Здравствуйте, Sheridan, Вы писали:
S>Вопрос несколько в другой плоскости я поднимаю: а почему бы и нет? S>Судя по этим веткам — потому что современные реалии требуют не качественный и быстрый код, а как можно более быстрый и дешевый процесс разработки.
ты считаешь, что качественный это быстрый, а это совсем, вот совсем не так.
Современные реалии требуют качественный код, но определение качества совсем другое.
Здравствуйте, genre, Вы писали:
S>>Мне пришло в голову взять подходящий инструмент и запилить более шустрый проект. G>А кому нынче нужна эта шустрость? Ну срендерится твой html не за 10мс а за 5. и?
Да я ж уже сказал — никому. Продолжайте наблюдения.
Здравствуйте, genre, Вы писали:
S>>Вопрос несколько в другой плоскости я поднимаю: а почему бы и нет? S>>Судя по этим веткам — потому что современные реалии требуют не качественный и быстрый код, а как можно более быстрый и дешевый процесс разработки.
G>ты считаешь, что качественный это быстрый, а это совсем, вот совсем не так.
Тебе "и" ни о чем не говорит?
G>Современные реалии требуют качественный код, но определение качества совсем другое.
Угу, я уже понял. Современное качество уже совсем другое.
Здравствуйте, Sheridan, Вы писали:
S>Гм. Давай посмотрим. S>пэхапэ + шаблоны: получение запроса, парсинг кода, интерпритация, запрос данных в бд, парсинг шаблонов, сборка страницы из "шаблон+данные", передача клиенту. S>с++ + инлайн-хтмл: получение запроса, запрос данных в бд, сборка страницы исходя из данных, передача клиенту. S>Из этого я вижу укорачивание процесса запрос-результат на три шага, от 7 к 4. Причем уходят именно ресурсоёмкие шаги: парсинг, интерпритация.
Ну вообще-то парсинг и интерпретация это чуть ли не самые дешевые шаги на фоне запроса в базу и доставки клиенту (а еще есть браузер в котором легко может получится, что твои супероптимизированные мс фигня на фоне секунд отрисовки).
ты кстати когда упрешься в базу еще вспомнишь нехорошим словом запросы в базу вперемежку с html в коде. фиг с ним с остальным, но sql хоть вынеси в отдельный класс/модуль.
Здравствуйте, Хон Гиль Дон, Вы писали:
ХГД>Не добавляются, а заменяется — зачем в скриптовых языках в стек гадить, если в них поголовно eval имеется
Ну, например в C# eval'а нет
ХГД>Ну давай теперь сравним это высказывание с оригинальным утверждением "Да, жаль, что все уязвимые приложения были написаны невменяемыми программистами "
Так это с моей стороны был сарказм в адрес твоего утверждения о вменяемых разработчиках.
KV>>Чисто статистически, проблемы с некорректным юникодом более актуальны для нативных языков и древних версий скриптовых (потому что их интерпретаторы/компиляторы потянули за собой проблемы нативного языка, на котором были разработаны). ХГД>Кто и на какой выборке сравнивал?
Я же не спрашиваю, путем опроса скольких хакеров ты пришел к выводу о том, что "чисто статистически — ломать типичное десктопное приложение, подсовывая некорректный utf, мало кому надо" (с) Из числа проанализированных нами нескольких сотен коммерческих приложений в 2010-2011, 2012 и 2013 годах и из числа стендов с опенсорсными веб-приложениями (около 4 десятков, php/java/c#), на которых мы гоняем наш продукт — ни одно не было подвержено атакам, связанным с эксплуатацией недостаточной обработки кодировок. Для меня этого более чем достаточно, чтобы считать нетипичными подобные ошибки для веб-среды.
KV>>Я могу придумать сценарий, при котором приложение на управляемом языке будет подвержено каким-либо атакам из-за недостаточной обработки кодировок, но на практике таких сценариев ни я, ни мои коллеги не встречали ХГД>Ога, а для нативных приложений, можно подумать, встречали, а не чисто теоретически придумали
Здравствуйте, genre, Вы писали:
G>Ну вообще-то парсинг и интерпретация это чуть ли не самые дешевые шаги на фоне запроса в базу и доставки клиенту (а еще есть браузер в котором легко может получится, что твои супероптимизированные мс фигня на фоне секунд отрисовки).
Наличие более дорогих шагов не должно быть стимулом написания менее производительного кода.
G>ты кстати когда упрешься в базу еще вспомнишь нехорошим словом запросы в базу вперемежку с html в коде. фиг с ним с остальным, но sql хоть вынеси в отдельный класс/модуль.
И так в отдельном классе. Наружу только запуск исполнения запроса и доступ к данным.
DFDB_R coworkers = DFDB_Q("task_coworkers", DF_SQL_TEXT(
select
/* 0*/ members.id,
/* 1*/ members.name,
/* 2*/ divisions.id,
/* 3*/ divisions.short_name
from task_coworkers
left join members on members.id=task_coworkers.coworker_member_id
left join divisions on divisions.id=members.division_id
where
task_coworkers.task_id=$1),
(taskID));
if(coworkers.size())
{
int coworkerID;
DFDB_QLOOP(coworkers, coworker)
{
coworkerID = coworker[0].as<int>();
HTML
(
<!++
<div class='performer'>
<a href='/members/show/<v++ coworkerID ++v>'><v++ coworker[1].as<std::string>() ++v></a>
(<a href='/divisions/show/<v++ coworker[2].as<std::string>() ++v>'><v++ coworker[3].as<std::string>() ++v></a>)
++!>
);
if(editable)
{
HTML
(<!++
<value_edit_dialog++ [<v++ coworkerID ++v>] [<v++ taskID ++v>] [TaskCoworkerRemove] [Удаление исполнителя] [close-round]>
<input type='hidden' id='task_coworker_rm_id_<v++ taskID ++v>' value='<v++ coworker[0].as<std::string>() ++v>'/>
<++value_edit_dialog>
++!>);
}
HTML(<!++ </div> ++!>);
}
}
Здравствуйте, Sheridan, Вы писали:
P>>Понимаешь, какая штука... Времена, когда процессорное время ценилось выше рабочего времени специалиста, давно и безвозвратно ушли. Доугими словами, ни один вменяемый менеджер проекта не даст 2 недели на выпуск версии из-за одной неправильно прописанной буквы.
S>Слава богам, у меня такого менеджера нет и я могу пилить то что считаю нужным.
И расходовать бюджет своей конторы непонятно куда. Или у тебя резиновый бюджет?
Я как-то наблюдал случай. Один деятель получил задание сделать некую учетную программу. Начал он ее на Сях. Делал окого года. Все у него то какие-то сортировки не работали, то в интерфейсе какие-то артефакты вылезали. Когда он узнал, что к нему должны прийти за результатом, он за несколько дней сдедал эту работу на FoxPro. Разумеется, там было полно багов и глюков, зато о всяких там сортировках думать было не надо. Потом подсчитали: нормально эту работу на Фоксе можно было сделать за пару месяцев. Парня, разумеется, выгнали пинком под зад.
S>пэхапэ + шаблоны: получение запроса, парсинг кода, интерпритация, запрос данных в бд, парсинг шаблонов, сборка страницы из "шаблон+данные", передача клиенту.
Я где-то говорил про ПХП? Есть языки с jit-ом, в которых интерпретация выполняется один раз при запуске приложения. Шаблоны тоже совершенно не нужно парсить каждый раз. При первом запуске, а дальше все зависит от приложения и от количества имеющейся памяти.
S>Из этого я вижу укорачивание процесса запрос-результат на три шага, от 7 к 4. Причем уходят именно ресурсоёмкие шаги: парсинг, интерпритация.
Так и в моем случае они уходят. Пусть не сразу. Зато автоматически.
В этом месте жду рассказа о том, что мне памяти не хватит в какой-то момент. Так тебе ее точно так же не хватит. Я однажды видел, как программа у одного молодого парня перестала помещаться в памяти из-за избытка в ней текстовых строк. Это, правда, было давненько.
S>Да и вообще, оправдывать тормозной код тем, что все равно "много" времени уйдет на доставку результата как минимум неверно, ибо результат надо доставить в любом случае.
Вот объясни, зачем вылизывать код до состояния, в котором программа 90% времени будет висеть в ожидании?
Кстати, сейчас я получаю ответы от некоторого сервера со слишком большой задержкой. Бутылочное горлышко — именно сеть.
S>Все ушли в с\с++, как более удобный инструмент и при этом практически настолько же шустрый.
Ты не угадал. Хотя бы потому, что Фортран в своей области гораздо удобнее C++.
Здравствуйте, Privalov, Вы писали:
S>>Слава богам, у меня такого менеджера нет и я могу пилить то что считаю нужным. P>И расходовать бюджет своей конторы непонятно куда. Или у тебя резиновый бюджет?
Начнем с того, что бюджета нет вообще
P>Я как-то наблюдал случай. Один деятель получил задание сделать некую учетную программу. Начал он ее на Сях. Делал окого года. Все у него то какие-то сортировки не работали, то в интерфейсе какие-то артефакты вылезали. Когда он узнал, что к нему должны прийти за результатом, он за несколько дней сдедал эту работу на FoxPro. Разумеется, там было полно багов и глюков, зато о всяких там сортировках думать было не надо. Потом подсчитали: нормально эту работу на Фоксе можно было сделать за пару месяцев. Парня, разумеется, выгнали пинком под зад.
Виноват конечно же, с++.
S>>пэхапэ + шаблоны: получение запроса, парсинг кода, интерпритация, запрос данных в бд, парсинг шаблонов, сборка страницы из "шаблон+данные", передача клиенту. P>Я где-то говорил про ПХП? Есть языки с jit-ом, в которых интерпретация выполняется один раз при запуске приложения. Шаблоны тоже совершенно не нужно парсить каждый раз. При первом запуске, а дальше все зависит от приложения и от количества имеющейся памяти. S>>Из этого я вижу укорачивание процесса запрос-результат на три шага, от 7 к 4. Причем уходят именно ресурсоёмкие шаги: парсинг, интерпритация. P>Так и в моем случае они уходят. Пусть не сразу. Зато автоматически.
А у меня сразу
P>В этом месте жду рассказа о том, что мне памяти не хватит в какой-то момент. Так тебе ее точно так же не хватит. Я однажды видел, как программа у одного молодого парня перестала помещаться в памяти из-за избытка в ней текстовых строк. Это, правда, было давненько.
Не буду, так как все сразу скажут что память стоит копейки
S>>Да и вообще, оправдывать тормозной код тем, что все равно "много" времени уйдет на доставку результата как минимум неверно, ибо результат надо доставить в любом случае. P>Вот объясни, зачем вылизывать код до состояния, в котором программа 90% времени будет висеть в ожидании?
Ну если обращений планируется раз в сутки от одного клиента, то согласен.
P>Кстати, сейчас я получаю ответы от некоторого сервера со слишком большой задержкой. Бутылочное горлышко — именно сеть.
А если бы ты писал например на перле или вообще на бэйсике — тот сервер бы тебе быстрее данные отдавал?
S>>Все ушли в с\с++, как более удобный инструмент и при этом практически настолько же шустрый. P>Ты не угадал. Хотя бы потому, что Фортран в своей области гораздо удобнее C++.
Тем не менее с++ победил и до сих пор жив.
Здравствуйте, Privalov, Вы писали:
P>Везет же некоторым. У них есть возможности упорно работать над никому не нужными задачами. Мне вот на нужные не всегда времени хватает.
Я еще время на ingress и eve online нахожу
А задача нужная. Но не так чтобы "должно быть готово вчера", а "между делом сделай".
Здравствуйте, Sheridan, Вы писали:
S>Вопрос несколько в другой плоскости я поднимаю: а почему бы и нет?
Если сам ставишь себе требования и сроки, а "время — не ресурс" — запросто.
S>Судя по этим веткам — потому что современные реалии требуют не качественный и быстрый код, а как можно более быстрый и дешевый процесс разработки.
Современные реалии требуют код, отвечающий требованиям, по которым его писали. И производительность там далеко не всегда на первом месте. На правах примера из собственного опыта: пользователи анализаторов защищенности исходных кодов, давно и прочно готовы к тому, чтобы скан их проектов занимал на порядок больше часов, но при этом давал хотя бы на десяток процентов меньшее количество false-positive'ов обоих родов. Просто потому, что поставить скан на ночь и за следующий день разгрести сотню фолзов легче, чем полчить результаты за полчаса, а потом угробить всю неделю на разгребвание руками тысячи ложных срабатываний.
Быстрый код никому не интересен, пока он не сформулирован в виде нефукнционального требования в виде измеряемой величины _и_ пока не реализованы _в срок_ хотя бы основные функциональные требования.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Современные реалии требуют код, отвечающий требованиям, по которым его писали. И производительность там далеко не всегда на первом месте. На правах примера из собственного опыта: пользователи анализаторов защищенности исходных кодов, давно и прочно готовы к тому, чтобы скан их проектов занимал на порядок больше часов, но при этом давал хотя бы на десяток процентов меньшее количество false-positive'ов обоих родов. Просто потому, что поставить скан на ночь займет меньше времени и за день разгрести сотню фолзов проще, чем угробить всю неделю на разгребвание руками тысячи ложных срабатываний.
Ну не сравнивай усложнение алгоритма поиска в угоду результату не обращая внимание на время его работы с выбором языка и архитектуры в угоду более быстрой разработки.
Иными словами — у тебя задача найти угрозы. И ты их ищешь, небось даже не на перле написано.
А разговор идет о реализации одной и той же задачи разными методами. Один из них быстрый в работе, другой — удобный для разработчиков и менеджеров.
KV>Быстрый код никому не интересен, пока он не сформулирован в виде нефукнционального требования в виде измеряемой величины _и_ пока не реализованы _в срок_ хотя бы основные функциональные требования.
Вот тут согласен. Сначала реализация, потом оптимизация. Редко когда понимаешь что именно можно прооптимизировать без уже рабочего кода.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Именно так. Есть конечный ряд угроз, актуальных для веб-приложений, написанных на скриптовых и управляемых языках. При разработке веб-приложения на языках со слабой типизацией и/или поддержкой адресной арифметики и/или возможностью ручного выделения памяти, к этому ряду добавляется еще несколько угроз, связанных с повреждениями стека, кучи, переполнениями численных типов и прочей низкоуровневой радостью.
А в управляемых языках есть, например, unsafe, вызов сторонних динамических библиотек и общая склонность к type erasure а-ля System.Object или dynamic, а в скриптовых — eval'ы с include'ами, не говоря уже об динамической типизации.
Так что ряды хоть и пересекаются, но один не включает другой.
Но, как мне видится, в данном случае основная угроза исходит вовсе не от каких-то особенностей самого языка, а от непопулярности такого решения и, соответственно, меньшей пользовательской базы.
S>Наличие более дорогих шагов не должно быть стимулом написания менее производительного кода.
Ты б вот вместо того, чтобы упорствовать прислушался к тому, что тебе тут чуть ли не хором говорят.
Фразу про преждевременную оптимизацию произнесли еще в прошлом веке.
Пойми ты, качество кода определяется не его скоростью, а требованиями к коду. От них надо отталкиватся, а не от своего идеализма.
G>>ты кстати когда упрешься в базу еще вспомнишь нехорошим словом запросы в базу вперемежку с html в коде. фиг с ним с остальным, но sql хоть вынеси в отдельный класс/модуль. S>И так в отдельном классе. Наружу только запуск исполнения запроса и доступ к данным. S>
Здравствуйте, Sheridan, Вы писали:
S>Начнем с того, что бюджета нет вообще
Т. е. ты работаешь бесплатно? И твой отдел технику бесплатно получает? И инфраструктуру поддерживать бесплатно получается? Про софт я просто молчу.
P>>Я как-то наблюдал случай.
S>Виноват конечно же, с++.
В известном смысле. У того разработчика не было необходимой инфраструктуры на C++ для разработки такого приложения, и он начал делать ее самостоятельно. В результате туда ушел весь бюджет проекта, а перень остался без работы.
Ты в своем проекте, по крайней мере, не думаешь про рисование окон и доступ к БД.
P>>Так и в моем случае они уходят. Пусть не сразу. Зато автоматически. S>А у меня сразу
Но вручную. Зачем тогда компьютеры, если ты делаешь за них их работу?
P>>В этом месте жду рассказа о том, что мне памяти не хватит в какой-то момент.
S>Не буду, так как все сразу скажут что память стоит копейки
P>>Вот объясни, зачем вылизывать код до состояния, в котором программа 90% времени будет висеть в ожидании? S>Ну если обращений планируется раз в сутки от одного клиента, то согласен.
Гораздо больше одного раза в сутки.
Кроме того, гораздо дешевле поднять производительность системы, просто установив рядом с рабочим сервером, который перестает справляться, пары-тройки таких же серверов. Не надо тиакты считать. Железо все равно намного дешевое того софта, который на нем бежит.
P>>Кстати, сейчас я получаю ответы от некоторого сервера со слишком большой задержкой. Бутылочное горлышко — именно сеть. S>А если бы ты писал например на перле или вообще на бэйсике — тот сервер бы тебе быстрее данные отдавал?
Он жив, но Фортран непобедим. Во всяком случае написать переходник С — Фортран мне в свое время оказалось намного дешевле, чем переписывать отлаженный Фортрановский код полностью на Сях.
Здравствуйте, genre, Вы писали:
S>>Наличие более дорогих шагов не должно быть стимулом написания менее производительного кода.
G>Ты б вот вместо того, чтобы упорствовать прислушался к тому, что тебе тут чуть ли не хором говорят. G>Фразу про преждевременную оптимизацию произнесли еще в прошлом веке.
Я тут тоже рядом писал что сначала рабочий код, потом его оптимизация.
G>Пойми ты, качество кода определяется не его скоростью, а требованиями к коду. От них надо отталкиватся, а не от своего идеализма.
Так уж сложилось что требования себе выставляю я сам.
S>>
Здравствуйте, Sheridan, Вы писали:
S>А разговор идет о реализации одной и той же задачи разными методами. Один из них быстрый в работе, другой — удобный для разработчиков и менеджеров.
Понимаешь какое дело. До тех пор пока ты не померял ты не можешь даже быть уверен, что твой способ быстрее чем какой-то другой.
Здравствуйте, kochetkov.vladimir, Вы писали:
ХГД>>Не добавляются, а заменяется — зачем в скриптовых языках в стек гадить, если в них поголовно eval имеется
KV>Ну, например в C# eval'а нет
Ну, если очень надо, то он там есть.
ХГД>>Ну давай теперь сравним это высказывание с оригинальным утверждением "Да, жаль, что все уязвимые приложения были написаны невменяемыми программистами "
KV>Так это с моей стороны был сарказм в адрес твоего утверждения о вменяемых разработчиках.
Я бы сказал чуть по другому — голословный выпад
KV>>>Чисто статистически, проблемы с некорректным юникодом более актуальны для нативных языков и древних версий скриптовых (потому что их интерпретаторы/компиляторы потянули за собой проблемы нативного языка, на котором были разработаны). ХГД>>Кто и на какой выборке сравнивал?
KV>Я же не спрашиваю, путем опроса скольких хакеров ты пришел к выводу о том, что "чисто статистически — ломать типичное десктопное приложение, подсовывая некорректный utf, мало кому надо"
Я не слышал ни об одном случае такого взлома. Все, что припоминается — это веб, древние юникодные атаки на IIS и т.п. Поскольку данной темой я худо-бедно интересуюсь — значит, данный способ как минимум не популярен.
KV> (с) Из числа проанализированных нами нескольких сотен коммерческих приложений в 2010-2011, 2012 и 2013 годах и из числа стендов с опенсорсными веб-приложениями (около 4 десятков, php/java/c#), на которых мы гоняем наш продукт — ни одно не было подвержено атакам, связанным с эксплуатацией недостаточной обработки кодировок. Для меня этого более чем достаточно, чтобы считать нетипичными подобные ошибки для веб-среды.
Ну то есть тебе неизвестно ни об одном случае взлома нативных приложений через неверный UTF-8, но ты делаешь вывод "проблемы с некорректным юникодом более актуальны для нативных языков". Отлично, чо.
KV>>>Я могу придумать сценарий, при котором приложение на управляемом языке будет подвержено каким-либо атакам из-за недостаточной обработки кодировок, но на практике таких сценариев ни я, ни мои коллеги не встречали ХГД>>Ога, а для нативных приложений, можно подумать, встречали, а не чисто теоретически придумали
KV>Я не встречал. Но это настолько известная для нативных приложений проблема, что ей в свое время и выступления на правильных конференциях посвящали (https://www.blackhat.com/presentations/win-usa-04/bh-win-04-fx.pdf), и отдельное место в классификациях отвели (https://www.owasp.org/index.php/Buffer_Overflows#Unicode_Overflow) и, конечно же,
