И вообще о железе для разработки

[metaclass]

Я периодически пытаюсь осмыслить - если бы для работы использовать более нормальное железо или более аккуратно отстроенную инфраструктуру, можно было бы работать эффективнее, или же это отмазка, потому что работать вообще влом.

В дельфи проще: компиляция порядка 100000 строк - пару секунд, запуск софта и открытие интересующего модуля для проверки - еще еще секунд пять. Вот если начать бэкапить или ресторить тестовые базы - уже от 30 минут до нескольких часов можно нихрена не делать. Поэтому базы я обычно копирую с диска на диск, это гораздо быстрее чем воевать с архивами или резерными копиями.

А в .net получается так: поставил компилироваться что-то в вижуал студии - это минимум 2-5 минут которые можно или пойти сожрать что-нибудь на кухне, или почитать ЖЖ, или заглянуть в RSS-читалку.

Запуск проги - минута (пока IIS сайт перегрузит, пока оно все с IIS подгрузит, да SQL сервер очухается)

Если поставить копироваться образ виртуальной машины, да еще по сети - еще минут 20 рабочего времени можно нихрена не делать - два компа резко становятся малопригодными для работы в студии, тормозят.
Запуск виртуальной машины - тоже минута-две.

Хорошо бы было использовать два-три разных компа, один с двумя мониторами и два с одним и какой-нибудь нормальный KVM-свитч, а то от ремоте-десктопов в глазах рябит. И на каждом компе минимум три физических диска гиг по 500-750. И чтобы компы были чо-нибудь вроде CoreDuo последних. И сеть гигабитную. Тогда, по идее можно было бы работать, не выпадая из потока за время тупления дисков и сети.

Но менеджер внутри головы говорит что это "выебоны не желающего работать обленившегося программиста, который ищет себе бонусов, ничего толком не делая".

Comments

[yurri.livejournal.com]

И что, в остальное время программист действительно бесперерывно работает?

Я именно работаю примерно половину рабочего времени, если по-честному (правда, подозреваю, что у всех более-менее так, потому что обычно иду с небольшим опережением).

Причём не сказал бы, что это сокращаемые затраты - т.е. не получается работать большую долю времени от имеющегося, не идёт.

Когда кодированием занимался, было получше, конечно, но всё равно далеко не всё время за вычетом технических расходов на компилирование - и вроде бы никто не жаловался, всё успевал.

Опять же, я далеко не гений, увы, так что мне кажется, это картина нормальная.

[metaclass.livejournal.com]

По моему, все программисты так работают - даже если заставить себя работать целый день - два-три дня так поработаешь, а потом неделю ничего вообще не делаешь.
Но лучше работать некоторое время подряд не отвлекаясь, а потом ничего не делать/заниматься чем-то другим, чем делать все вперемежку. А если железо и софт тормозят, то не отвлекаться просто не выходит.

Re: Reply to your comment...

[yurri.livejournal.com]

Ну тут как, с одной стороны это в общем масштабе "простоев"
некритично, с другой стороны, когда ты всё-таки решил поработать - то
тут лишняя минута торможения может сильно раздражать.

[vp.livejournal.com]

Факт +500
ты посмотри как у нас последние годы разработка проходит
месяц мыслей = 1 день работы, в остальное время разные занятия, по интересам (дурдом с заказчиками, выставки, говно и т.п.)

[aamonster.livejournal.com]

Есть такой момент, что такой простой может прийти очень невовремя - и после него требуется какое-то время, чтобы снова увлечься работой.

Так что минимизация таких моментов - большой плюс.

[1ceheart.livejournal.com]

Сборка большого проекта под FPGA на нормальном компе обычно занимает 30-40 минут, на компе "так себе" двухчасовой place&route - норма жизни.

Это неприятно, но не более того. Можно в это время спокойно заниматься тестами, и вообще есть чем заняться.

А вот двухмониторная конфигурация да, это важно. Я сейчас вынужденно с одним монитором, и такое чувство, как будто на мир через замочную скважину смотришь.

[potan.livejournal.com]

Это еще быстро - на старой работе часа 3-4 на вполне приличном компе.

[1ceheart.livejournal.com]

Некислые у вас там проекты :)

[potan.livejournal.com]

Второй Leon с обвязкой что бы Linux на нем нормально работал + несколько наших мелких модулей. Наши модули сами маленькие, все остальное для их тестирования.

[1ceheart.livejournal.com]

Leon такой тяжелый? Я никогда с ним не работал, но даже Nios, не говоря уж о Microblaze, собирается все-таки сильно быстрее. Оно того стоит?

[potan.livejournal.com]

Не знаю. Мы больше ни чего не знали открытого.
Проект уже завершен и я от туда уволился.

[sergiej.livejournal.com]

Везёт блин, ты бы подождал десять раз в день 15-ти минутного рестарта веблоджика (хорошо если одного а не 2-х, 3-х одного за другим), увидел бы где раки... а то 2-5 минут много ему :)
Конечно "компилится" в джаве всё влёт, потому что обычно подхватить нужно всего несколько файлов которые изменились. А сборкой больших проектов целиком должны заниматься не девелоперские машины, а скрипты на сервере, регулярно и автоматически, желательно вместе с автоматическими тестами - Be Agile :)

[metaclass.livejournal.com]

