Хотелось бы более детально уточнить некоторые технические вопросы, связанные со статьей. Вы говорите, что:
Сегмент «Закрытый» реализован с использованием решений VMware. Инфраструктура соответствует требованиям приказов №17 и №21 ФСТЭК для обеспечения до 1-го класса защиты ГИС и 1-го уровня защищенности ПДн включительно. Собственно говоря, решение позволяет, в том числе, государственным органам размещать ИС с наивысшими требованиями к информационной безопасности, что подтверждается наличием аттестата соответствия требованиям защиты информации, установленным ФСТЭК России.
Предположим, что коммерческая компания, хочет разместить в вашем облаке SaaS-решение, предназначенное для органов государственной власти или органов местного самоуправления. Приложение является системой обработки ПДн. И поскольку ИС обработки ПДн — это не только сервера, но и ПО, а также клиентские рабочие места и сеть, то:
как сертифицируется само ПО, которое такая компания-разработчик размещает и требуется ли такая сертификация?
как сертифицируются клиентские рабочие места конкретного заказчика — пользователя SaaS-решения, а также каналы связи с ним?
как сертифицируются клиентские рабочие места сотрудников компании-разработчика SaaS-решения, с которых выполняются работы по обслуживанию системы, а также каналы связи?
какие бумаги, гарантирующие что конкретный заказчик (пользователя SaaS-решения) исполняет закон о защите ПДн, вы предоставляете?
Keks650, подскажите, а какой процесс использовался до перехода? он как-то был описан, сформулирован, осознан? или люди просто интуитивно правильно работали?
Подскажите пожалуйста, какую "кучу плюшек" можно получить на 25$ в Azure? Особенно интересно было бы в сравнении c программой Amazon Web Services Free Tier?
Возможно, но когда столько перечеркнутых сумм и звездочек со сносками, очень сложно понять, какова же все-таки цена. 119 для существующих пользователей-это для тех, у кого уже есть решарпер? А для новых людей в команде?
Основная у нас VS 2012 и к ней достаточно давно куплены решарперы. На 2013 многие не переходили, в основном из-за необходимости обновлять решарпер. С 2015-й ситуация другая, перейти на нее хочется всей коммандой, но даже при пожизненной лицензии убедить выделить средства на обновление пока не удается. Все-таки это не IDE, а ускорение работы в ней, и некоторым кажется, что можно «легко обойтись». Теперь же вместе с выделением денег на продление нужно еще и смириться с тем что, это только на год, а в следующем году нужно будет платить еще раз. Хотя вероятность перехода с VS 2015 через год не очень велика. Добавьте к этому новые курсы валют и появление light bulbs в VS 2015, и пропасть между разработчиком и лицом, разрешающим покупку, становится почти непреодолимой.
Выскажусь относительно ReSharper-а. И до сегодняшнего дня в нашей компании, к примеру, было сложно объяснить руководству, почему нужно платить 250 долларов на разработчика за этот, пусть и реально полезный, продукт. Теперь же нужно, будет платить 250 ежегодно. Если раньше мы могли спокойно сидеть на старой версии Vs больше года, то теперь так не выйдет. Кстати, надо отметить что Макрософт даёт 5 Vs Community вообще бесплатно.
В общем, все это грустно. Хочется надеяться, что с появлением Roslyn все же появятся достойные аналоги решарпера бесплатно или за разумные деньги.
Это позволяет нам оценить производительность программиста, основываясь исключительно на времени выполнения задания: если все решено меньше, чем за час, мы будем довольны
А если потом в реальной работе программист решает задачу вот так, за час, а после этого тратит еще три раза по часу, чтобы сделать код не просто рабочим но и правильным/красивым/обобщенным и т.п., вместо того, чтобы потратить сразу два или два с половиной часа и сделать все то же самое? Насколько объективна оценка программиста с позиции такой «производительности»?
Интересно, а есть ли примеры, где сами разработчики/менеджеры реальных проектов описывают свой процесс управления рисками? В блогах, например? Они его как-то формализуют или управление рисками происходит на уровне «ощущений и инстинктов»?
А как вы разграничиваете роли аналитика, архитектора и проектировщика? Мне, честно говоря, тоже странно выполнение одним человеком ролей архитектора и аналитика одновременно. Я бы в этом случае предположил, что этот же человек и основной разработчик тоже.
Например, я хочу несколько директив, которые по сути своей dropdown-контролы, но содержимое выпадающей области разное: в одном случае простой список, в другом — какая-то более ложная конструкция, позволяющая искать/выбирать элементы. В силу того, что большую часть времени я пишу на языке с наследованием, мне описанное разнообразие хочется сделать с помощью соответствующих классов-наследников. Хотя, require, похоже тоже для этого подойдет.
Спасибо!
Еще попутно вопрос по структурированию кода приложения: где, по Вашему мнению, лучше размещать логику построения (перестроения) DOM, общую для нескольких директив? Ведь наследования директив нормальными способами не добиться?
Но ведь эти проблемы связаны не непосредственно с AngularJs, я правильно понимаю? Т.е. понятно, что резиновый интерфейс не всегда позволяет сделать интерфейс удобным для всех форм-факторов, а косяки с разметкой могут быть разные в разных браузерах. Но если все-таки этот путь выбран (хотя бы как временный), то как себя будет вести AngularJs со своим двусторонним связыванием в мобильном браузере? В аспекте производительности и в аспекте совместимости AngularJs с разными браузерами…
Интересно было бы узнать о применении AngularJs для разработки Web-приложений, работающих в браузере мобильных устройств. Как в этом случае трансформируются рекомендуемые ограничения по количеству watch-ей на странице? Было бы здорово еще и узнать о каких-нибудь примерах из реального опыта.
Думаю, ответ вовсе не очевиден! Почему CodeFirst так быстро набирает популярность и фактически становится приоритетным подходом при использовании EF?
Кроме того, одна из задач ORM, избавить разработчика бизнес-логики от нюансов системы хранения и сделать модель предметной области чистой. И в этом смысле работая с диаграммой классов, я именно проектирую такую модель. Естественно, вопрос отображения этой модели в БД тоже важен. Но решается он не визуально на диаграмме, а в коде, и меня лично это совсем не смущает, поскольку те места, где это отображение определяется при использовании fluent api, заведомо известны.
Но у меня тогда еще вопрос: если Вы используете некую «замечательную» альтернативу EF, которая позволяет делать все гораздо удобнее, то она либо «серебряная пуля» (но Вы сами в одном из комментариев признали, что ее нет), либо что-то, обладающее другими недостатками. Так давайте же тогда озвучим эту альтернативу и будем сравнивать EF, не с потенциальными «пожеланиями» к ORM, а с реальным конкурентом. Иначе, как-то однобоко получается.
CodeFirst… Поэтому мне нужны картинки. Компактные, наглядные, удобные. Причем модель должна быть не на одной картинке, а на нескольких, по-частям, выбранным как-то предметно. Ну, и далее, с картинок что-то как-то должно генерироваться, не буду же я писать однотипный код сотнями раз, да ещё и не делать при этом ошибок.
А почему для визуализации модели нельзя в случае с CodeFirst использовать диаграммы классов? Они, по-моему, удовлетворяют описанным требованиям?
А каким был интерфейс репозитория? Универсальным, т.е. выставлялся IQueryable или его аналог, или просто содержал конечный набор методов, который и определял набор возможных запросов?
И еще интересно было бы узнать Ваше мнение. Допустим в некой задаче нет необходимости поддерживать разные хранилища/ORM, есть только EF и, к примеру, SQL Server. Но в то же время набор возможных запросов к БД сильно ограничен и расширяется очень предсказуемо. Стали бы Вы оборачивать EF в репозиторий с простым интерфейсом, или же просто использовали бы DbContext?
Ну теперь, вроде бы, позиции наши ясны. Спасибо, lair, за дискуссию! Было интересно!
Кстати говоря, здорово было бы Вам написать пост по материалам комментариев к этой статье: Вы, по моему, большую работу проделали по разъяснению. Осталось только все это собрать вместе.
Нет, ее посыл в том, что IQueryable — это текущая абстракция, которая не предоставляет изоляции. Если это осознавать, равно как и осознавать ограничения этого — все будет хорошо.
А эти слова разве я написал в начале статьи?
From time to time I encounter people who attempt to express an API in terms of IQueryable. That's almost always a bad idea. In this post, I'll explain why
На всякий случай напомню, что я написал почти то же самое:
весь ее посыл в том, чтобы не использовать этот интерфейс в своем API
Вам кажется. На самом деле, речь идет о замене ORM за абстрактным интерфейсом
Когда мне говорят, что мне кажется, а собеседник знает, как «на самом деле», я очень настораживаюсь: возможно у человека сверхспособности. Боюсь что в данном случае у нас с Вами просто разный прошлый опыт и набор тех проблем, с которыми мы сталкивались. Поэтому Вы смотрите на это в своем контексте, а я в своем. А кто из нас «на самом деле» прав, может сказать только Марк Симан.
Если вы предполагаете заменять хранилище — тогда зависимость от IQueryable плоха (потому что его реализации не взаимозаменяемы). Если нет — то нет.
Но заметьте, что автор ответа на SO (он же и автор вопроса) нигде не говорит о том, что собирается заменять NHibernate. И тем не менее, он зачем-то инкапсулирует IQueryable внутри репозитория.
как только мы отбираем IQueryable, мы берем на себя обязанность предоставить замену. Банальный пример: как в предложенном DSL выразить запрос на (а) начатые и незавершенные (б) начатые или незавершенные? А проекции? А джойны? Ну и понеслась. А интеграция с UI и сервисной моделью навроде OData?
А вот тут я с Вами полностью согласен. Как только у нас появляется разнообразие запросов, мы будем изобретать велосипед, создавая нечто такое же гибкое, как IQueryable, с теми же проблемами. Вопрос только в том, всегда ли нужно такое разнообразие и те возможности, о которых Вы написали.
Понятно. Но насчет Симана я не соглашусь: по-моему Вы отделяете приведенное Вами ранее высказывание от контекста.
If you have a specific ORM in mind, then be explicit about it. Don't hide it behind an interface. It creates the illusion that you can replace one implementation with another. In practice, that's impossible. Imagine attempting to provide an implementation over an Event Store.
Во-первых, статья называется «IQueryable is Tight Coupling» и весь ее посыл в том, чтобы не использовать этот интерфейс в своем API. Мне даже кажется, что Симан считает, что IQueryable вообще не стоило разрабатывать, поскольку абстракция «дырявая» до неприличия. Хотя непонятно, как тогда стоило бы поступить.
Во-вторых, в приведенной цитате я бы выделил фразу «It creates the illusion that you can replace one implementation with another». Возникает вопрос: implementation of what? Мне кажется, что речь об интерфейсе IQueryable.
В-третьих, в подтверждение этого есть комментарий к статье с просьбой к Марку оценить интерфейс репозитория над NHibernate:
Хотелось бы более детально уточнить некоторые технические вопросы, связанные со статьей. Вы говорите, что:
Предположим, что коммерческая компания, хочет разместить в вашем облаке SaaS-решение, предназначенное для органов государственной власти или органов местного самоуправления. Приложение является системой обработки ПДн. И поскольку ИС обработки ПДн — это не только сервера, но и ПО, а также клиентские рабочие места и сеть, то:
Основная у нас VS 2012 и к ней достаточно давно куплены решарперы. На 2013 многие не переходили, в основном из-за необходимости обновлять решарпер. С 2015-й ситуация другая, перейти на нее хочется всей коммандой, но даже при пожизненной лицензии убедить выделить средства на обновление пока не удается. Все-таки это не IDE, а ускорение работы в ней, и некоторым кажется, что можно «легко обойтись». Теперь же вместе с выделением денег на продление нужно еще и смириться с тем что, это только на год, а в следующем году нужно будет платить еще раз. Хотя вероятность перехода с VS 2015 через год не очень велика. Добавьте к этому новые курсы валют и появление light bulbs в VS 2015, и пропасть между разработчиком и лицом, разрешающим покупку, становится почти непреодолимой.
В общем, все это грустно. Хочется надеяться, что с появлением Roslyn все же появятся достойные аналоги решарпера бесплатно или за разумные деньги.
А если потом в реальной работе программист решает задачу вот так, за час, а после этого тратит еще три раза по часу, чтобы сделать код не просто рабочим но и правильным/красивым/обобщенным и т.п., вместо того, чтобы потратить сразу два или два с половиной часа и сделать все то же самое? Насколько объективна оценка программиста с позиции такой «производительности»?
Еще попутно вопрос по структурированию кода приложения: где, по Вашему мнению, лучше размещать логику построения (перестроения) DOM, общую для нескольких директив? Ведь наследования директив нормальными способами не добиться?
Кроме того, одна из задач ORM, избавить разработчика бизнес-логики от нюансов системы хранения и сделать модель предметной области чистой. И в этом смысле работая с диаграммой классов, я именно проектирую такую модель. Естественно, вопрос отображения этой модели в БД тоже важен. Но решается он не визуально на диаграмме, а в коде, и меня лично это совсем не смущает, поскольку те места, где это отображение определяется при использовании fluent api, заведомо известны.
Но у меня тогда еще вопрос: если Вы используете некую «замечательную» альтернативу EF, которая позволяет делать все гораздо удобнее, то она либо «серебряная пуля» (но Вы сами в одном из комментариев признали, что ее нет), либо что-то, обладающее другими недостатками. Так давайте же тогда озвучим эту альтернативу и будем сравнивать EF, не с потенциальными «пожеланиями» к ORM, а с реальным конкурентом. Иначе, как-то однобоко получается.
А почему для визуализации модели нельзя в случае с CodeFirst использовать диаграммы классов? Они, по-моему, удовлетворяют описанным требованиям?
И еще интересно было бы узнать Ваше мнение. Допустим в некой задаче нет необходимости поддерживать разные хранилища/ORM, есть только EF и, к примеру, SQL Server. Но в то же время набор возможных запросов к БД сильно ограничен и расширяется очень предсказуемо. Стали бы Вы оборачивать EF в репозиторий с простым интерфейсом, или же просто использовали бы DbContext?
Кстати говоря, здорово было бы Вам написать пост по материалам комментариев к этой статье: Вы, по моему, большую работу проделали по разъяснению. Осталось только все это собрать вместе.
На всякий случай напомню, что я написал почти то же самое:
Когда мне говорят, что мне кажется, а собеседник знает, как «на самом деле», я очень настораживаюсь: возможно у человека сверхспособности. Боюсь что в данном случае у нас с Вами просто разный прошлый опыт и набор тех проблем, с которыми мы сталкивались. Поэтому Вы смотрите на это в своем контексте, а я в своем. А кто из нас «на самом деле» прав, может сказать только Марк Симан.
Но заметьте, что автор ответа на SO (он же и автор вопроса) нигде не говорит о том, что собирается заменять NHibernate. И тем не менее, он зачем-то инкапсулирует IQueryable внутри репозитория.
А вот тут я с Вами полностью согласен. Как только у нас появляется разнообразие запросов, мы будем изобретать велосипед, создавая нечто такое же гибкое, как IQueryable, с теми же проблемами. Вопрос только в том, всегда ли нужно такое разнообразие и те возможности, о которых Вы написали.
Во-первых, статья называется «IQueryable is Tight Coupling» и весь ее посыл в том, чтобы не использовать этот интерфейс в своем API. Мне даже кажется, что Симан считает, что IQueryable вообще не стоило разрабатывать, поскольку абстракция «дырявая» до неприличия. Хотя непонятно, как тогда стоило бы поступить.
Во-вторых, в приведенной цитате я бы выделил фразу «It creates the illusion that you can replace one implementation with another». Возникает вопрос: implementation of what? Мне кажется, что речь об интерфейсе IQueryable.
В-третьих, в подтверждение этого есть комментарий к статье с просьбой к Марку оценить интерфейс репозитория над NHibernate:
И вот ответ Марка:
По ссылке на StackOverflow есть пример кода, где IQueriable скрыт за своим интерфейсом, который уже не предоставляет IQueryable.
Только это уже какая-то герменевтика пошла…