дотнет-срач
.NET и Co - это не мейнстрим, это помойка для однодневных приложений
Сразу скажу, я на дотнете пишу уже года 4 и он меня задолбал весьма серьезно. Но тем не менее, альтернативы в моем случае (опердень с GUI, разрабатываемая в условиях адских ограничений по времени и ресурсам) тупо нет.
Основная причина, конечно, в том, что у меня на нем уже сделано 2/3 любого проекта типа "бд->аппсервер->gui-клиент", на любой другой платформе это все придется делать с нуля.
Но, кроме этого, в других платформах и языках, по-моему, такие задачи вообще не рассматриваются, как класс. Т.е. если GUI - то сделанный вручную, зашит в ресурсы, формы делаются по принципу "один студент-одна неделя-одна форма". А то и вообще GUI никто не рассматривает, потому что язык предназначен для веб- и прочих серверов. Очевидно же, что если основная целевая аудитория - веб-разработчики, то для серьезного GUI это использовать будет невозможно - даже если есть биндинги к GUI-тулкитам, они будут баговые и недоделанные и придется все время тратить на их допиливание. (Хотя, по правде сказать, в дотнете все точно так же - гуй там приходится допиливать постоянно).
Подумал я использовать жабу, для аппсервера. На словах все выглядит красиво - Hibernate, Spring итд итп. На практике, мне придется неделю сидеть только настраивать eclipse, jdk, jetty или томкаты, ant и мавены какие, разбираться как это все интегрировать, как сделать инфраструктуру для разработки. А потом опять с нуля делать все, что у меня уже сделано на ASP.NET (конфигурируемая миддлварь для произвольных баз данных, выставляющая CRUD операции в виде restful сервиса)
zabivator там по ссылку пропагандирует линукс, емаксы, билд из командной строки, итд. Я серьезно не понимаю, как можно в таком стиле быстро разрабатывать проекты. Т.е., я даже согласен признать, что я тупой, что у меня мозг сломан 15 годами быдлоразработки на дельфи, но я не понимаю, как проект НАЧАТЬ.
Когда приходишь уже на готовое - более менее понятно, скачал исходники, configure/make/install и понеслась. Я понимаю, что это закрывает 99% современного IT, когда народ приходит на проекты, которые делаются 10 до того, и будут делаться 10 лет после, получает инструкции "как включиться в работу", все им настраивается/деплоится с образом специально назначенными гуру-админами и все.
Но у меня обычно все не так. Стандартная ситуация "нужно с нуля сделать совершенно новый проект, нужно выбрать для него платформу так, чтобы не сойти с ума, чтобы по максимуму повторно использовать прошлые наработки, итд".
И обычно это выглядит примерно так: 20-50-100 сущностей предметной области, в лучшем случае их можно оформить в виде независимых редакторов, в худшем - они связаны в сложный адский workflow который нужно контролировать, чтобы юзера в дебри не убрели, разработчиков - 1-2 человека, времени - 2 месяца, причем каждый день будут регулярно отвлекать по мелочам, старым проектам и прочей хрени минимум 2-3 раза. Но зато почти нет оверхеда на коммуникацию, на сбор требований (требования уже известны, т.к. я предметку знаю лучше всех спецов клиетов вместе взятых). Тестирование софта обычно требуется по минимуму, т.к. изначально правильная архитектура не допускает множество тупых багов, а вот с документированием - абзац. Т.е. либо документирование, либо сделать проект вовремя.
Сразу скажу, я на дотнете пишу уже года 4 и он меня задолбал весьма серьезно. Но тем не менее, альтернативы в моем случае (опердень с GUI, разрабатываемая в условиях адских ограничений по времени и ресурсам) тупо нет.
Основная причина, конечно, в том, что у меня на нем уже сделано 2/3 любого проекта типа "бд->аппсервер->gui-клиент", на любой другой платформе это все придется делать с нуля.
Но, кроме этого, в других платформах и языках, по-моему, такие задачи вообще не рассматриваются, как класс. Т.е. если GUI - то сделанный вручную, зашит в ресурсы, формы делаются по принципу "один студент-одна неделя-одна форма". А то и вообще GUI никто не рассматривает, потому что язык предназначен для веб- и прочих серверов. Очевидно же, что если основная целевая аудитория - веб-разработчики, то для серьезного GUI это использовать будет невозможно - даже если есть биндинги к GUI-тулкитам, они будут баговые и недоделанные и придется все время тратить на их допиливание. (Хотя, по правде сказать, в дотнете все точно так же - гуй там приходится допиливать постоянно).
Подумал я использовать жабу, для аппсервера. На словах все выглядит красиво - Hibernate, Spring итд итп. На практике, мне придется неделю сидеть только настраивать eclipse, jdk, jetty или томкаты, ant и мавены какие, разбираться как это все интегрировать, как сделать инфраструктуру для разработки. А потом опять с нуля делать все, что у меня уже сделано на ASP.NET (конфигурируемая миддлварь для произвольных баз данных, выставляющая CRUD операции в виде restful сервиса)
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
Когда приходишь уже на готовое - более менее понятно, скачал исходники, configure/make/install и понеслась. Я понимаю, что это закрывает 99% современного IT, когда народ приходит на проекты, которые делаются 10 до того, и будут делаться 10 лет после, получает инструкции "как включиться в работу", все им настраивается/деплоится с образом специально назначенными гуру-админами и все.
Но у меня обычно все не так. Стандартная ситуация "нужно с нуля сделать совершенно новый проект, нужно выбрать для него платформу так, чтобы не сойти с ума, чтобы по максимуму повторно использовать прошлые наработки, итд".
И обычно это выглядит примерно так: 20-50-100 сущностей предметной области, в лучшем случае их можно оформить в виде независимых редакторов, в худшем - они связаны в сложный адский workflow который нужно контролировать, чтобы юзера в дебри не убрели, разработчиков - 1-2 человека, времени - 2 месяца, причем каждый день будут регулярно отвлекать по мелочам, старым проектам и прочей хрени минимум 2-3 раза. Но зато почти нет оверхеда на коммуникацию, на сбор требований (требования уже известны, т.к. я предметку знаю лучше всех спецов клиетов вместе взятых). Тестирование софта обычно требуется по минимуму, т.к. изначально правильная архитектура не допускает множество тупых багов, а вот с документированием - абзац. Т.е. либо документирование, либо сделать проект вовремя.
no subject
no subject
no subject
Но честно говоря 20 - 100 сущностей и 2 месяца: это жесть адская. Вы естимейшиом маленькие выставляете.
no subject
no subject
Все привыкли, что все делается "за один день". Потому что существующая платформа это позволяла, а сейчас нужно ее расширять до кроссплатформенности, веба, использования более современных чем дельфи средств разработки, итд.
no subject
no subject
no subject
Т.е., инструменты, требующие на освоение больше дня, рассматривать бесполезно.
Видимо, это нихрена не правильно, и нужно просто ложить хер на все, выключать телефоны, емыл и жабер и сидеть целенаправленно курить, то что нужно.
А, и на мнение окружающих тоже хер положить, а то оно слишком разновекторное :)
no subject
Но все это с лихвой покрывается удобством работы, и самое главное - начала работы.
no subject
no subject
no subject
no subject
no subject
Текстовый редактор - и вперед!
Правда, в качестве gui я использую web, который, обычно, другой человек разрабатывает.
no subject
А теперь я объясню, что нужно чтобы например нам начать новый проект:
1) поставить на работе меркуриал, т.к. svn не совсем подходит под наши условия. Во что то выливается - я уже писал недавно.
2) поднять резервный канал в интернет, т.к. основной падает часто, а доступ к серверу нужен.
3) поставить сервер баз данных и наладить у разработчиков доступ к нему, для создания баз(как раз идет этап разработки структуры базы).
4) поднять сервер приложений - это в случае дотнета IIS с настроенным asp.net приложением(dotnet 3.5)
5) поднять тестовую инфраструктуру для сервера - если по простому, это набор скриптов с wget, для проверки работы сервера.
6) сделать разработчикам доступ к базе конфигурации сервера приложений(база данных с гуи-редактором, из которой генерируется код и файлы конфигурации для сервера приложений)
7) сделать репозиторий в меркуриале со стартовой версией проекта, чтобы у разработчиков можно было сразу оттуда достать и начать работать.
т.е. до работы непосредственно с кодом тут минимум через пару дней только можно добраться. И это все я знаю что и как и на чем делать. Если же взять сюда хотя бы один неизвестный инструмент - количество необходимой подготовки увеличивается еще больше - нужно инсталлироваьт инструмент, проверить, можно ли его деплоить без инсталляции, разобраться как вкрутить его в среду разработки, проверить зависимости, итд итп.
no subject
"Окунитесь в реальный программерский АД!".
Использовать разрешено любые фреймворки, готовые продукты и прочее, в жюри половина состоит из невмяняемых админов, вторая половина - боящиеся клавиатуры выпускницы кафедры бухучета усть-урюпинского техникума жабоживотноводства.
no subject
BULLSHIT!
no subject
Жюри ее не читает. :)
no subject
(Anonymous) 2010-01-27 03:32 pm (UTC)(link)Ясен хер, что в таких условиях в консоли вбить `make build` проще, чем запускать студию и проч., и проч. Хотя также ясно, что аргументация притянута за уши, ибо nant/msbuild никто не отменял
no subject
no subject
Только C# мне не надоел :) Красивый язык по-моему получился.
no subject
Реализация, архитектура, API высокоуровневых частей фреймворка - страшный ад.
Коллега как-то искал баг вида "программа не реагирует на закрытие главного окна". Оказалось что логика валидации состояния контролов сделана настолько противоестественно, что удаление контрола с основного окна методом Parent = null; калечит состояние этого парента. Внутренности методов которые это выполняют - костыль на костыле и костылем погоняет, сразу очевидно, что авторам идея "посидеть подумать, а потом только писать" совершенно не близка.
no subject
no subject
Ситуация такая, что пока всех все устраивает. Я впилил на работе сначала svn, потом баг-трекер, основные действующие лица в итоге оказались этим очень довольны, документацию начали вести и следить за порядком.
no subject
deployment на моём проекте настраивать с нуля будет... Ну, скажем так, пару недель - пока все зависимости соберёшь, скрипты настроишь, зависимости и конфигурации пропишешь.
Теперь смотрим profit'ы.
* Разобравшись и настроив один раз, ты легко будешь делать все аналогичные проекты
* Легко сделать "скелетон" - генератор проекта, задаёшь название-авторов, запускаешь скрипт - на выходе готовый hello world, что УЖЕ умеет подключаться к базе и так далее.
* Если меня посадить за .NET + база + всё остальное, я тоже буду неделю а то и две сидеть и тупо фтыкать в инструменты - как чо где работает, куда крутить, как пускать тесты, и так далее
no subject
Я этот плач у вас два года уже читаю. Хули делать? Убить себя апстену, или таки научить уже людей уважать твою работу, твоё личное время, твоё здоровье.
no subject
Под убунтой всё такое гавно ставится одной командой apt-get....
+ конфиги для postgres/etc, с указанием путей куда класть.
Или просто скрипт, что пропишет куда чего надо
no subject
За пару недель слепишь аналог в линуксе - а дальше лёгким движением руки превращаешь его в скелетон (см. ниже что это), и все дальнейшие проекты будут развёртываться в виде:
sudo ./make_project project_name
в скриптах - apt-get / прописывание конфигов куда надо / и так далее
Экономь своё время.
no subject
Ты просто к этому ПРИВЫК. Не более.
no subject
Я даже сам не уверен, что имею право тратить время на то, чтобы разобраться с инструментом, который в 90% случаев придется массово допиливать до пригодности к продакшену. У нас, по всем параметрам, получается очень специфическая ниша - с одной стороны, полный GUI и опердень, а с другой - низкоуровневая работа с железом и сетями, да еще и администрирование всего этого. А большинство инструментов рассчитано на что-то менее разнообразное и безумное.
Я вот читаю ваши с dmzlj прения на тему окамла и его либо - мне страшно становится. Я этих слов ВООБЩЕ не слышал, и не уверен что большая часть программистов их тоже слышала. Т.е. это означает только одно: пойди что не так - садись и правь исходники инструмента/либы/фреймворка самостоятельно. Если вообще не делай с нуля. В принципе, с дотнетом то же самое - мы сейчас не можем использовать ключевой контрол так как нам надо, разработчик сидит с отладчиком 2008 студии в исходниках windows forms, ищет способы обхода. Но на дотнете уже большая часть этих вопросов решена, и таки комьюнити, хоть и индусское, но намного больше.
И вот я сомневаюсь в своем праве потратить время на то, чтобы делать себе инструменты, вместо решения текущих задач в лоб на существующих инструментах.
no subject
no subject
Раз запилишь основное, а по мелочи ты любую платформу будешь допиливать.
Где проблема.
Два года уже сомневаешься.
В то время пока у меня руководство мучается "что делать с тупыми жабистами" и "как собрать разваленный третий день билд", я сижу и пишу кодоген. Потому что НАДО.
Потому я свои задачи все уже сделал, и занимаюсь ИНВЕСТИЦИЯМИ в будущее, и ОПТИМИЗИРУЮ РАБОТУ.
Что же, тебе остаётся лишь сомневаться дальше.
Учить не можешь, брать новое сомневаешься, выбить два дня "чтобы никто не трогал" не в состоянии.
Ты прости, но ты сам себе злобный буратино, что всё в такой жопе.
no subject
Для меня со стороны GAC выглядит куда более забористой и ебанутой хуйнёй, чем либы в плюсах.
no subject
В GAC ее ставят, если она сотне проектов на компе нужна.
И по-моему, GAC - элементарная вещь, в отличие от с++ либ :)
no subject
Запоминаешь это золотое правило.
Дальше либо используешь dll, либо собираешь руками.
Благо большая часть библиотек доступна в сорцах
no subject
no subject
no subject
no subject
no subject
no subject
http://www.b-list.org/weblog/2008/dec/14/packaging/
no subject
py2exe спасёт
no subject
no subject