как вы думаете, откуда он берет все эти suggestions, да еще так в точку попадает? а сегодня так вообще во время обращения к интранет-ресурсам заметил ничем не прикрытые хиты на гугланалитикс.
идея, несомненно интересная, ровно как и возможность запуска Windows 95 на iPhone.
но! существует великое множество реальных проблем разных степеней сложности — те же самые алгоритмы динамической маршрутизации и проблемы безопасности с ними связанные, или, скажем, новый виток проблем анонимности в сети интернет, а вы зачем-то взяли надуманную… в лучшем случае вы получите массу интересной информации в контексте кросс-платформенной разработки под мобильные платформы и сетевого программирования в условиях низкой надежности сетевых соединений, т. е. полезность побочных продуктов вашей работы превысит полезность результата в ближайшем обозримом будущем… а за пределами ближайшего обозримого будущего ваши приложения, скорее всего, станут бесполезными в виду эволюции этих самых мобильных платформ или переходу к fully-virtualized-решениям.
у .net приложений не более чем у обычных приложений. а именно — установка на компьютер.
вот я, например, собираюсь заключать договор аренды. ищу в поисковике «договор аренды» и он мне выдает пару типовых договоров и ваш сайт. в том виде, в котором это у вас сейчас сделано — я вобъю нужные данные и тут же получу договор, останусь вполне довольным (ну, разве что, может по поводу паспортных данных попереживаю). если мне предложат что-то скачать — я возьму типовой договор и поправлю сам — мне нужен договор, а не ваша программа. т. е. делая приложение вы отсекаете таких вот как я пользователей, а их будет больше, чем тех, кто будет пользоваться вашим сервисом постоянно — так как они, скорее всего, уже используют встроенные макросы MS Word или еще что-то типа того.
пожалуйста, обратите ваше внимание на критику текущей реализации, она откровенно слабая. я сам раньше занимался фрилансом и какое-то время держал небольшой стартап и с трудом в голове укладывается, что это может быть результатом действительно долгой и серьезной работы. принципы реализации продукта — будь то .net, python или скрипт на шелле (а такие задачи я именно на нем и решаю, кстати) — не так важны, как суть дела. ваше главное и основное — пользователь, которому нужен договор. и ему будет абсолютно плевать на всевозможные визуальные эффекты и технологии, благодаря которым он его получает. процесс должен быть просто комфортным, не более.
идея, на мой взгляд, очень неплохая. и хорошо, что в виде вебсервиса. начал читать статью — подумал, будет .net приложение — в таком виде обречено было бы на провал.
реализация — совсем слабая, учитывая достаточно малый объем работы. я может быть что-то не понимаю, но эта штука должна сгенерить документ в .rtf подставив вместо placeholder'ов введенные данные? но это же пару вечеров не сильно напряженной работы.
мораль: вам надо как-то пересмотреть свое отношение либо к ТЗ, либо к исполнителям, либо к менеджменту в целом. на вашем месте я бы почитал на эту тему мудрых книжек.
хм, вы бы указали, что речь именно о цифровой схемотехнике, иначе вся статья получается логически неверная :) да и начинать пожалуй с булевой алгебры, а не с ТА, хотя, тут уже можно поспорить…
буду искренне благодарен примерам. как минимум одна бумага будет всегда — набор исходных требований (техзадание, бизнес-требования, спецификация и так далее). и их бывает очень много или они бывают довольно большими. а иногда еще и загадочными.
из практики:
1.) тестовый стенд. приближен к «боевым условиям» — то есть, интерфейс взаимодействия крайне ограничен. можно инсталлировать приложение, можно передать набор конфигураций через специальный интерфейс, ничего другого — нельзя, ибо при выходе в production не факт что нам дадут хотя бы это. да, можно подцепиться отладчиком, посмотреть логи, сделать рестарт и очистку кэшей, разумеется, все, остальное только read-only.
2.) приведенный выше пример следовать заданной степени test coverage, комментировать коммиты и осмысленно закрывать таски (да, иногда требуется немного больше, чем поставить статус FIXED) — что-то вытекает из внешних требований, что-то из внутренней организации процесса.
3.) из-за жестких требований иметь на все исходный код и передавать в качестве релиза исходный код всего, кроме ряда исключений, опять таки — суровые ограничения на использование инструментов (билд система, кое-что даже на ide завязано) и общих/внешних компонент и библиотек.
отзывы, соответственно:
1.) а мы сделали по-своему и у нас работает
2.) нам это не удобно и мы так не хотим/не будем
3.) что за бред?
и, пожалуй, я все три реакции понимаю, особенно последнюю, так как она вступает в противоречие с некоторыми исходными требованиями и некоторыми best practice, ровно как и со здравым смыслом (на первый взгляд)
вопрос — как сделать не прибегая к жестким мерам и регламентации процессов? из третьего, например, следует, что перед тем как брать какой-либо внешний компонент, надо заапрувить это решение (благо, делается без бумаг и довольно быстро — полуавтоматически, но некоторая бюрократия присутствует).
на аналогичном проекте сделали по принципу «ничего не должно мешать разработке». теперь ни выйти в production не получается, ни с соседями интегрироваться.
вот как бы объяснить, что многие странные для разработчика требования — на самом деле банальная жизненная необходимость. что-то требует кастомер, без чего-то будут проблемы при интегрэйшине, где-то дефицит ресурсов а что-то банально неприоритетно или невозможно, а бывает еще так, что есть действительно абсолютно бредовое требование или процесс, но по каким-то независимым причинам приходится ему следовать, ибо менять его выйдет дороже.
а еще бывает «документацию прочитал по диагонали, почту не читаю, но вчера у меня все работало!», «а у меня на машине работает, это у вас неправильный сервер!» и «а нафига нам эти тесты и coding style checking?» или «а мне неудобно писать комментарии к коммитам!», и хоть трава не расти!
дочтаточно давно я работаю «по ту сторону» разработки ПО и очень обидно сталкваться с подобным непониманием.
да, бумага на создание VM — это просто ужасно (сейчас сам в похожем положении), но стандарт на именование и структуру директорий в svn — на многих проектах весьма полезен, так же, как и соглашения по именованию переменных, так же, как и общий процесс для перехода в QA и еще многие вещи. после определенного баръера человеко-часов без этой бюрократии проект может просто развалиться под собственным весом.
мозилла файрфокс был в зачаточном состоянии, а сама мозилла (не помню как она называлась тогда) была достаточно неповоротливой, лучше уж сразу было нетскейп ставить. опера же тогда очень хорошо подходила под потребности «влезть» в модемное соединение. в ней, помнится, даже докачка работала.
но! существует великое множество реальных проблем разных степеней сложности — те же самые алгоритмы динамической маршрутизации и проблемы безопасности с ними связанные, или, скажем, новый виток проблем анонимности в сети интернет, а вы зачем-то взяли надуманную… в лучшем случае вы получите массу интересной информации в контексте кросс-платформенной разработки под мобильные платформы и сетевого программирования в условиях низкой надежности сетевых соединений, т. е. полезность побочных продуктов вашей работы превысит полезность результата в ближайшем обозримом будущем… а за пределами ближайшего обозримого будущего ваши приложения, скорее всего, станут бесполезными в виду эволюции этих самых мобильных платформ или переходу к fully-virtualized-решениям.
я все же думаю, что батарейки там с хорошим запасом, надо ведь еще что-то с тучками делать и дождливыми деньками.
вот я, например, собираюсь заключать договор аренды. ищу в поисковике «договор аренды» и он мне выдает пару типовых договоров и ваш сайт. в том виде, в котором это у вас сейчас сделано — я вобъю нужные данные и тут же получу договор, останусь вполне довольным (ну, разве что, может по поводу паспортных данных попереживаю). если мне предложат что-то скачать — я возьму типовой договор и поправлю сам — мне нужен договор, а не ваша программа. т. е. делая приложение вы отсекаете таких вот как я пользователей, а их будет больше, чем тех, кто будет пользоваться вашим сервисом постоянно — так как они, скорее всего, уже используют встроенные макросы MS Word или еще что-то типа того.
пожалуйста, обратите ваше внимание на критику текущей реализации, она откровенно слабая. я сам раньше занимался фрилансом и какое-то время держал небольшой стартап и с трудом в голове укладывается, что это может быть результатом действительно долгой и серьезной работы. принципы реализации продукта — будь то .net, python или скрипт на шелле (а такие задачи я именно на нем и решаю, кстати) — не так важны, как суть дела. ваше главное и основное — пользователь, которому нужен договор. и ему будет абсолютно плевать на всевозможные визуальные эффекты и технологии, благодаря которым он его получает. процесс должен быть просто комфортным, не более.
реализация — совсем слабая, учитывая достаточно малый объем работы. я может быть что-то не понимаю, но эта штука должна сгенерить документ в .rtf подставив вместо placeholder'ов введенные данные? но это же пару вечеров не сильно напряженной работы.
мораль: вам надо как-то пересмотреть свое отношение либо к ТЗ, либо к исполнителям, либо к менеджменту в целом. на вашем месте я бы почитал на эту тему мудрых книжек.
и на хабре вы, ну очень рано выложили это.
из практики:
1.) тестовый стенд. приближен к «боевым условиям» — то есть, интерфейс взаимодействия крайне ограничен. можно инсталлировать приложение, можно передать набор конфигураций через специальный интерфейс, ничего другого — нельзя, ибо при выходе в production не факт что нам дадут хотя бы это. да, можно подцепиться отладчиком, посмотреть логи, сделать рестарт и очистку кэшей, разумеется, все, остальное только read-only.
2.) приведенный выше пример следовать заданной степени test coverage, комментировать коммиты и осмысленно закрывать таски (да, иногда требуется немного больше, чем поставить статус FIXED) — что-то вытекает из внешних требований, что-то из внутренней организации процесса.
3.) из-за жестких требований иметь на все исходный код и передавать в качестве релиза исходный код всего, кроме ряда исключений, опять таки — суровые ограничения на использование инструментов (билд система, кое-что даже на ide завязано) и общих/внешних компонент и библиотек.
отзывы, соответственно:
1.) а мы сделали по-своему и у нас работает
2.) нам это не удобно и мы так не хотим/не будем
3.) что за бред?
и, пожалуй, я все три реакции понимаю, особенно последнюю, так как она вступает в противоречие с некоторыми исходными требованиями и некоторыми best practice, ровно как и со здравым смыслом (на первый взгляд)
вопрос — как сделать не прибегая к жестким мерам и регламентации процессов? из третьего, например, следует, что перед тем как брать какой-либо внешний компонент, надо заапрувить это решение (благо, делается без бумаг и довольно быстро — полуавтоматически, но некоторая бюрократия присутствует).
на аналогичном проекте сделали по принципу «ничего не должно мешать разработке». теперь ни выйти в production не получается, ни с соседями интегрироваться.
а еще бывает «документацию прочитал по диагонали, почту не читаю, но вчера у меня все работало!», «а у меня на машине работает, это у вас неправильный сервер!» и «а нафига нам эти тесты и coding style checking?» или «а мне неудобно писать комментарии к коммитам!», и хоть трава не расти!
дочтаточно давно я работаю «по ту сторону» разработки ПО и очень обидно сталкваться с подобным непониманием.
да, бумага на создание VM — это просто ужасно (сейчас сам в похожем положении), но стандарт на именование и структуру директорий в svn — на многих проектах весьма полезен, так же, как и соглашения по именованию переменных, так же, как и общий процесс для перехода в QA и еще многие вещи. после определенного баръера человеко-часов без этой бюрократии проект может просто развалиться под собственным весом.