>Безусловно вы можете сказать что UnitOfWork работает в рамках каждого обращения клиента к серверу. Но, согласитесь, что это не есть полноценный UnitOfWork.
Ну как раз так часто (почти всегда?) и делается. Тут просто «удачно» сошлись в одном месте идеи SOA, декларативного управления транзакциями и работа с ORM с помощью UnitOfWork.
«полноценные»/«не полноценные» — это уже больше жонглирование словами. Если граница транзакции проходит по вызову метода сервиса-«фасада» в котором осуществляется осмысленный законченый кусок работы — то имхо это и есть вполне себе unitofwork).
Да и если делать границы UnitOfWork по границам сеанса работы пользователя — то возникнет же таже проблема что и с длинными транзакциями в базе данных.
ORM позволяет сэкономить значительное время на OLTP. Всё. OLAP часть придётся всё-равно писать руками.
Личное наблюдение: многие проблемы при использовании ORM вызваны тем что «проектирование» идёт от структуры таблиц к иерархиям классов. Если делать на борот — с ORM будет меньше проблем.
Ещё один немаловажных плюс ORM в которых реализован UnitOfWork — они позволяют полностью скрыть тот факт что мы используем РСУБД. Это выражается вот в чём:
Когда вы работаете с библиотеками построенными на ActiveRecord у вас работа выглядит примерно так:
myDomainObject=myDBFramework.fetchById(id);
myDomainObject.set(....);
myDomainObject.save/update или myDBFramework.update(myDomainObject);
Так вот, с hibernate и некоторыми другими фреймворками — последний вызов не нужен, как например когда мы работаем с in-memory реализацией хранилища. Сокрытие.
Скажите, правильно ли я понял суть текста:
0)Все допускают ошибки
1)Если вы используете ООП — опирайтесь на принципы SOLID и тогда ошибки проектирования будут стоить дешевле.
Для 1972 года — вполне себе отличная работающая идея.
В современных реалиях: если код покрыт автотестами, то внести туда нетривиальную детерменированную багу таким образом, чтобы все автотесты проходились — кажется мне очень непростым делом.
расстановка таких рэндомов
if(someCondition || random*1000 == 42)
не в счёт)
+Ошибки многопоточности — остаются совсем в стороне
eliah_lakhin, Если возможно, расскажите, в чём преимущества «функциональной» реализации по сравнению с «традиционной». Просто из примера, это не очевидно: кода стало больше + синтаксис generic'ов усложняет чтение.
Я говорил немного о другом. и и если в кратце, то: если сайт развлекательной тематики, и пользователь не знает о нём (читать как «не пользовался полноразмерной версией»), то с большой вероятностью, пользуясь только мобильным браузером, он не станет вашим посетителем. (Теоретически есть возможность нагнетать значительный трафик новых мобильных посетителей через «мне нравится» в лентах активности мобильных версий соц сетей, но каких-то чисел и историй успеха мне неизвестно)
Если возможно — было бы интересно посмотреть статистику вашего сайта (сейчас многие системы позволяют дать доступ «только для чтения». Хотябы на один день).
Или — опять же, если возможно, график с 2мя кривыми «новые посетители И мобильные браузеры» и «новые посетители».
Вот и я о том же. Есть подозрение что мобильная версия для развлекательного сайта — увеличит только число просмотров и значительного увеличения аудитории за счёт мобильно составляющей не случится.
цыфра мобильных посещений выглядит интересно. А есть у вас данные о том какое количество мобильных помещений приходится НЕ на ресурсы вконтакте, яндекса, мейл.ру?
Несколько лет назад сталкивался с похожей проблемой, и тогда мы её решали через то-ли js + title толи js + status
Но если требуется чуть более сложное взаимодействие, и нужно иметь возможность как-то инициировать процессы со странички во встроенном браузере — то можно использовать встроенный в JRE http сервер для этого ну и дальше уже как умеем ajax/REST/вашелюбимоеbuzzword
Кстати, обратите внимание, что «просто выразился некорректно» переживается всеми участниками обсуждения намного лучше если предварительно тот, кто «выразился некорректно» не позволял себе высказываний вроде «Нет, чтобы документацию почитать…»
«на порядки меньше» — это значит более чем на порядок, т.е. в 100 и более раз. Простите но это глупости которые любят повторять фанатики.
На Java как и на C++ можно писать достаточно плохо чтобы решение было хрупким и никто не мог понять что же происходит.
Тут ведь всё относительно и у каждого участника тех событий окажется своя правда и тысячи аргументов в поддержку своей версии.
Просто из поста складывалось ощущение что «крутой нрав» — одно из слагаемых успеха. Я хотел показать что это вполне может быть не так. Один в поле не воин и в ситуации, когда «манагер» попытается выставит всех идиотами и бездельниками — поставленной цели он может и не добиться. Особенно когда на стороне «идиотов» месяцы/годы совместной б.м. нормальной работы.
Более гибким надо быть. Стремление «в лоб» убедить людей в том, что они ничего не делают или публично это показать — позитивных результатов не принесёт, а отношения испортит и сделает достижение цели ещё более сложным. Ведь мало кто готов помогать в решении проблем человеку, который вчера перед «генеральным» пытался выставить весь отдел идиотами.
Та часть которая от КО (про глоссарий, про аналитиков, про опросы, про квадратики со стрелочками, и даже про преимущества готовых решений) — да всё хорошо и правильно. Но как только начинаются эмоциональные оценки и «юморок из презентаций 'гуру'» — впечатление резко портится.
Вот была компания, работала. В ней был отдел разработки и тоже работал. И всё у них было не то чтобы прям очень хорошо, но в среднем — неплохо. И вот появился в компании новый манагер проектов которому поручили за 4 месяца открыть интернет-магазин. Он взялся за дело и делал в целом всё не плохо. Но вот в какой-то момент, вместо того чтобы решать проблемы и двигаться к результату, он начал «дёргать рубильники», «требовать кадровых перестановок», и всячески показывать что он то «за дело», и всё бы хорошо но вот только разработчики халтурят, бездельничают, проще говоря «Козлы». Естественно — начальнику разработки «козлом» быть не хочется. И тут начинаются чудеса — в ТЗ находится много ошибок и каждая ошибка постфактум начинает раздуваться как оч серьёзная, из-за которой все сроки и сорваны. Да и начальники других отделов — не бездельничают (как могло показаться из картинок манагера и аналитика), а работают в поте лица. И вот вся эта братия совместными усилиями проект разваливает + ведёт информационные войны с понятной целью.
В итоге — магазин не запущен, манагер уволился. Печаль.
Простите, но «сведение количества ошибок к нулю. Да это и невозможно (если кто-то захочет, это можно доказать чисто математически)»
противоречит
«ошибок в жизненно важных частях бизнес логики быть не должно»
И это вполне по силам заметить на слух. Так что подозреваю, что «очень проникновенная речь» не получилось. Возможно так же что немного уменьшился авторитет в глазах некоторых участников команды.
Что же до сабжа — я тоже думаю, что уже давно наступила эпоха «наивных реализаций», но не все себе ещё в этом признались.
Заходите в мойкруг, например. Находите людей которые там работали инедавно уволились — и разговариваете с ними.
В самой компании:
посомтреть какие задачи стоят в системе заданий
поспрашивать PMа о том сколько людей ушло с проекта, почему уволились
попросить главного по тарелочкам используется ли у них TDD или хотябы просто юнит тестирование. Если используется — сколько времени уходит на тесты, какой они длинны. Если неиспользуется- то почему.
Распросить об архитектуре и поыптаться на слух найти признаки циклических зависимостей.
Если это «вебпроект» — попросить посомтреть «код контроллера» в котором происходит обработка загруженных файлов.
«Конечно «бить морду» это метафора» — да метафора. метафора для наказания.
«Когда вы заметите ошибку, может быть уже поздно» — да может быть, а может быть и нет. Но вы в своём топике говорите о техдире как о некоем сверх человеке, который сам не допускает ошибок + проверят работу других и недаёт ошибиться другим. В теории всёздорово, но в жизни — все ошибаются. Достаточно посомтреть на гугл, яндекс, мейл — могут нанять (а некоторые и наняли) умнейших людей — но у них постоянно случаются проблемы связанные с ошибкой «самого умного». Уберечься от этого невозможно. Надо просто адекватно реагироваться на такие события, а не «пинать» или «бить морду»
«Постараемся понять, кому «бить морду».»
Очевидно, что «себе».
Очень странно такое читать. Мы наняли людей, квалифицированных, с признаками лояльности и прозрачной заинтересованностью в успешном завершении проекта. Люди честно работают. Но случилась ошибка. Если вместо того чтобы разобраться в причинах и подумать возможно ли её избежать в будущем, мы начнём кого-то «мутузить» — то лучше не станет, а хабр пополнится ещё одним топиком с «плачем ярославны» о том какие программисты плохие и как же их надо правильно стегать кнутом.
«Гибкость» гибких методов не превышает «гибкость ума» людей «принимающих решения» (как технические так и управленческие). Стремление избежать ошибок (в широком смысле) — проявление «негибкости».
Ну как раз так часто (почти всегда?) и делается. Тут просто «удачно» сошлись в одном месте идеи SOA, декларативного управления транзакциями и работа с ORM с помощью UnitOfWork.
«полноценные»/«не полноценные» — это уже больше жонглирование словами. Если граница транзакции проходит по вызову метода сервиса-«фасада» в котором осуществляется осмысленный законченый кусок работы — то имхо это и есть вполне себе unitofwork).
Да и если делать границы UnitOfWork по границам сеанса работы пользователя — то возникнет же таже проблема что и с длинными транзакциями в базе данных.
ORM позволяет сэкономить значительное время на OLTP. Всё. OLAP часть придётся всё-равно писать руками.
Личное наблюдение: многие проблемы при использовании ORM вызваны тем что «проектирование» идёт от структуры таблиц к иерархиям классов. Если делать на борот — с ORM будет меньше проблем.
Ещё один немаловажных плюс ORM в которых реализован UnitOfWork — они позволяют полностью скрыть тот факт что мы используем РСУБД. Это выражается вот в чём:
Когда вы работаете с библиотеками построенными на ActiveRecord у вас работа выглядит примерно так:
myDomainObject=myDBFramework.fetchById(id);
myDomainObject.set(....);
myDomainObject.save/update или myDBFramework.update(myDomainObject);
Так вот, с hibernate и некоторыми другими фреймворками — последний вызов не нужен, как например когда мы работаем с in-memory реализацией хранилища. Сокрытие.
0)Все допускают ошибки
1)Если вы используете ООП — опирайтесь на принципы SOLID и тогда ошибки проектирования будут стоить дешевле.
В современных реалиях: если код покрыт автотестами, то внести туда нетривиальную детерменированную багу таким образом, чтобы все автотесты проходились — кажется мне очень непростым делом.
расстановка таких рэндомов
if(someCondition || random*1000 == 42)
не в счёт)
+Ошибки многопоточности — остаются совсем в стороне
А вот кода стало больше (INT_TO_STRING + map +join > императивный joinNumbers)
И появились конструкции вроде
public static <F, T> List map(Collection from, Function<? super F,? extends T> transformer) {
Если возможно — было бы интересно посмотреть статистику вашего сайта (сейчас многие системы позволяют дать доступ «только для чтения». Хотябы на один день).
Или — опять же, если возможно, график с 2мя кривыми «новые посетители И мобильные браузеры» и «новые посетители».
Но если требуется чуть более сложное взаимодействие, и нужно иметь возможность как-то инициировать процессы со странички во встроенном браузере — то можно использовать встроенный в JRE http сервер для этого ну и дальше уже как умеем ajax/REST/вашелюбимоеbuzzword
На Java как и на C++ можно писать достаточно плохо чтобы решение было хрупким и никто не мог понять что же происходит.
Кто-нибудь кстати может сказать о каком таком тайном «знании указателей» (кроме очевидного), которого никто не знает, он говорит?
Ну и непонятно почему он не страдает из-за того что весь мир ушёл от «основ» (ассемблера) к «богомерзким» языкам выского уровня.
Просто из поста складывалось ощущение что «крутой нрав» — одно из слагаемых успеха. Я хотел показать что это вполне может быть не так. Один в поле не воин и в ситуации, когда «манагер» попытается выставит всех идиотами и бездельниками — поставленной цели он может и не добиться. Особенно когда на стороне «идиотов» месяцы/годы совместной б.м. нормальной работы.
Более гибким надо быть. Стремление «в лоб» убедить людей в том, что они ничего не делают или публично это показать — позитивных результатов не принесёт, а отношения испортит и сделает достижение цели ещё более сложным. Ведь мало кто готов помогать в решении проблем человеку, который вчера перед «генеральным» пытался выставить весь отдел идиотами.
Вот была компания, работала. В ней был отдел разработки и тоже работал. И всё у них было не то чтобы прям очень хорошо, но в среднем — неплохо. И вот появился в компании новый манагер проектов которому поручили за 4 месяца открыть интернет-магазин. Он взялся за дело и делал в целом всё не плохо. Но вот в какой-то момент, вместо того чтобы решать проблемы и двигаться к результату, он начал «дёргать рубильники», «требовать кадровых перестановок», и всячески показывать что он то «за дело», и всё бы хорошо но вот только разработчики халтурят, бездельничают, проще говоря «Козлы». Естественно — начальнику разработки «козлом» быть не хочется. И тут начинаются чудеса — в ТЗ находится много ошибок и каждая ошибка постфактум начинает раздуваться как оч серьёзная, из-за которой все сроки и сорваны. Да и начальники других отделов — не бездельничают (как могло показаться из картинок манагера и аналитика), а работают в поте лица. И вот вся эта братия совместными усилиями проект разваливает + ведёт информационные войны с понятной целью.
В итоге — магазин не запущен, манагер уволился. Печаль.
противоречит
«ошибок в жизненно важных частях бизнес логики быть не должно»
И это вполне по силам заметить на слух. Так что подозреваю, что «очень проникновенная речь» не получилось. Возможно так же что немного уменьшился авторитет в глазах некоторых участников команды.
Что же до сабжа — я тоже думаю, что уже давно наступила эпоха «наивных реализаций», но не все себе ещё в этом признались.
В самой компании:
посомтреть какие задачи стоят в системе заданий
поспрашивать PMа о том сколько людей ушло с проекта, почему уволились
попросить главного по тарелочкам используется ли у них TDD или хотябы просто юнит тестирование. Если используется — сколько времени уходит на тесты, какой они длинны. Если неиспользуется- то почему.
Распросить об архитектуре и поыптаться на слух найти признаки циклических зависимостей.
Если это «вебпроект» — попросить посомтреть «код контроллера» в котором происходит обработка загруженных файлов.
«Когда вы заметите ошибку, может быть уже поздно» — да может быть, а может быть и нет. Но вы в своём топике говорите о техдире как о некоем сверх человеке, который сам не допускает ошибок + проверят работу других и недаёт ошибиться другим. В теории всёздорово, но в жизни — все ошибаются. Достаточно посомтреть на гугл, яндекс, мейл — могут нанять (а некоторые и наняли) умнейших людей — но у них постоянно случаются проблемы связанные с ошибкой «самого умного». Уберечься от этого невозможно. Надо просто адекватно реагироваться на такие события, а не «пинать» или «бить морду»
Очевидно, что «себе».
Очень странно такое читать. Мы наняли людей, квалифицированных, с признаками лояльности и прозрачной заинтересованностью в успешном завершении проекта. Люди честно работают. Но случилась ошибка. Если вместо того чтобы разобраться в причинах и подумать возможно ли её избежать в будущем, мы начнём кого-то «мутузить» — то лучше не станет, а хабр пополнится ещё одним топиком с «плачем ярославны» о том какие программисты плохие и как же их надо правильно стегать кнутом.
«Гибкость» гибких методов не превышает «гибкость ума» людей «принимающих решения» (как технические так и управленческие). Стремление избежать ошибок (в широком смысле) — проявление «негибкости».