И всё-таки остается загадкой: совершенствование процесса в команде — это основная или побочная обязанность тимлида? С одной стороны, команда сама должна вырабатывать «правила игры», но иногда для этого требуется «волшебный пинок».
В некотором смысле универсальную платформу можно сравнить с языком программирования. Всем понятно, что язык должен проектироваться исходя из каких-то глобальных принципов и не поддаваться на провокации отдельных проектов, реализованных на нём. Тут, конечно, всё дело во внутреннем стержне менеджеров или архитекторов универсальной платформы и их прозорливости. Ведь одним из важных принципов является принцип — сохранения обратной совместимости. Даже если надо исправить ошибку в платформе, но если это исправление приведёт к вот этому эффекту у пользователей платформы:
в один прекрасный день Вы в своем проекте обновляете версию платформы до последней и обнаруживаете, что весь проект сломан
Тут надо трижды подумать что делать с этой ошибкой — быть может есть другой вариант решения, а сломать всё — последнее дело. Ещё один полезный принцип — открытость интерфейсов платформы. Если пользователю не подходит что-то из платформы — пусть напишет сам (возможно, хуже, но своё которое ему понятно как устроено).
Повторил. По шагам. Что там внутри происходило при вызове команд — по ощущениям магия какая-то, но с нехитрым бубном оно заработало. Один важный комментарий:
kpm restore
надо вызывать в папке с веб-приложением, которое будет запускаться в веб-сервере.
Пример с Mvc тоже работает (после второго «рестора»). Пока не совсем понял что была за картинка из примера HelloWeb, видимо, что-то зашитое в AspNet. Остро ощущается нехватка Visual Studio что называется «на месте».
Чисто теоретически их можно вынудить вернуть эти списанные средства, т.к. их оферта содержит противоречие относительно того может ли Сервис списывать средства без уведомления (пункт 5.7 это запрещает).
Действительно, оказывается у Мегафона абонентская плата сильно зависит от региона и немного отличается в условиях для разных тарифов. Например, для Перми 30 р., а для Москвы 90р…
Кремниевые батареи действительно весьма плохо сказываются на экологии, но периодически промелькивают статьи про полимерные батареи, которые можно делать в виде слоёного пирога и получать уже сравнимый с кремнием КПД. Надо что-то типа скотча из полимерных солнечных батарей по цене обычного скотча и куча народу ринется обклеивать им доступные крыши.
Второй вариант — это устройства для получения углеводородного топлива из солнечной энергии и атмосферного CO2. С этим пока всё совсем глухо, но мысль о том, что крыша дачного домика мне будет выдавать X литров бензина довольно притягательна.
АЭС и углеводороды кроме прочего, разогревают атмосферу, что тоже можно считать видом загрязнения.
Немного оффтоп, но все же скажу: конец нефтяной трубе может ускорить кардинальное снижение стоимости компонентов солнечной энергетики, в частности, если пластины солнечного кварца будут стоить доли цента. В этом случае Россия будет закупать энергию у экваториальных стран, например качать водород по газопроводам в обратном направлении.
Интересно, могут ли Хабражители каким-нибудь образом ускорить этот процесс? Возможно, уже есть подходящие технологии, но они неизвестны широкой публике и пылятся в столах институтов.
Спасибо за статью. Я когда-то услышал термин «техническое самоубийство», который как раз описывает переход из разряда разработчиков в менеджеры. Сам я уже больше года нахожусь где-то между, но стараюсь не погрязнуть в менеджменте полностью, хотя бы ради команды.
Поддержка распространения технологических сборок через NuGet у нас только в планах.
Привожу ссылку на картинку, поскольку в моём комментарии выше на ней ничего не видно.
Разработчик описывает реализованные фичи во внутренней вики. Ответы на вопросы прикладных программистов также пишем туда. Уровни описания были указаны выше.
Пример статьи (для прикладных программистов):
Тесты у нас пишутся, как правило, после кода. Отдельные разработчики иногда делают наоборот — это не возбраняется. В связи с тем, что часть кода была написана довольно давно и без тестов, при изменении функциональности или исправлении ошибок разработчик добавляет тесты для проверки и того старого кода. Цели взять и покрыть за один раз тестами всё на 100% у нас нет — идём постепенно. Отдельных задач на тестирование не ставится — участники команды достаточно сознательные чтобы писать тесты самостоятельно.
В данный момент соотношение технологов к прикладным разработчикам у нас примерно 1 к 5-6.
Я готов ответить на вопросы (как тут в комментах, так и в личных сообщениях).
По поводу команды: да, Вы правильно понимаете, наша небольшая команда технологов занимается разработкой технологического слоя. Чтобы дать представление о всей компании, приведу пример одной из прикладных систем, разработанных на нашей технологии: web2edu.ru
Увеличение ступеней — это, разумеется, может привести к нехорошим последствиям при определённом стечении обстоятельств. Чтобы этого не происходило вырабатываются определённые механизмы как технического, так и организационного свойства. У нас около 50ти программистов (из них 6 технологов). Если технология развивается и хорошо поддерживается, то ни у одного прикладного программиста не возникнет мысли сделать как-то по-своему в обход общих практик просто потому, что проще и надёжнее взять готовое решение. Появление велосипедов в прикладных проектах говорит о недостаточно качественной работе технологического отдела.
По поводу заглядывания в технологический код. Я лично ничего против этого не имею, но лишь до той степени, когда начинают появляться реплики наподобие «я бы сделал это в 1000 раз лучше». Конструктивная критика и советы всегда принимаются. Тут следует учесть, что ввиду своей универсальной природы и многообразия вариантов, технологический слой довольно сложен. Если прикладной программист начинает тратить время на чтение этого кода, то для компании — это не очень хорошо, поскольку зарплата платится ему за другую работу. Отлаживать технологический код — сравнимо с отладкой кода .NET Framework. Это возможно, но принесёт ли это счастье? Я находил ошибки в .NET, в результате приходилось ставить «костыли» у себя. В случае с технологическим слоем — всегда есть возможность подойти к технологам и попросить их разобраться в ситуации.
И ещё один комментарий по поводу обфускации — не все наши проекты подвергаются этому процессу. Это нужно только при угрозе, что наш прототип будет передан заказчиком третьим лицам на доработку и с нами не будет заключен контракт.
Экономическую выгоду посчитать очень тяжело, поскольку все проекты уникальны и для честной оценки надо делать 2 похожих проекта с применением нашего фреймворка и без. Для конкретного проекта можно примерно оценить стоимость работ «с нуля» и вычесть реальную стоимость. По моим оценкам один из проектов стоил дешевле примерно на 30% благодаря технологии. Для типичных проектов этот процент больше, а для проектов в которых количество специфичных решений весьма велико, разумеется, процент выигрыша будет небольшим. Наиболее важный аспект как для заказчика, так и для нас — это возможность за 2-3 недели подготовить работающий прототип приложения и продемонстрировать его, а также гарантировать качество работ, поскольку основные компоненты были проверены в других внедрённых проектах. Что же касается лицензирования и ценообразования — технология позволяет делать уступки клиентам, если иначе договориться не получается.
Пять лет прошло. Ну как? Получилось?
надо вызывать в папке с веб-приложением, которое будет запускаться в веб-сервере.
Пример с Mvc тоже работает (после второго «рестора»). Пока не совсем понял что была за картинка из примера HelloWeb, видимо, что-то зашитое в AspNet. Остро ощущается нехватка Visual Studio что называется «на месте».
Второй вариант — это устройства для получения углеводородного топлива из солнечной энергии и атмосферного CO2. С этим пока всё совсем глухо, но мысль о том, что крыша дачного домика мне будет выдавать X литров бензина довольно притягательна.
АЭС и углеводороды кроме прочего, разогревают атмосферу, что тоже можно считать видом загрязнения.
Интересно, могут ли Хабражители каким-нибудь образом ускорить этот процесс? Возможно, уже есть подходящие технологии, но они неизвестны широкой публике и пылятся в столах институтов.
code.msdn.microsoft.com/101-LINQ-Samples-3fb9811b
Привожу ссылку на картинку, поскольку в моём комментарии выше на ней ничего не видно.
Пример статьи (для прикладных программистов):
Тесты у нас пишутся, как правило, после кода. Отдельные разработчики иногда делают наоборот — это не возбраняется. В связи с тем, что часть кода была написана довольно давно и без тестов, при изменении функциональности или исправлении ошибок разработчик добавляет тесты для проверки и того старого кода. Цели взять и покрыть за один раз тестами всё на 100% у нас нет — идём постепенно. Отдельных задач на тестирование не ставится — участники команды достаточно сознательные чтобы писать тесты самостоятельно.
В данный момент соотношение технологов к прикладным разработчикам у нас примерно 1 к 5-6.
По поводу команды: да, Вы правильно понимаете, наша небольшая команда технологов занимается разработкой технологического слоя. Чтобы дать представление о всей компании, приведу пример одной из прикладных систем, разработанных на нашей технологии: web2edu.ru
По поводу заглядывания в технологический код. Я лично ничего против этого не имею, но лишь до той степени, когда начинают появляться реплики наподобие «я бы сделал это в 1000 раз лучше». Конструктивная критика и советы всегда принимаются. Тут следует учесть, что ввиду своей универсальной природы и многообразия вариантов, технологический слой довольно сложен. Если прикладной программист начинает тратить время на чтение этого кода, то для компании — это не очень хорошо, поскольку зарплата платится ему за другую работу. Отлаживать технологический код — сравнимо с отладкой кода .NET Framework. Это возможно, но принесёт ли это счастье? Я находил ошибки в .NET, в результате приходилось ставить «костыли» у себя. В случае с технологическим слоем — всегда есть возможность подойти к технологам и попросить их разобраться в ситуации.
И ещё один комментарий по поводу обфускации — не все наши проекты подвергаются этому процессу. Это нужно только при угрозе, что наш прототип будет передан заказчиком третьим лицам на доработку и с нами не будет заключен контракт.