В статье фундаментальная ошибка: наши предки жёстко изнашивали свои организмы постоянными нагрузками , для них это было не здоровье. Пример неудачный, про древних наших пращуров. Там дети в 12 лет уже имели проблемы с опоро двигательным аппаратом как нынешние 50-ти летние.
В остальном - очевидный тезис, физкультура хорошо, гиподинамия плохо.
И, да, для большинства Марафон плохо, бег трусцой по 5-10 км несколько раз в неделю - хорошо. Качалка хорошо, убить себя штангой - глупо.
Слишком много букв для статьи про пользу разумных нагрузок. Удачи вашим коленям и позвоночным дисками.
Надо быть таким сотрудником, чтобы руководство понимало: даже если ты сейчас смотришь порно посреди рабочего дня, волноваться не о чем — поставленные задачи будут выполнены качественно и вовремя!
Гражданская позиция может и должна быть у каждого гражданина. Если бы химики в нацистской германии все дружно саботировали разработку хим оружия, то не было бы хим оружия у фашистов. Пример нарочито упрощенный, но суть ясна.
Я не к тому, что разрабы яндекса должны отказаться от проекта, а лишь отвечаю на ваш вопрос «должны ли смотреть, что делают».
Заметьте, про предметную область я ничего не писал. Ну, кроме расстрелов за гомеопатию, которые спасли бы какое-то количество жизней и сэкономили бы миллиарды честным, но неграмотным гражданам.
За гомеопатию давно пора расстреливать.
А статья хорошая.
И комментарии изящно подчеркивают проблему разных подходов разработчиков-перфекционистов и управленцев нацеленных на результат к вопросу.
Все, все, сдаюсь.
Но если бы вы внимательно читали и думали, о чем я пишу, вы бы заметили: такие проблемы есть у всех, все о них знают, и всем приходится их решать в той или иной степени. И интересно не то, что они есть, а как именно их решаете вы. Методология, алгоритмы, роли в команде и т.п. Рассказ типа «у нас прибегают пользователи с квадратными глазами и спрашивают про что-то, что уже есть… что делать? Рассказать им, что оно есть!» — ну вы поняли:)
Иногда следует признать ошибку и подумать над тем, как ее не допустить в дальнейшем. Но если вы настаиваете на дискуссии, то…
«Хотелки». Вы написали, что они есть. Вряд ли это новость. Вы написали, что они не формализованы и не понятны, и иногда пересекаются, а иногда достаточно ткнуть пальцем в уже имеющуюся фичу. Вряд ли это важная информация. Каких-то методик для работы с хотелками вы не указали. Ценность информации по хотелкам — ноль. Ну ок, тут есть посыл: юзеры хотят всякого. Причем в заголовке акцент на внутренних юзеров, но каких либо отличий их от внешних, или особенности работы с ними, я не увидел.
Про описанные задачи, готовые к работе, нет вообще ничего — даже какой-никакой классификации, не знаю… вы просто указали, что они получаются каким-то образом из хотелок. Ценность информации — абсолютный ноль.
Когда я захожу на этот ресурс, и вижу заголовок потенциально пересекающийся с моей проф. деятельностью, я радостно читаю статью: вдруг узнаю что-то новое, или получу подтверждение что делаю свою работу правильно, или какая-то важная мысль для понимания сути мироздания промелькнет. А тут — ничего нет, пустота.
Мои комментарии несут ровно одну цель: сказать вам, что заметки не должны быть такими, текст ради текста. Статьи здесь должны быть интересны кому-то из читателей. А читатели, в основном, профессионалы, или около того.
Ответьте на простой вопрос. Что же тут есть? Часть между хотелками и реализацией это я бы сказал — вообще весь проект. Сначала есть хотелка, потом знак вопроса, потом она реализована. Этот знак вопроса включает в себе не только управление требованиями, а еще кучу всего интересного. И этого в статье тоже, нет. Чего же в ней есть, кроме пары анекдотов?..
Ну очевидно, товарищ решил написать статью, чтобы получить приглашение — так все делают, это правильный путь. Но полагаю, для этого нужно копнуть глубже. Например, взять готовые методологические наработки управления требованиями (допустим, из pmbok) и рассказать о реальной практике применения каких-то из них в своей работе. С примерами. Например, как составляли матрицу требований, ранжировали ее и т.п.
Значит не с теми людьми общались. Без хранения программного кода в репозитории работать невозможно, это профнепригодность просто. Не удивлен в таком случае, что у вас скептическое отношение к БЛ в БД. Такой подход к работе я не рассматриваю.
Про «другое» сильно от задачи зависит. Если инстансов базы мало ( в идеале один), то вопрос решается организационно, в том числе и с помощью ГИТа. Сделать скрипты, компилирующие все что нужно — не так сложно. Остальное (то, что не в базе) собирайте как хотите. Но нужна синхронизация действий.
Если инстансов множество, и, допустим, у вас нет к ним доступа — нужно наладить выпуск патчей для их обновления. Но в последнем случае, я бы крепко задумался о БЛ в БД.
Идеальная ситуация для такого подхода — один облачный сервер и множество клиентов. Тогда проблем вообще нет. Либо крупные системы типа биллинга в сотовой связи, где клиентов по пальцам пересчитать можно.
Заявочка на холивар? :)
Что мешает хранить исходные коды БД в Git?
… а в 70-х я еще даже не родился.
Но думаю, продолжать смысла нет, ведь оба подхода имеют право на существование. Вопрос в конкретном случае, и целесообразности выбора того или иного пути для него.
Прочитал заметку, и не понял: где тут про управление требованиями хоть что-то? Да еще именно внутри компании. Вы рассказали о том, что у пользователей бывают хотелки, и что обычно они не очень понятно для разработчиков выражаются. Вряд ли это открытие для читателя. В конце предлагается их все брать и анализировать, чтобы получить задачи. Это, видимо, и есть управление требованиями. В чем смысл написания этого текста?
У многих принято. Есть разные подходы, и утверждать о правильности одного и ошибочности другого без привязки к конкретному случаю нельзя. И большинство СУБД дают достаточно ограниченные возможности для реализации логики. А Oracle дорогой.
Я бы сказал так: хочешь и умеешь делать логику в базе, есть деньги на Oracle и желание их потратить — прекрасно! Делай логику в базе. Если ответ «нет» хоть по одной из частей вопроса, то надо смотреть, что это за логика и принимать решение.
Если же ты купил Oracle и просто хранишь там данные в табличках — это растрата денег.
Подскажите пожалуйста, что с типами и ООП PL\SQL?
Если, например, я хочу что-то такое иметь в этой СУБД…
CREATE OR REPLACE TYPE t_mama UNDER t_person
(
m_1 NUMBER,
m_2 NUMBER,
m_3 NUMBER,
CONSTRUCTOR FUNCTION t_mama (ins t_person ) RETURN SELF AS RESULT,
MEMBER FUNCTION method1 RETURN NUMBER,
MEMBER FUNCTION method2 RETURN NUMBER,
MEMBER FUNCTION method3 (m_type NUMBER) RETURN NUMBER
) NOT FINAL;
Заявку оставлять по ссылке? Не нашел там отдельной кнопки «акция на хабре».
Можно ли дать ссылки на размещенные на гуглплей и аппсторе приложения, или надо скопировать оттуда текст и вставить?
В статье фундаментальная ошибка: наши предки жёстко изнашивали свои организмы постоянными нагрузками , для них это было не здоровье. Пример неудачный, про древних наших пращуров. Там дети в 12 лет уже имели проблемы с опоро двигательным аппаратом как нынешние 50-ти летние.
В остальном - очевидный тезис, физкультура хорошо, гиподинамия плохо.
И, да, для большинства Марафон плохо, бег трусцой по 5-10 км несколько раз в неделю - хорошо. Качалка хорошо, убить себя штангой - глупо.
Слишком много букв для статьи про пользу разумных нагрузок. Удачи вашим коленям и позвоночным дисками.
Я не к тому, что разрабы яндекса должны отказаться от проекта, а лишь отвечаю на ваш вопрос «должны ли смотреть, что делают».
А статья хорошая.
И комментарии изящно подчеркивают проблему разных подходов разработчиков-перфекционистов и управленцев нацеленных на результат к вопросу.
Но если бы вы внимательно читали и думали, о чем я пишу, вы бы заметили: такие проблемы есть у всех, все о них знают, и всем приходится их решать в той или иной степени. И интересно не то, что они есть, а как именно их решаете вы. Методология, алгоритмы, роли в команде и т.п. Рассказ типа «у нас прибегают пользователи с квадратными глазами и спрашивают про что-то, что уже есть… что делать? Рассказать им, что оно есть!» — ну вы поняли:)
«Хотелки». Вы написали, что они есть. Вряд ли это новость. Вы написали, что они не формализованы и не понятны, и иногда пересекаются, а иногда достаточно ткнуть пальцем в уже имеющуюся фичу. Вряд ли это важная информация. Каких-то методик для работы с хотелками вы не указали. Ценность информации по хотелкам — ноль. Ну ок, тут есть посыл: юзеры хотят всякого. Причем в заголовке акцент на внутренних юзеров, но каких либо отличий их от внешних, или особенности работы с ними, я не увидел.
Про описанные задачи, готовые к работе, нет вообще ничего — даже какой-никакой классификации, не знаю… вы просто указали, что они получаются каким-то образом из хотелок. Ценность информации — абсолютный ноль.
Когда я захожу на этот ресурс, и вижу заголовок потенциально пересекающийся с моей проф. деятельностью, я радостно читаю статью: вдруг узнаю что-то новое, или получу подтверждение что делаю свою работу правильно, или какая-то важная мысль для понимания сути мироздания промелькнет. А тут — ничего нет, пустота.
Мои комментарии несут ровно одну цель: сказать вам, что заметки не должны быть такими, текст ради текста. Статьи здесь должны быть интересны кому-то из читателей. А читатели, в основном, профессионалы, или около того.
Про «другое» сильно от задачи зависит. Если инстансов базы мало ( в идеале один), то вопрос решается организационно, в том числе и с помощью ГИТа. Сделать скрипты, компилирующие все что нужно — не так сложно. Остальное (то, что не в базе) собирайте как хотите. Но нужна синхронизация действий.
Если инстансов множество, и, допустим, у вас нет к ним доступа — нужно наладить выпуск патчей для их обновления. Но в последнем случае, я бы крепко задумался о БЛ в БД.
Идеальная ситуация для такого подхода — один облачный сервер и множество клиентов. Тогда проблем вообще нет. Либо крупные системы типа биллинга в сотовой связи, где клиентов по пальцам пересчитать можно.
Что мешает хранить исходные коды БД в Git?
… а в 70-х я еще даже не родился.
Но думаю, продолжать смысла нет, ведь оба подхода имеют право на существование. Вопрос в конкретном случае, и целесообразности выбора того или иного пути для него.
Я бы сказал так: хочешь и умеешь делать логику в базе, есть деньги на Oracle и желание их потратить — прекрасно! Делай логику в базе. Если ответ «нет» хоть по одной из частей вопроса, то надо смотреть, что это за логика и принимать решение.
Если же ты купил Oracle и просто хранишь там данные в табличках — это растрата денег.
Если, например, я хочу что-то такое иметь в этой СУБД…
Можно ли дать ссылки на размещенные на гуглплей и аппсторе приложения, или надо скопировать оттуда текст и вставить?