Я не хотел бы вас с Zakus'ом обижать и уводить в глухую оборону, но молчать больше не могу. :)
Программирование — не какая-то особенная работа, она так же поддаётся оценкам с определенной точностью. Обычный инженерный труд. Когда разрабатывается новая модель телевизора, телефона, самолета, когда проектируется новое здание, инженеры не забивают на оценку и не рапортуют начальству «хрен его знает когда будет, мы забили на анализ — уже хреначим вовсю!». Более того, зачастую программное обеспечение является частью других более крупных проектов. И всё прекрасно оценивается. Понятное дело, везде есть погрешности и непредвиденные обстоятельства.
От вашего подхода к организации производства сильно несёт кустарщиной. Не обижайтесь, но ваши навыки в этой области сейчас находятся на уровне «подающий надежды гений», перечитайте.
Ничего не знаю о ваших реализациях стека и списка, хотя сам факт их наличия, как бы это сказать, немного смущает. В том же конкретном случае, к инициалам в именах класса прилагались симптоматичные для «подающего надежды гения» забавные конструкции, включая System.exit(1) в catch-блоках, которые, например, тихо и молча тушили tomcat без единого писка в логи.
Да и вообще, логика такова, что именам классов подобает отражать их назначение и содержание. Если же у списка или стека единственной особенностью является автор, то не понятно их назначение, если же нет — то почему не намекнуть на их назначение или особенности в названии класса?
Вообще говоря содержание договора — не их дело. По крайней мере у меня никогда вопросов не возникало. Как я понимаю, им главное сдать в вышестоящие органы паспорт валютной сделки (за скромную сумму заполняют сами и необходим только при договорах на сумму свыше 5k) и документы подтверждающие основания для транзакции(чаще всего инвойс). Остальное — дело вас и заказчика. Про продажу валют и прочее — не набегает там никаких 6%.
Не холивору для, а из любопытства. Я стараюсь при решении задач, требующих многопоточности, извернуть всё в сторону immutable state и сообщений. Есть ли какой то класс задач, который решается эффективнее с использованием изменяемого состояния и STM? То есть куда бы посмотреть чтобы цокнуть языком и сказать «Ай да STM, ай да сукин сын!»?
и как hands on ощущения? мне пока еще не удалось потрогать clojure основательно, но из того что пробовал — сильно раздражали запутанные сообщения об ошибках.
Есть мнение что для всех перечисленных форматов файлов (кроме, наверное, pdf) можно использовать open office в headless режиме, как это и сделали парни из Alfresco. Понятно, что это куда более громоздкое решение, но, как говорится, 30 гектар леса разом и под корень.
вообще говоря, в бытность мою работы в custom software development, стандартный пункт нашего договора гласил что любые двоякие прочтения технического задания трактуются в пользу разработчика. и это нормально.
не за что. еще что хотел сказать по поводу этой статьи — интеграционные тесты со спрингом конечно бывают нужны, но по сути в большинстве случаев лучше изолировать тестируемый код, подставляя вместо зависимостей Mock'и. Которые тоже здорово и просто делать с помощью Unitils. То есть, к примеру, для тестирования сервисов удобно создать mock'и dao и проверять не «во всю глубину», а только контракт взаимодействия сервиса и dao.
давно пользуюсь примерно аналогичным окружением. только вместо голого junit, использую связку testng+unitils. позволяет разбивать тесты на группы, и солидно так сокращает код, за счет использования ReflectionAssert и прочих приятностей из unitils.
И да и нет. В десятке последних проектов, после деплоймента production версии, конфигурация не менялась ни разу. Я понимаю что данное утверждение справедливо не для всех проектов. Но на моей памяти спринговые xml чаще живут внутри jar'а и никем не меняются во время эксплуатации. Большой разницы исправить ли xml или реестр модулей для меня нет, однако, проверка реестра компиляцией — очень удобная вещь.
Программирование — не какая-то особенная работа, она так же поддаётся оценкам с определенной точностью. Обычный инженерный труд. Когда разрабатывается новая модель телевизора, телефона, самолета, когда проектируется новое здание, инженеры не забивают на оценку и не рапортуют начальству «хрен его знает когда будет, мы забили на анализ — уже хреначим вовсю!». Более того, зачастую программное обеспечение является частью других более крупных проектов. И всё прекрасно оценивается. Понятное дело, везде есть погрешности и непредвиденные обстоятельства.
От вашего подхода к организации производства сильно несёт кустарщиной. Не обижайтесь, но ваши навыки в этой области сейчас находятся на уровне «подающий надежды гений», перечитайте.
Да и вообще, логика такова, что именам классов подобает отражать их назначение и содержание. Если же у списка или стека единственной особенностью является автор, то не понятно их назначение, если же нет — то почему не намекнуть на их назначение или особенности в названии класса?