По-моему, тут одни Васины проблемы:
1. Он явно считает себя самым умным.
2. Он говорит очевидные вещи, вроде «что любая оценка проекта есть величина статистическая и имеет свой доверительный интервал». А когда ему отвечают «и что?» он считает, что «его не услышали». А потом вклинит: «а я же говорил!»
3. Остальные работали 60 часов и значит это был их выбор. Возможно, работа идет в стартапе, или за нее платят так, что и 60 часов можно поработать. Если Вася недоволен, ему стоит искать новое место работы, а не жаловаться.
4. И главное, если у Васи есть рациональные мысли (тут их не видно), то либо он действительно работает среди идиотов либо не умеет их доносить. Опять таки, проблемы только у него.
MS Word при помещении курсора левее текста (на левое поле документа), меняет его наклон чтобы было удобно выделять строки справа от курсора. Забавно, но большинство пользователей этого не могут вспомнить и воспринимают как само собой разумеющееся.
Можно клонировать текущую задачу в другом проекте и автоматически связывать ее при этом с помощью скрипта.
Скрипт запускается в postfunction в каком-то шаге workflow с помощью ScriptRuner
Использовал подобную схему, и даже более развитую. Например, когда тестировщик отказывает задачу, задача должна автоматом вернуться именно на того разработчика, который ей занимался.
Но этот подход изменяет концепцию жиры. Потом возникают сложности:
1. Понять, кто делал задачу (только через историю)
2. Собрать статистку по разработчикам.
3. Поддерживать такое решение, особенно функции выбора, КАКОМУ тестировщику отдать эту работу, если он не один.
Мое мнение: для описанной задачи нужно использовать несколько проектов жиры. Например, отдельно для разработки и отдельно для тестирования. При этом можно автоматом создавать задачи в другом проекте и связывать их с исходной.
Или заводить отдельные поля тестировщик, аналитик и т.д., для каждой роли и прописывать пользователей в них.
Если нет событий или другого аналога, то это печально и тут действительно могут быть проблемы. Но события — есть.
Два update в батче сделает, понятно, ORM.
В ORM связь будет заданна на событии обработки изменения объекта какого-то класса. Соответственно, «забыть» после этого может только ORM. Но это из того же класса, что MSSQL «забудет» выполнить триггер.
Какой аспект? Требования ACID выполняет СУБД, ORM ее использует. Соответсвено, изменения денормализованных данных будут происходить в рамках одной транзакции и их целостность гарантирует СУБД.
Или есть мнение, что если код копирования данных написан в триггере, то это более надежно, чем два update в батче?
Ок, подолью огня. Я — системный архитектор нескольких информационных систем.
Считаю, для промышленного написания бизнес-логики удобно использовать статически типизированные, объектноориентированные языки, на которые есть хорошие инструменты:
* unit тестирования
* статического анализа и анализ метрик кода
* отладки
Java, Python, C# — хороший выбор.
T-SQL — в этом смысле плох. Про PL/SQL не знаю, есть ли в нем указанные инструменты и действительно ли он ООП или же как PHP.
Также замечу, что описанные плюсы ХП по сравнению с ORM в большинстве ошибочны. Сравню с .C# и DataObject.Net, т.к. пользуюсь ими.
* Скорость
Значимое отличие в скорости будет проявляться только за счет:
1. Константных задержек передачи по сети и материализации.
2. Использования редких средств SQL, не поддерживаемых большинством ORM, например такие как оконные функции.
Первая ситуация значима для разовых или очень быстрых запросов до нескольких мс, которых, как правило, не много.
Вторая — специфична, и в большинстве запросов бизнес приложений не проявят себя.
Ну и есть еще дискуссия по поводу качества запросов ORM. Я, например, занимался анализом запросов от DataObject и могу сказать что их качество скорости выполнения очень высоко, как бы при этом не выглядел пугающе внешний вид.
* Сокрытие структуры данных
LOL. Как раз, когда структура в модели классов, то происходит сокрытие способа хранения, и не придется изменять приложение, например, при смене способа организации наследования Single/Class/Concrete Table Inheritance.
При этом, при действительной необходимости изменения МОДЕЛИ, например, в C#, 99% работы за тебя сделает Resharper и статическая типизация.
* Гибкое управление правами доступа
Опять мимо. В слое доступа к данным можно организовать сколь угодно сложную логику ограничения доступа и она будет прозрачна для кода бизнес-логики.
* Меньшая вероятность SQL injection
ORM защищает от SQL инъекций лучше, т.к. делает это централизованно в LINQ провайдере. В хранимых процедурах придется за этим следить постоянно, либо вообще не использовать динамический SQL, что также уменьшает количество инструментов разработчика.
* Повторное использование SQL
В наличии, и даже более развито. См. деревья выражений и LINQ в .NET
* Простая отладка SQL
Большинство описанных минусов отсутствует. В наличии только действительно более сложная трассировка, анализ качества запросов и внесение изменений по результатам анализа так, чтобы исправить проблему.
Вопрос: Читал, что светодиодные лампы белого цвета уменьшают со временем свою яркость, т.к. ухудшается люминисцентное покрытие. Не практичней ли было бы получать белый цвет освещения комбинацией RGB, которая, фактически, вечная?
На всякий случай так же напомню, чипсеты Intel Z68 и выше умеют подключать SSD как кэширующий диск для основного, без потери работоспособности в случае отказа SSD. Соответственно, примерно за 2 т.р. можно поставить 60Гб SSD для кэширования вашего основного 3Tb диска за 6.т.р.
Наверно хороший продукт, о котором я бы хотел узнать побольше. Но первые 6 абзацев, которые осилил (а подозреваю и весь остальной текст) описывает то, что я бы лучше прочитал в документации системы.
Если я не знал до этого о том, зачем нужна Teradata (а я не знал), то в этой статье и не узнаю. А если знал, то содержание статьи ожидаю найти в мануалах.
Надеюсь, статья найдет своих читателей, но, имхо, в статье, имеет смыл писать о важных отличиях, проводить сравнения, рассказывать о киллер-фичах и т.д.
В водороде очень высокая плотность энергии (особенно, если не считать окислитель) по сравнению с электрическими батареями.
При этом водород — это не альтернативная энергия, а лишь альтернативный носитель. Выделение большинства объема водорода идет из углеводородного топлива.
Компилятора под рукой нет, но не нравится строчка if(c<=' '){ s++; continue; }
Не свалится ли на выход за границы массива например, на таком примере: "(3+1"
Я также задумывался о проблематике научного краудфандинга, но основную проблему выделил — другую: Сложность цепочки исследований.
Например, возьмем задачу «увеличение продолжительности жизни до 100 лет». Под эту задачу, уверен, многие бы были готовы предоставить финансирование.
Но эта задача распадается на кучу современных направлений и подходов, которые распадаются на решаемые сейчас проблемы.
Т.е. краудфандинговый сайт должен уметь связывать решаемые задачи с финансируемыми проектами. При этом необходимо уметь легко отследить и показать связь потенциальному инвестору.
Как дополнительный бонус, хорошо бы ученому понять, куда ему можно приложить усилия в своей тематике, чтобы его исследование попало под финансирование.
И как? Лично в Вашем проекте у Вас есть план на то, что вы нарушите сроки? Очень хочется посмотреть, как он выглядит.
1. Он явно считает себя самым умным.
2. Он говорит очевидные вещи, вроде «что любая оценка проекта есть величина статистическая и имеет свой доверительный интервал». А когда ему отвечают «и что?» он считает, что «его не услышали». А потом вклинит: «а я же говорил!»
3. Остальные работали 60 часов и значит это был их выбор. Возможно, работа идет в стартапе, или за нее платят так, что и 60 часов можно поработать. Если Вася недоволен, ему стоит искать новое место работы, а не жаловаться.
4. И главное, если у Васи есть рациональные мысли (тут их не видно), то либо он действительно работает среди идиотов либо не умеет их доносить. Опять таки, проблемы только у него.
Скрипт запускается в postfunction в каком-то шаге workflow с помощью ScriptRuner
Но этот подход изменяет концепцию жиры. Потом возникают сложности:
1. Понять, кто делал задачу (только через историю)
2. Собрать статистку по разработчикам.
3. Поддерживать такое решение, особенно функции выбора, КАКОМУ тестировщику отдать эту работу, если он не один.
Мое мнение: для описанной задачи нужно использовать несколько проектов жиры. Например, отдельно для разработки и отдельно для тестирования. При этом можно автоматом создавать задачи в другом проекте и связывать их с исходной.
Или заводить отдельные поля тестировщик, аналитик и т.д., для каждой роли и прописывать пользователей в них.
Два update в батче сделает, понятно, ORM.
Или есть мнение, что если код копирования данных написан в триггере, то это более надежно, чем два update в батче?
Считаю, для промышленного написания бизнес-логики удобно использовать статически типизированные, объектноориентированные языки, на которые есть хорошие инструменты:
* unit тестирования
* статического анализа и анализ метрик кода
* отладки
Java, Python, C# — хороший выбор.
T-SQL — в этом смысле плох. Про PL/SQL не знаю, есть ли в нем указанные инструменты и действительно ли он ООП или же как PHP.
Также замечу, что описанные плюсы ХП по сравнению с ORM в большинстве ошибочны. Сравню с .C# и DataObject.Net, т.к. пользуюсь ими.
* Скорость
Значимое отличие в скорости будет проявляться только за счет:
1. Константных задержек передачи по сети и материализации.
2. Использования редких средств SQL, не поддерживаемых большинством ORM, например такие как оконные функции.
Первая ситуация значима для разовых или очень быстрых запросов до нескольких мс, которых, как правило, не много.
Вторая — специфична, и в большинстве запросов бизнес приложений не проявят себя.
Ну и есть еще дискуссия по поводу качества запросов ORM. Я, например, занимался анализом запросов от DataObject и могу сказать что их качество скорости выполнения очень высоко, как бы при этом не выглядел пугающе внешний вид.
* Сокрытие структуры данных
LOL. Как раз, когда структура в модели классов, то происходит сокрытие способа хранения, и не придется изменять приложение, например, при смене способа организации наследования Single/Class/Concrete Table Inheritance.
При этом, при действительной необходимости изменения МОДЕЛИ, например, в C#, 99% работы за тебя сделает Resharper и статическая типизация.
* Гибкое управление правами доступа
Опять мимо. В слое доступа к данным можно организовать сколь угодно сложную логику ограничения доступа и она будет прозрачна для кода бизнес-логики.
* Меньшая вероятность SQL injection
ORM защищает от SQL инъекций лучше, т.к. делает это централизованно в LINQ провайдере. В хранимых процедурах придется за этим следить постоянно, либо вообще не использовать динамический SQL, что также уменьшает количество инструментов разработчика.
* Повторное использование SQL
В наличии, и даже более развито. См. деревья выражений и LINQ в .NET
* Простая отладка SQL
Большинство описанных минусов отсутствует. В наличии только действительно более сложная трассировка, анализ качества запросов и внесение изменений по результатам анализа так, чтобы исправить проблему.
Если я не знал до этого о том, зачем нужна Teradata (а я не знал), то в этой статье и не узнаю. А если знал, то содержание статьи ожидаю найти в мануалах.
Надеюсь, статья найдет своих читателей, но, имхо, в статье, имеет смыл писать о важных отличиях, проводить сравнения, рассказывать о киллер-фичах и т.д.
При этом водород — это не альтернативная энергия, а лишь альтернативный носитель. Выделение большинства объема водорода идет из углеводородного топлива.
Не свалится ли на выход за границы массива например, на таком примере: "(3+1"
Например, возьмем задачу «увеличение продолжительности жизни до 100 лет». Под эту задачу, уверен, многие бы были готовы предоставить финансирование.
Но эта задача распадается на кучу современных направлений и подходов, которые распадаются на решаемые сейчас проблемы.
Т.е. краудфандинговый сайт должен уметь связывать решаемые задачи с финансируемыми проектами. При этом необходимо уметь легко отследить и показать связь потенциальному инвестору.
Как дополнительный бонус, хорошо бы ученому понять, куда ему можно приложить усилия в своей тематике, чтобы его исследование попало под финансирование.
Использование:
Реализация: