Проект по ссылке просто умеет менять цвет темы в Win10, дергая правильный API из uxtheme.dll.
Я втащил это решение в Kilo и у меня, в принципе, заработало. Теперь надо сделать аккуратный выбор цветов, все проверить и собрать инсталлятор. Так что скоро всё будет. Я сам страдаю :)
Еще из хорошего — в десятке можно настроить цветовую схему так, что меняться будет фон на экране разблокировки. Этого нельзя было добиться в семерке/восьмерке.
Молодцы, что выложили на GitHub, приятно, что появляется такой контент. За это респект.
Но вот только эта тема — совсем не админка. Не интерфес для работы с большими таблицами, ввода данных, подгрузки файлов и другой повседневной работы.
У вас получился отличный задел по dashboard для руководителя. В таком виде тема будет органично смотреться на экране директорского айпада. Только потребление агрегированной информации: график чего-нибудь, карточка с условиями договора и сводкой по работе по нему, контроль выполнения задач. Из ввода данных — логин/пароль, ответ на сообщение, согласование и комментарии, да может быть постановка или переадресация задачи. Для этих целей у вас есть неплохой подбор компонентов (графики, таймлайны, списки сообщений, счетчики, дерево документов), но есть над чем поработать.
Например, впилить диаграмму Ганта, удобный кастомизатор таблицы (сортировка, фильтр по колонке, добавление и сокрытие колонок), более информативные пункты таймлайна для компактного представления информации, и так далее. Лучше всего и правда плясать от реальных сценариев пользователей.
А для админки как удобного интерфейса для ввода структурированных данных у вас вообще ничего нет, по правде говоря. Например, ну какая «админка» без удобного выбора одного или нескольких объектов из списка с возможностью добавить «на лету» недостающее? И без готового стилизованного контрола для аплоада файлов. Тут можно долго продолжать. Если вам интересно, могу составить прямо список необходимых компонентов с подробным описанием :)
В указанном вами пункте в третьим предложении написано именно, что «изговнокодит весь проект». Просто употреблять слово «говно» больше трех раз в статье, претендующей на серьезное изложение — это уже перебор :)
Описанные крайние случаи иногда вполне себе встречаются, по крайней мере, я все четыре случая видел лично. Но вы правы в том, что обычно обходится без крайностей.
Ну а что касается очевидности… К сожалению, для людей, которые эти учебники не читали (а я несколько раз прямо в руки такой учебник выдавал, только на их прочтение всегда не хватало времени) — советы не такие уж очевидные, и часто противоречат накопленному опыту подбора людей и организации их работы.
Да, так и есть. Статья для людей, которые пришли в IT делать бизнес и со всеми особенностями отрасли не знакомы. ДеМарко я тоже настойчиво рекомендовал к прочтению, вместе с Бруксом. Даже в свое время хотел купить десяток Peopleware в мягкой обложке и раздавать в подарок, но они тогда пропали из магазинов почему-то :)
Описание моего позитивного опыта построения команды не решит задачи, которая стоит перед статьей. Это как раз будет еще одна плюха в терриконах шлака, которая никому не интересна :)
Обсуждаемая статья написана, как коммерческое предложение — на определенную целевую аудиторию. Для тех самых людей с деньгам, идеей, но без опыта в IT. Она построена по схеме pain-power-vision-бла-бла-бла и написана так, чтобы нужный человек сперва узнал себя и свою ситуацию, потом примерил на себя риски, которые там перечислены, и уже тогда стал читать про решения.
В том случае, когда мне удалось собрать и поддерживать крутую команду, мне как раз удалось донести до основателей правильный подход. В других случаях не не брался за эту работу. Мой опыт донесения таких мыслей и собран в этой статье :)
У меня и у нескольких рецензентов этой статьи ушло довольно много времени на то, чтобы ее подготовить. А люблю писать код и очень не люблю писать тексты. Поэтому мне ооочень не хочется писать вторую часть, где я обещал описать организацию работы команды.
Буду очень признателен, если вы припомните среди этого шлака и подкинете мне хорошую практическую статью в формате риск — как сделать правило/неправильно — цена ошибки. Я тогда дам ссылку на нее вместо обещанного продолжения.
Что же касается опыта, то у меня есть опыт создания только одной маленькой dream team, которая 1.5 года в отличном темпе выдавала качественный продукт, а потом в одночасье прекратила существовать из-за нескольких описанных в этой статье ошибок.
А после майских праздников в этом году попросту выключился, бросив на произвол судьбы своих пользователей, и продукт, который мы делали. Это тоже результат описанных выше ошибок и один из основных поводов к написанию статьи.
Представьте себе человека, который состоялся и заработал деньги, скажем, в ресторанном бизнесе. А там заметно другие подходы к подбору и мотивации персонала. Это тоже сложная задача (поэтому рестораны так различаются по качеству обслуживания) и он умеет ее решать.
А теперь у этого человека есть идея сделать программный продукт. Только он не просто не читал этих учебников, он совершенно уверен, что ему их читать не нужно, он же умеет управлять персоналом! И вот он нанимает команду, вкладывает деньги, забирает с рынка специалистов и… всё это тратится с нулевым выхлопом. В процессе страдает основатель, страдает команда.
Цель, которую я ставил перед собой — не открыть миру новое знание, а изложить самые базовые моменты так, чтобы они были понятны человеку без опыта в индустрии, и при этом не вызывали совсем уж яростной критики тех, кто в теме.
Упоминаемый в статье Брукс актуален уже несколько десятилетий. Но почему-то каждый год я вижу новые и новые повторения одних тех же ошибок со все теми же печальными последствиями. Ну не читали люди, у которых есть идея и деньги, но которые раньше к разработке не имели отношения, ни Деминга, ни Брукса.
Весь смысл этой длинной статьи в том, чтобы на абсолютно реальных и довольно болезненных примерах обратить внимание то, что к работе с командой нужно подходить ответственно. И теорию — изучать.
Последнее утверждение неверно. Ключевым (и уникальным) свойством урана является не пирофорность (это уже «заброневой» эффект), а особые физические свойства материала в момент пробития. Хорошо описано в этой статье в «Популярной механике», например.
Елена, сервис классный, каждому B2B сервису, где работа с контрагентами важна, стоило бы его заинтегрировать для удобства пользователей. Но вот он у вас, кажется, уже больше года в бете, это грустно.
Я втащил это решение в Kilo и у меня, в принципе, заработало. Теперь надо сделать аккуратный выбор цветов, все проверить и собрать инсталлятор. Так что скоро всё будет. Я сам страдаю :)
Еще из хорошего — в десятке можно настроить цветовую схему так, что меняться будет фон на экране разблокировки. Этого нельзя было добиться в семерке/восьмерке.
Без подсветки дичайше неудобно, так что уже озадачился тем, как менять цвета в новом интерфейсе.
С другой стороны, я провожу все больше времени в Убунте. Но пока все равно для работы нужна винда, так что придется разобраться.
Но вот только эта тема — совсем не админка. Не интерфес для работы с большими таблицами, ввода данных, подгрузки файлов и другой повседневной работы.
У вас получился отличный задел по dashboard для руководителя. В таком виде тема будет органично смотреться на экране директорского айпада. Только потребление агрегированной информации: график чего-нибудь, карточка с условиями договора и сводкой по работе по нему, контроль выполнения задач. Из ввода данных — логин/пароль, ответ на сообщение, согласование и комментарии, да может быть постановка или переадресация задачи. Для этих целей у вас есть неплохой подбор компонентов (графики, таймлайны, списки сообщений, счетчики, дерево документов), но есть над чем поработать.
Например, впилить диаграмму Ганта, удобный кастомизатор таблицы (сортировка, фильтр по колонке, добавление и сокрытие колонок), более информативные пункты таймлайна для компактного представления информации, и так далее. Лучше всего и правда плясать от реальных сценариев пользователей.
А для админки как удобного интерфейса для ввода структурированных данных у вас вообще ничего нет, по правде говоря. Например, ну какая «админка» без удобного выбора одного или нескольких объектов из списка с возможностью добавить «на лету» недостающее? И без готового стилизованного контрола для аплоада файлов. Тут можно долго продолжать. Если вам интересно, могу составить прямо список необходимых компонентов с подробным описанием :)
МегамозгХабр)Описанные крайние случаи иногда вполне себе встречаются, по крайней мере, я все четыре случая видел лично. Но вы правы в том, что обычно обходится без крайностей.
Ну а что касается очевидности… К сожалению, для людей, которые эти учебники не читали (а я несколько раз прямо в руки такой учебник выдавал, только на их прочтение всегда не хватало времени) — советы не такие уж очевидные, и часто противоречат накопленному опыту подбора людей и организации их работы.
Обсуждаемая статья написана, как коммерческое предложение — на определенную целевую аудиторию. Для тех самых людей с деньгам, идеей, но без опыта в IT. Она построена по схеме pain-power-vision-бла-бла-бла и написана так, чтобы нужный человек сперва узнал себя и свою ситуацию, потом примерил на себя риски, которые там перечислены, и уже тогда стал читать про решения.
В том случае, когда мне удалось собрать и поддерживать крутую команду, мне как раз удалось донести до основателей правильный подход. В других случаях не не брался за эту работу. Мой опыт донесения таких мыслей и собран в этой статье :)
Буду очень признателен, если вы припомните среди этого шлака и подкинете мне хорошую практическую статью в формате риск — как сделать правило/неправильно — цена ошибки. Я тогда дам ссылку на нее вместо обещанного продолжения.
Что же касается опыта, то у меня есть опыт создания только одной маленькой dream team, которая 1.5 года в отличном темпе выдавала качественный продукт, а потом в одночасье прекратила существовать из-за нескольких описанных в этой статье ошибок.
А после майских праздников в этом году попросту выключился, бросив на произвол судьбы своих пользователей, и продукт, который мы делали. Это тоже результат описанных выше ошибок и один из основных поводов к написанию статьи.
А теперь у этого человека есть идея сделать программный продукт. Только он не просто не читал этих учебников, он совершенно уверен, что ему их читать не нужно, он же умеет управлять персоналом! И вот он нанимает команду, вкладывает деньги, забирает с рынка специалистов и… всё это тратится с нулевым выхлопом. В процессе страдает основатель, страдает команда.
Цель, которую я ставил перед собой — не открыть миру новое знание, а изложить самые базовые моменты так, чтобы они были понятны человеку без опыта в индустрии, и при этом не вызывали совсем уж яростной критики тех, кто в теме.
Весь смысл этой длинной статьи в том, чтобы на абсолютно реальных и довольно болезненных примерах обратить внимание то, что к работе с командой нужно подходить ответственно. И теорию — изучать.
Постараюсь в длинные выходные раскурить дестяку, но на 100% обещать не могу! :)
А инструкция по интеграции вот тут: www.nalog.ru/rn66/service/egrip2/egrip_vzayim