Здравствуйте, Тёмчик, Вы писали:
L>>Бесполезно рассказывать о своем опыте разработки сетевых устройств человеку, для которого сетевое программирование ограничивается сакральным знанием о том, как открыть сокет, вычитанным за 15 минут до собеседования из википедии, а протоколов, кроме TCP, не существует.
Тё>Сетевая часть пишется максимум за полдня с закрытыми глазами. Вот как разрулить толстый поток, дозапрашивать пакеты и не лочить, не выжрать память- нужно знание структур данных, алгоритмов, многопоточки, паттернов проектирования — т.е. ровно того, что на собеседовании у тебя пригорает.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Увы, джентльмены, начинать с намеренной пессимизации не прокатывает.
Так не нужно пессимизировать намеренно. На том этапе, когда заказчик не знает чего хочет, когда идут постоянно требования — "а давайте добавим вот эту фичу", затем на следующей — "нет, вот эту фичу, которую мы добавляли, ради которой нам пришлось до хрена рефакторить — это мы випилим, она не нужна", затем — "эту фичу мы модифицируем", затем — "нет, тут мы ошиблись, вот тут связь не 1 к одному а много ко многим, а здесь не много ко многим а 1 ко многим", и в таком режиме продукт может жить годами. При этом с развитием может оказаться, что для клиента 1 идет 1 набор фич, для клиента 2 идет второй, для третьего идут фичи с модификациями, четвертый клиент хочет вообще конструктор фич, чтоб он сам мог добавлять свою специфику самостоятельно. Если в таком режиме все делать сверхоптимально, а не максимально гибко — в этом случае проект будет делаться 100 лет.
План определяет, как именно SQL сервер будет вычислять ответ на запрос. В каком порядке читать из каких таблиц, какими индексами пользоваться, т.е. как именно сервер собирается обращаться к своим B-Trees на диске.
Здравствуйте, elmal, Вы писали:
E>Так не нужно пессимизировать намеренно. На том этапе, когда заказчик не знает чего хочет, когда идут постоянно требования — "а давайте добавим вот эту фичу", затем на следующей — "нет, вот эту фичу, которую мы добавляли, ради которой нам пришлось до хрена рефакторить — это мы випилим, она не нужна", затем — "эту фичу мы модифицируем", затем — "нет, тут мы ошиблись, вот тут связь не 1 к одному а много ко многим, а здесь не много ко многим а 1 ко многим", и в таком режиме продукт может жить годами. При этом с развитием может оказаться, что для клиента 1 идет 1 набор фич, для клиента 2 идет второй, для третьего идут фичи с модификациями, четвертый клиент хочет вообще конструктор фич, чтоб он сам мог добавлять свою специфику самостоятельно. Если в таком режиме все делать сверхоптимально, а не максимально гибко — в этом случае проект будет делаться 100 лет.
Ты или готовую прикрути, или свой контейнер напиши с топологической сортировкой и простыми понятными интерфейсами наружу, покрой юнит тестами. Надо заказчику сортировку- подцепил, не надо- выбросил. Может в будущем пригодится. Так нет, каждый раз по памяти фигачишь кривой велосипед с O(n*n*log n).
Update
А вообще, я тут подумал (правильного алгоритма не читал) ведь топологическая сортировка — это обход графа с удовлетворением зависимостей. Просто обходишь в глубину и помечаешь пройденные узлы, чтобы не было повторов (та самая мемоизация).
Здравствуйте, elmal, Вы писали:
SVZ>>Увы, джентльмены, начинать с намеренной пессимизации не прокатывает. E>Так не нужно пессимизировать намеренно. На том этапе, когда заказчик не знает чего хочет, когда идут постоянно требования — "а давайте добавим вот эту фичу", затем на следующей — "нет, вот эту фичу, которую мы добавляли, ради которой нам пришлось до хрена рефакторить — это мы випилим, она не нужна", затем — "эту фичу мы модифицируем", затем — "нет, тут мы ошиблись, вот тут связь не 1 к одному а много ко многим, а здесь не много ко многим а 1 ко многим", и в таком режиме продукт может жить годами. При этом с развитием может оказаться, что для клиента 1 идет 1 набор фич, для клиента 2 идет второй, для третьего идут фичи с модификациями, четвертый клиент хочет вообще конструктор фич, чтоб он сам мог добавлять свою специфику самостоятельно. Если в таком режиме все делать сверхоптимально, а не максимально гибко — в этом случае проект будет делаться 100 лет.
Гм, интересные шляпки носила буржуазия.
А в какой отрасли такие разброд и шатание? Веб сайты? Какие-то корпоративные системы?
В наших ебенях САПРах так не делают. Объем данных известен еще на берегу, цель тоже более-менее известна.
Нюансы выплывают немного в другом. Либо задача будет исследовательской, пока не сделаешь, не узнаешь, годится ли результат. Либо задача известна, но данные приходят из разных источников, и хотя они соответствуют спецификации, могут быть всякие косяки.
В обоих случаях нет смысла ляпать прототип на скорую руку, экономии не получишь. Да еще и рискуешь не дождаться результатов, если сляпано совсем без оптимизации.
Ну и есть такая вредная традиция, которую еще Хмелевская описала в своих мемуарах: "...нет ничего более постоянного, чем временное. Так времянка, построенная для ремонта усадьбы, простояла 200лет...". Так что приходится делать сразу добротно.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>А в какой отрасли такие разброд и шатание? Веб сайты? Какие-то корпоративные системы?
В разработке корпоративных приложений вот такое сплошняком. Особенно весело когда работаешь не по готовому ТЗ, а пытаешься что то сделать такое, чтоб у тебя это купили, и бегаешь по потенциальным клиентам собирая требования и показывая прототипы. Да и когда заказчик известен — обычно тоже куча веселого. ПОка пишется, все, поменяется 10 представителей заказчика и 10 раз требования, причем оценка объема данных может отличаться в миллион раз от изначальной .
Здравствуйте, elmal, Вы писали:
SVZ>>А в какой отрасли такие разброд и шатание? Веб сайты? Какие-то корпоративные системы? E>В разработке корпоративных приложений вот такое сплошняком. Особенно весело когда работаешь не по готовому ТЗ, а пытаешься что то сделать такое, чтоб у тебя это купили, и бегаешь по потенциальным клиентам собирая требования и показывая прототипы. Да и когда заказчик известен — обычно тоже куча веселого. ПОка пишется, все, поменяется 10 представителей заказчика и 10 раз требования, причем оценка объема данных может отличаться в миллион раз от изначальной .
Понятно.
Не, у нас с этим попроще. От клиентов приходит фидбек и в целом понятно, что им надо. Плюс всякие выставки и конференции показывают, в каком направлении движется отрасль в целом.
Вот серьезная проблема это борьба с конкурентами. Честные методы, ессно, не работают. Надо работать через топ-менеджмент, а это знакомства + талант.
Вернее, не знакомства, отрасль небольшая, все всех знают, а именно вхожесть в кабинеты.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, uncommon, Вы писали:
U>>Я так понял, ты менеджер?
НС>А еще у меня 20 лет опыта разработчика. Так что все равно у меня длиннее.
К сожалению это мало о чем говорит. Есть такие ребята которым не повезло и они 20 лет работали с менеджерами и знать не знали и представить себе не могли что может быть иначе. В итоге такие ребята становятся менеджерами и окончательно запирают перспективы своего развития. Ведь если ты менеджер, то не имеешь уже шанса понять как работают без менеджеров. Стал таки драконом.
Здравствуйте, Gattaka, Вы писали:
НС>>А еще у меня 20 лет опыта разработчика. Так что все равно у меня длиннее. G>К сожалению это мало о чем говорит.
А что говорит много? Величина ЧСВ?
G> Есть такие ребята которым не повезло и они 20 лет работали с менеджерами и знать не знали и представить себе не могли что может быть иначе. В итоге такие ребята становятся менеджерами и окончательно запирают перспективы своего развития. Ведь если ты менеджер, то не имеешь уже шанса понять как работают без менеджеров. Стал таки драконом.
В отличие от тебя, я создал или довел до ума несколько успешных open source продуктов, которыми пользуются десятки тысяч человек. Так что у тебя все равно короче.
Здравствуйте, SergASh, Вы писали:
SAS>А задачу-то можно озвучить?
Ну я слышал краткий вариант в таком виде.
Гномы отмечали день рождения Белоснежки и немного перебрали сладкого сиропа. За долгие годы в коллективе набрались взаимные претензии у каждого к каждому, но они существа добрые и любой третий не позволит двоим подраться. Всем гномам надо перебраться по мостику через ущелье, но мост ограничен по номинальной нагрузке по проекту, не более N гномов за раз, но, как нам известно, мосты проектируются с допусками в X процентов сверху нагрузки. X неизвестен из-за того, что Железный Дровосек уехал на курорт на профилактику и не осматривал техническое состояние моста. За время его отсутствия злобные Марраны угрожали Страшиле Мудрому и для устрашения сожгли одну шину на мосту, образовалась дырка круглой формы. В эту дырку проросло дерево. Страшила не поддался на провокации, Марраны через несколько лет сожгли вторую покрышку. Гномам нужно преодолеть дырку и перебраться на другую сторону, пока не наступила ночь и злобный людоед не сожрал иж. Они надели разноцветные колпаки, взяли квадратную крышку от люка и пошли на другую сторону. Обошли дерево вглубину и краем глаза заметили какой-то сундук высоко в густых ветвях. Время поджимало и крышка тяжелая. После обхода дерева они прошли дальше, дошли до дырки от сгоревшей шины, положили крышку. Поскольку они любопытные, они развернулись нерекурсивно и пошли назад. После разворота кто-то зацепился за длинную одежду товариша и им пришлось определять место цикла и отцеплять друг дружку чтобы снова получить нормальную связность. Подощли к дереву и начали обходить его в ширину, нашли сундук с золотыми монетами. Поделили клад так, что каждому в каждый его карман положили по монетке. У всех разное число карманов, но известно что их не более 16 и не менее 12 у каждого из гномов. Всем дали по монетке разных номиналов, так чтобы ни у одного в отдельности не было двух монет одного номинала. В итоге у каждого оказалась равная сумма. Они развернулись в этот раз уже рекурсивно и продолжили путь. По достижению другого края они нашли кучку блинов разного размера на одном блюде, прикрепленном цепью к камню. Рядом находялось еще два пустых блюда, одно тоже с цепью, другое свободное. Они при помощи лопаток перенесли блины на блюдо, которое не прикреплено к камню и продолжили путь. Зашли в замок к Кощею и за сумму в K денег выкупили у него прекрасную принцессу Элли, собрав деньги L различными способами из своих карманов. После этого нажрались булочек с маком, которые добрые Жевуны раздавали рядом с полем и нетвердой походкой горланя песни дошли до города, где устроили пир и накормили всех блинами.
Вопрос: во сколько обойдется Страшиле Мудрому ремонт дороги, моста с путепроводом нектара, восстановление макового поля и поиски загулявшего Дровосека. Нужно ли брать кредит у подземных королей или лучше распродать земли вокруг города? Какова зависимость затрат по времени и по ресурсам от числа гномов?
Бонусные вопросы.
Насколько изменится время, если вместо летающих обезьян материалы для ремонта будут доставлены на автомобиле Винтика и Шпунтика?
Перечислите плюсы и минусы привлечения разных исполнителей для ремонта: гномов, деревянных солдат, жителей города, сельских жителей.
Как Страшиле Мудрому избежать обвинений в растрате бюджета и покрывательстве промахов Железного Дровосека?
Стоит ли Храброму Льву принимать участие в тендере на охрану строительных работ и как ему победить в заявке против саблезубых тигров?
Какие организационные выводы должны последовать из происшествия для уменьшения возможности повторения? Стоит ли вводить запрет на угощение медовым сиропом после двух часов дня или ограничиться выговором Белоснежке? Провести ли референдум о легалайзе или скосить маковое поле и посадить ромашки?
Каким образом вести контроль работ и раздачу задач: водопадом, канбаном, скрамом или прочим аджайлом?
К этому моменту у меня внутри 0.5, 0.7, 0.33 (с) НС
.