Сборкой то скрипты занимаются, проблема в том, что я отлаживаю кусок связанный со сквозным взаимодействием типа GUI->веб-сервис->(серверное приложение->чужая-система),(веб-сервис->СУБД)-> веб-сервис-GUI. Я уже и моков туда повставлял и на модули разбил как следует, все равно от каждого изменения в коде до теста запущенного по 2-5 минут проходит.

[sergiej.livejournal.com]

Ну я и завидую, у меня сквозное изменение такого типа это 15-20 минут, оптимистически, если ничего не упало по дороге :) Поэтому стараюсь ограничиваться малыми изменениями: сервис-база - тест, гуя-сервис (замоканый) - тест. И только потом из конца в конец. Вообще в идеале эти части разные люди или вообще тимы делают.

[metaclass.livejournal.com]

Да, в идеале всю эту работу надо замедлить в 5 раз и раздать разным людям.

[sergiej.livejournal.com]

Я последнее время склоняюсь к тому что лучше день потерять, потом за 5 минут долететь писать хорошие автоматические тесты, и добиваться "зелёненьких лампочек" а не гадать, заработает из конца в конец или нет.

[vp.livejournal.com]

Это все так и надо. Но иногда самое высокое руководство просто тупо не понимает, на что сейчас тратится время (подготовка тестов, налаживание инфраструктуры и т.п.).

[sergiej.livejournal.com]

Если за "подготовка тестов, налаживание инфраструктуры" не кроется разгильдяйство пока "полно времени", то руководству можно объяснить, даже простым показом как это работает. Дать доступ к панели с результатами тестов чтобы наблюдали, это очень занимательно и они сами будут бегать требовать чтобы красные лампочки превращались в зелёные. Это может и минус, но мотивирует очень когда рядом с набором "красных" тестов твоя фамилия.

[guamoka.livejournal.com]

Мне бы ваши проблемы:) Вот когда для фикса/проверки пустякового бага из модуля, который ты если и видел в глаза, то с пол-месяца назад, и в котором уже успели все переколбасить три разных человека, нужно забрать из CVS свежуюю версию всего проекта, потом выяснить где/отыскать последние тестовые данные (обязательно свои, хенд-мэйд, на каждый баг), переставить схему (которая может поменяться как погода в марте), залить данные, собрать приложение, задепроить на Вебложик, который после нескольких деплоев впадает в Java.lang.OutOfMemoryError: PermGen space, запустить и обнаружить, что что-то поправил не совсем так... И ведь главное юнит-тесты, моки и др. практически бесполезны, ибо ты не контролируешь изменения, и весь кодбейз поэтому словно зловонная жижа совершенно непредсказуемым образом перетикает, завихряется, клокочит:)

[metaclass.livejournal.com]

А сколько при этом времени на один баг отводится?

[guamoka.livejournal.com]

К счастью, в большинстве случаев достаточно. Однако, а) случаются авралы, и положение вещей, когда скрипя зубами глядишь на черепаший деплоймент приложения, абсолютно не радует б) как-то абсолютно не вдохновляет бестолково тратить на 10тиминутный баг час рабочего времени и уйму психических сил- получается все буквально по Ф. Ф. Преображенскому: забить парадный вход, а всем ходить в обход через черный:)

[vp.livejournal.com]

Когда час это хорошо. А часто бывает когда пол дня надо выкачать базу клиента, вторую половину дня восстановить всю его инфраструктуру, и на следующий день только подбираться непосредственно к анализу.

[guamoka.livejournal.com]

А часто бывает когда пол дня надо выкачать базу клиента


Ну, ребе, я описал только отдельную (свою) часть работы при типичном баг-фиксе;) При ведении дел с одним из предыдущих клиентов было необходимо скачивать с ФТП свежие данные по двое суток. А некоторые данные необходимо было заливать в подготовленную базу через интеграционный модуль по JMS, и тоже порядка нескольких часов. Не спрашивайте, почему для тестов нельзя было хотя бы исключить JMS и лить данные прямо в базу через мок-кліента:)

[feorex.livejournal.com]

У меня на прошлом проекте было незазорно баг фиксить день.
Был случай, что я на простой баг с неправильной очисткой полей потратил около 5 дней. Потом мне ввалили за это пиздюлей, и я пофиксал его за час :)
Проект-то в целом и заключался в фиксании багов. Около 1.5 млн строчек кода, так что там было чем заняться.
Хорошо, что это все закончилось :)

[zamotivator.livejournal.com]

Тебе везёт, наша СУБД распределённой сборкой (параллельно 20 компов) компилируется минут 15-20 (т.е. 6-7 часов времени компиляции на одной машине), линкуется минут 20-30.
Вот так вот...

[alll]

Вы там, я смотрю, уже скоро второй MySQL забабхаете и за переплёвывание Oracle приметесь. :)

[metaclass.livejournal.com]

Я так понимаю, у них БД в основном read-only и в силу этого мегаоптимизированная под обгон всех других БД :)

[alll]

Я немножко в курсе, пару месяцев имел честь рассматривать тамошние потроха. Но давно, вроде даже ещё до появления там zabivator'а. И уже тогда там был как бы готовый продукт, хотя не без планов на вырост. Вот и гадаю, что там за пару лет ещё эдакого наворотили.