Яндекс.Браузер отправляет в Яндекс историю посещенных пользователем страниц с привязкой к какому-нибудь идентификатору, который потом позволяет таргетировать на этого пользователя релевантную рекламу?
Насколько мне известно, только на государственную экспертизу проектная документация сдается в цифровом виде с электронной подписью. С 1 января этого года — в обязательном порядке. А во всех остальных местах — бумага.
А еще есть исполнительная документация, в не меньших объемах. И все эти безумные объемы до сих пор проверяются, сдаются и хранятся в бумажном виде, а не в цифровом, подписанные ЭЦП %)
И еще маленькое замечание для moikrug по юзабилити: так сложилось, что со времен еще того Моего круга он есть у меня в закладках и я периодически случайно туда перехожу. И вижу какой-то большой пустой экран и строку для ввода непонятно чего. Абсолютно никакой интересной информации, глаз не цепляется за контент, взаимодействия не происходит и я с недоумением закрываю вкладку.
Если бы вы вытащили аппетитные вакансии или любой другой читабельный контент на самый верх, кажется, у вас было бы больше взаимодействия с посетителями, которые не ищут работу или сотрудников, но не удержались бы и посмотрели, что происходит на рынке.
В начале статьи указано, что вы опросили более 3500 человек. А раскройте тогда еще, сколько человек заполнило анкету, а сколько проигнорировало. Без этой информации сложно сделать обоснованные выводы из результатов опроса. Скорее всего, большая часть проигнорировавших как раз не имела никакого опыта взаимодействия со стартапами.
И просто забавный факт: предложение поучаствовать в опросе как пользователю МойКруг упало мне в почту примерно через неделю после того, как я попросил удалить мой аккаунт за ненадобностью и получил подтверждение его удаления :)
Да, при наследовании реализации необходимо опираться на детали реализации базового класса. Да, изменение этих деталей, очевидно, будет ломающим для наследника. Но это почти всегда не проблема на фоне возможности перезагрузить один единственный нужный метод.
Ваша проблема в том, что вы, когда рассуждаете, фантазируете о подключаемом в виде бинарных зависимостей расширяемом фреймворке, которым пользуются миллионы.
В 99% случаев это совсем не так. Почти всегда вся иерархия наследования создается и поддерживается одной командой, а то и одним человеком. В любой момент можно не только подсмотреть детали реализации в базовом классе, но и исправить возникающие по мере развития проблемы. Логика базовых классов и наследников изменяется за один заход одним человеком, поэтому никакой хрупкости там нет.
Ваша озабоченность оправдана в 1% случаев: разработчикам фреймворков и популярных библиотек следует задумываться над тем, о чем вы говорите. Они не могут поменять свои контракты без нарушения работоспособности клиентского кода. В этом случае выставлять наружу точки расширения в виде интерфейсов, которые пользователь может полностью реализовать сам, не заглядывая в омут чужого кода — это, безусловно, отличное решение. И повсеместное проникновение DI поддерживает этот подход.
Но призывать отказываться от наследования реализации в одноразовых SaaSах и in-house проектах, которые обречены тихо гнить внутри какого-нибудь банка — это глупый максимализм.
Для того, чтобы правильно реализовать такого наследника (представим себе, что нам это действительно необходимо), нужно знать, как работают эти методы в классе-предке (например, не использует ли в базовом классе AddRange() вызов Add()). От этого зависит реализация наследника. Это нормально.
Из существование модификатора доступа private следует возможность скрывать члены базового класса от наследников. Но никак не следует необходимость это делать.
Корректная реализация перекрытых методов требует знания деталей реализации базового класса и часто доступа к членам базового класса (для чего и существует модификатор protected). Это нормально, потому что не раскрывает детали реализации и данные вовне иерархии наследования.
У автора некорректна сформулирована исходная проблема:
1. Наследование реализации может нарушать инкапсуляцию, но не обязывает это делать. Более того, инкапсуляция в практическом ключе — это сокрытие реализации от пользователей класса (или его наследников), а не от самих наследников.
2. Принцип Лисков ни в коем случае не обязывает класс-потомок удовлетворять всем требованиям к классу-предку. Он вообще не обязывает, а только лишь рекомендует. SOLID — это что-то вроде христианских заповедей, которые вроде бы надо выполнять, но не так уж и обязательно. И не факт, что от выполнения будет лучше. И за реализацию этих принципов нужно достаточно дорого заплатить, что в реальной жизни часто совершенно не оправдано. И далеко не всегда реализация принципа Лисков требует знания о реально используемом наследнике. В большинстве случаев это получается само и бесплатно.
Итого, автор усмотрел в устоявшейся концепции ООП потенциальную проблему, которая иногда возникает, и на всякий случай предлагает всем навсегда запретить пользоваться удобным механизмом наследования реализации, выжечь этот механизм каленым железом из языка. Чем демонстрирует изрядную долю теоретико-фанатизма.
Практичные же люди, когда видят практическую проблему наследования реализации, берут и прибегают к зависимостям от абстрактных интерфейсов :)
Проект по ссылке просто умеет менять цвет темы в Win10, дергая правильный API из uxtheme.dll.
Я втащил это решение в Kilo и у меня, в принципе, заработало. Теперь надо сделать аккуратный выбор цветов, все проверить и собрать инсталлятор. Так что скоро всё будет. Я сам страдаю :)
Еще из хорошего — в десятке можно настроить цветовую схему так, что меняться будет фон на экране разблокировки. Этого нельзя было добиться в семерке/восьмерке.
Молодцы, что выложили на GitHub, приятно, что появляется такой контент. За это респект.
Но вот только эта тема — совсем не админка. Не интерфес для работы с большими таблицами, ввода данных, подгрузки файлов и другой повседневной работы.
У вас получился отличный задел по dashboard для руководителя. В таком виде тема будет органично смотреться на экране директорского айпада. Только потребление агрегированной информации: график чего-нибудь, карточка с условиями договора и сводкой по работе по нему, контроль выполнения задач. Из ввода данных — логин/пароль, ответ на сообщение, согласование и комментарии, да может быть постановка или переадресация задачи. Для этих целей у вас есть неплохой подбор компонентов (графики, таймлайны, списки сообщений, счетчики, дерево документов), но есть над чем поработать.
Например, впилить диаграмму Ганта, удобный кастомизатор таблицы (сортировка, фильтр по колонке, добавление и сокрытие колонок), более информативные пункты таймлайна для компактного представления информации, и так далее. Лучше всего и правда плясать от реальных сценариев пользователей.
А для админки как удобного интерфейса для ввода структурированных данных у вас вообще ничего нет, по правде говоря. Например, ну какая «админка» без удобного выбора одного или нескольких объектов из списка с возможностью добавить «на лету» недостающее? И без готового стилизованного контрола для аплоада файлов. Тут можно долго продолжать. Если вам интересно, могу составить прямо список необходимых компонентов с подробным описанием :)
В указанном вами пункте в третьим предложении написано именно, что «изговнокодит весь проект». Просто употреблять слово «говно» больше трех раз в статье, претендующей на серьезное изложение — это уже перебор :)
Описанные крайние случаи иногда вполне себе встречаются, по крайней мере, я все четыре случая видел лично. Но вы правы в том, что обычно обходится без крайностей.
Ну а что касается очевидности… К сожалению, для людей, которые эти учебники не читали (а я несколько раз прямо в руки такой учебник выдавал, только на их прочтение всегда не хватало времени) — советы не такие уж очевидные, и часто противоречат накопленному опыту подбора людей и организации их работы.
Да, так и есть. Статья для людей, которые пришли в IT делать бизнес и со всеми особенностями отрасли не знакомы. ДеМарко я тоже настойчиво рекомендовал к прочтению, вместе с Бруксом. Даже в свое время хотел купить десяток Peopleware в мягкой обложке и раздавать в подарок, но они тогда пропали из магазинов почему-то :)
Описание моего позитивного опыта построения команды не решит задачи, которая стоит перед статьей. Это как раз будет еще одна плюха в терриконах шлака, которая никому не интересна :)
Обсуждаемая статья написана, как коммерческое предложение — на определенную целевую аудиторию. Для тех самых людей с деньгам, идеей, но без опыта в IT. Она построена по схеме pain-power-vision-бла-бла-бла и написана так, чтобы нужный человек сперва узнал себя и свою ситуацию, потом примерил на себя риски, которые там перечислены, и уже тогда стал читать про решения.
В том случае, когда мне удалось собрать и поддерживать крутую команду, мне как раз удалось донести до основателей правильный подход. В других случаях не не брался за эту работу. Мой опыт донесения таких мыслей и собран в этой статье :)
Если бы вы вытащили аппетитные вакансии или любой другой читабельный контент на самый верх, кажется, у вас было бы больше взаимодействия с посетителями, которые не ищут работу или сотрудников, но не удержались бы и посмотрели, что происходит на рынке.
И просто забавный факт: предложение поучаствовать в опросе как пользователю МойКруг упало мне в почту примерно через неделю после того, как я попросил удалить мой аккаунт за ненадобностью и получил подтверждение его удаления :)
Ваша проблема в том, что вы, когда рассуждаете, фантазируете о подключаемом в виде бинарных зависимостей расширяемом фреймворке, которым пользуются миллионы.
В 99% случаев это совсем не так. Почти всегда вся иерархия наследования создается и поддерживается одной командой, а то и одним человеком. В любой момент можно не только подсмотреть детали реализации в базовом классе, но и исправить возникающие по мере развития проблемы. Логика базовых классов и наследников изменяется за один заход одним человеком, поэтому никакой хрупкости там нет.
Ваша озабоченность оправдана в 1% случаев: разработчикам фреймворков и популярных библиотек следует задумываться над тем, о чем вы говорите. Они не могут поменять свои контракты без нарушения работоспособности клиентского кода. В этом случае выставлять наружу точки расширения в виде интерфейсов, которые пользователь может полностью реализовать сам, не заглядывая в омут чужого кода — это, безусловно, отличное решение. И повсеместное проникновение DI поддерживает этот подход.
Но призывать отказываться от наследования реализации в одноразовых SaaSах и in-house проектах, которые обречены тихо гнить внутри какого-нибудь банка — это глупый максимализм.
Из существование модификатора доступа private следует возможность скрывать члены базового класса от наследников. Но никак не следует необходимость это делать.
Корректная реализация перекрытых методов требует знания деталей реализации базового класса и часто доступа к членам базового класса (для чего и существует модификатор protected). Это нормально, потому что не раскрывает детали реализации и данные вовне иерархии наследования.
Собственно, откуда вы вообще взяли, что от класса-наследника надо скрывать детали реализации или лишать его доступа к данным?
1. Наследование реализации может нарушать инкапсуляцию, но не обязывает это делать. Более того, инкапсуляция в практическом ключе — это сокрытие реализации от пользователей класса (или его наследников), а не от самих наследников.
2. Принцип Лисков ни в коем случае не обязывает класс-потомок удовлетворять всем требованиям к классу-предку. Он вообще не обязывает, а только лишь рекомендует. SOLID — это что-то вроде христианских заповедей, которые вроде бы надо выполнять, но не так уж и обязательно. И не факт, что от выполнения будет лучше. И за реализацию этих принципов нужно достаточно дорого заплатить, что в реальной жизни часто совершенно не оправдано. И далеко не всегда реализация принципа Лисков требует знания о реально используемом наследнике. В большинстве случаев это получается само и бесплатно.
Итого, автор усмотрел в устоявшейся концепции ООП потенциальную проблему, которая иногда возникает, и на всякий случай предлагает всем навсегда запретить пользоваться удобным механизмом наследования реализации, выжечь этот механизм каленым железом из языка. Чем демонстрирует изрядную долю теоретико-фанатизма.
Практичные же люди, когда видят практическую проблему наследования реализации, берут и прибегают к зависимостям от абстрактных интерфейсов :)
Я втащил это решение в Kilo и у меня, в принципе, заработало. Теперь надо сделать аккуратный выбор цветов, все проверить и собрать инсталлятор. Так что скоро всё будет. Я сам страдаю :)
Еще из хорошего — в десятке можно настроить цветовую схему так, что меняться будет фон на экране разблокировки. Этого нельзя было добиться в семерке/восьмерке.
Без подсветки дичайше неудобно, так что уже озадачился тем, как менять цвета в новом интерфейсе.
С другой стороны, я провожу все больше времени в Убунте. Но пока все равно для работы нужна винда, так что придется разобраться.
Но вот только эта тема — совсем не админка. Не интерфес для работы с большими таблицами, ввода данных, подгрузки файлов и другой повседневной работы.
У вас получился отличный задел по dashboard для руководителя. В таком виде тема будет органично смотреться на экране директорского айпада. Только потребление агрегированной информации: график чего-нибудь, карточка с условиями договора и сводкой по работе по нему, контроль выполнения задач. Из ввода данных — логин/пароль, ответ на сообщение, согласование и комментарии, да может быть постановка или переадресация задачи. Для этих целей у вас есть неплохой подбор компонентов (графики, таймлайны, списки сообщений, счетчики, дерево документов), но есть над чем поработать.
Например, впилить диаграмму Ганта, удобный кастомизатор таблицы (сортировка, фильтр по колонке, добавление и сокрытие колонок), более информативные пункты таймлайна для компактного представления информации, и так далее. Лучше всего и правда плясать от реальных сценариев пользователей.
А для админки как удобного интерфейса для ввода структурированных данных у вас вообще ничего нет, по правде говоря. Например, ну какая «админка» без удобного выбора одного или нескольких объектов из списка с возможностью добавить «на лету» недостающее? И без готового стилизованного контрола для аплоада файлов. Тут можно долго продолжать. Если вам интересно, могу составить прямо список необходимых компонентов с подробным описанием :)
МегамозгХабр)Описанные крайние случаи иногда вполне себе встречаются, по крайней мере, я все четыре случая видел лично. Но вы правы в том, что обычно обходится без крайностей.
Ну а что касается очевидности… К сожалению, для людей, которые эти учебники не читали (а я несколько раз прямо в руки такой учебник выдавал, только на их прочтение всегда не хватало времени) — советы не такие уж очевидные, и часто противоречат накопленному опыту подбора людей и организации их работы.
Обсуждаемая статья написана, как коммерческое предложение — на определенную целевую аудиторию. Для тех самых людей с деньгам, идеей, но без опыта в IT. Она построена по схеме pain-power-vision-бла-бла-бла и написана так, чтобы нужный человек сперва узнал себя и свою ситуацию, потом примерил на себя риски, которые там перечислены, и уже тогда стал читать про решения.
В том случае, когда мне удалось собрать и поддерживать крутую команду, мне как раз удалось донести до основателей правильный подход. В других случаях не не брался за эту работу. Мой опыт донесения таких мыслей и собран в этой статье :)