Погода: −3 °C
23.03−2...1пасмурно, снег с дождем
24.03−5...−3пасмурно, небольшой снег
  • В ответ на: P.S. Отнесусь с пониманием, если поленитесь доводить решение до конца. Как я уже писал, свое время дорого стоит.
    Вы ещё не поняли? Или политесом занимаетесь? Это никогда не будет доведено до конца. Подход с вероятностями как ковровая бомбардировка - хоть одна мышь, да проскочит. Абсолютно неверно пускать кошку туда, где только на данный момент вероятность толще (я про 2-2-4-4). Изложенными там выкладками можно лишь математически подтвердить правильное решение.
    Но можно привести программное решение, которое переберёт комбинации примерно на 10 шагов вперёд и выведет ходы кошки с вероятностью мышки в зубах 1. Это было бы реабилитацией:улыб:

    ps не, а вот если бы я на последнем комиксе клетки не квадратными, а прямоугольными отформатировал, то ассоциация с шахматами случилась бы?

    42

  • НПП
    Спорщики, а не пора ли вам в Курилку тематического подфорума? :1: :biggrin:

  • В ответ на: Подход с вероятностями как ковровая бомбардировка - хоть одна мышь, да проскочит.
    Именно так я и думал, когда читал спойлер.
    То есть, если речь идет о той же вероятности в "1", что и вероятность появления орла при подкидываниях монеты (_бесконечном_ числе подкидываний), то это не решение задачи Толстопуза.

    Но мало ли, вдруг у Mad_Dollar'а было решение с конечным числом ходов...
    Всегда есть шанс, что ты чего-то не понимаешь:улыб:

    Ну а та фраза, которую Вы цитируете - это просто возможность Mad_Dollar'у благополучно спрыгнуть с темы (зачем зажимать человека в угол, правильно?). Если это называется "политесом" - то да, этим я и занимаюсь.

    P.S. Ассоциация с шахматами случилась у меня, когда сам решал эту задачу (то есть несколько до появления комиксов).

  • Хорошо, вижу с копипастом все справились, теперь предлагаю вернуться в русло топика, и обсудить (не нужно его решать!) реальное тестовое задание.

    • задание для php-разработчика.

    «Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий» К.Прутков

  • Задание - как задание. Тем более что решать - "не надо"... Сильно похоже на "базовый проект" ВКИ НГУ... это который рассчитан на ребенка, начинающего изучать первый язык программирования... типа 12-14 занятий по паре, попутно с освоением языка и основ программирования, делались такие задачки... уж не знаю, что из той затеи сейчас там выросло...

    "Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин:улыб:(а не на "вертикаль власти" надеяться)

  • Решать - это Вам не нужно, а реальный соискатель должен выполнить это задание, чтобы попасть на собеседование.

    Сколько времени соискатель должен потратить на это задание?
    На ваш взгляд на какой уровень ЗП Он будет претендовать?
    Позволит ли данный тест выявить у соискателя его сильные/слабые стороны, потенциал?
    Вы сами бы стали выполнять тест для прохождения конкурса при трудоустройстве, если бы знали что правильность выполнения данного задания не влияет на решение о принятии вас в штат?

    • задание для php-разработчика №2

    «Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий» К.Прутков

  • В ответ на: правильность выполнения данного задания не влияет на решение о принятии вас в штат?
    Это видимо тот случай когда все по требованиям написано - но ни к инвариантам не приведено, ни об оптимальности и масштабируемости в проекте ничего не напоминает, да и вообще говнокод, который потом еще не один месяц исправлять.

    А время соискателя учитывать - бред. Рынок перенасыщен давно школьниками - фрилансерами. Это их проблема - вырасти из говонкода и стать настоящими программистами.

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

    об истинных причинах моего поведения и бредогенераторства

  • :улыб:Над достаточно эффективным решением я размышляю уже лет 6 ...:миг:

    "Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин:улыб:(а не на "вертикаль власти" надеяться)

  • > Пасибки, что уделили внимание. Посмотрел код. Если не учитывать общую многословность, то оно "практически" тоже самое, но чуть дольше. А упростить?

    далеко не то же самое :безум:

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

    Вариант от Велла - читается и понимается с листа. Упрощать там нечего, сокращать тем более, наоборот считаю не хватает { }, но в этом случае мелочи ...

    Или место на диске под сорс код экономится? Или склонность к однострочничеству со времен перфокарт сохранилась? :ха-ха!:

  • Читайте дальше. Уже разобрались что далеко не одно и тоже.:миг:

    "Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин:улыб:(а не на "вертикаль власти" надеяться)

  • В ответ на: Уже разобрались что далеко не одно и тоже
    Вы свое видение мира в ранг абсолютной и нерушимой аксиомы не возводите.

    Non solum oportet, sed etiam necessese est

  • В ответ на: Решать - это Вам не нужно, а реальный соискатель должен выполнить это задание, чтобы попасть на собеседование.

    Сколько времени соискатель должен потратить на это задание?
    На ваш взгляд на какой уровень ЗП Он будет претендовать?
    Позволит ли данный тест выявить у соискателя его сильные/слабые стороны, потенциал?
    Вы сами бы стали выполнять тест для прохождения конкурса при трудоустройстве, если бы знали что правильность выполнения данного задания не влияет на решение о принятии вас в штат?
    Уровень зарплаты - _восемь_ тысяч рублей. Потому что в вузах за это платят _семь_, и то отличникам, и с перспективами.
    А если человек устраивается клепать копросайты: то и этого не нужно, здесь - минимум 20-25 т.р. за запросы при полном отсутствии знаний. Удивительно, но так и есть - за семь в НИИ не берут, но берут за 27 в веп-студийе. Правда удивительно?

    Non solum oportet, sed etiam necessese est

  • > Читайте дальше. Уже разобрались что далеко не одно и тоже.:миг:

    Я и дальше прочитал, немного ...
    Очень смешно, особенно когда проверку на граничные условия покритиковали за нагрузку на процессор. Речь идет о рил тайм приложении? Эй, тогда вы реально облажались выбрав php в качестве инструмента! :ха-ха!: Нет? тогда забудьте про это лишний процессорный такт! Не надо заниматься охотой на ведьм, наукой давно доказано что их нет. И после этих замечаний, высказанных даже как будто всъерьез, кто-то там еще рассуждает о сферических конях в вакууме?! :eek: Проверка на граничные условия и оптимизация перформанса это две абсолютно не связанные с собой вещи. К тому же помимо самой проверки, эта строка кода просто объясняет какие входные данные не могут быть, и это между прочим важно.

    Код должен быть читаемым и понятным, это должно быть очевидно человеку имеющему дело с поддержкой и развитием приложения, тем более большого приложения. За названия переменных типа r_x, r_y надо саечки ставить :миг: за однострочничество тоже.

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

    :спок:

  • Расслабьтесь. ОН - непогрешим. ЕГО - не переделать, а из Вас может получится хороший сотрудник крупной компании.
    А может и не получится.
    Как получится.
    Из него - не получится точно - то-ли слишком умен, то-ли слишком надменен - никому до этого нет дела.

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

    Поэтому у вас шанс еще есть - у ТСа - нет, противно, досадно, но ладно, при достаточном обучении из ТСа мог бы получится нормальный "архитектор" (блин - это же обычный программист с обычной математикой на обычных задачах), но вот эго... эго то девать не куда.

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

    Non solum oportet, sed etiam necessese est

  • В ответ на: та строка кода просто объясняет какие входные данные не могут быть, и это между прочим важно
    Приходите! это то, что я не смог сформулировать. Вы понимаете о чем говорили участники даже не прочитав всего топика - и вы, черт побери, правы!

    Non solum oportet, sed etiam necessese est

  • Спасибо, что считаете меня перспективным спецом, надеюсь у меня еще действительно есть куда расти, несмотря на 10+ лет стажа преимущественно тем самым пресловутым enterprise программистом:миг:

    И за приглашение спасибо, но пока мне интересно на моем текущем месте во всех смыслах:улыб:

    Что касается ТС, то ему видимо просто сложно получить требуемый опыт сидя по уши в ГК, он возможно из тех кто умеет подковывать блоху, но на этом навыке нормальный производственный процесс наладить неполучится, поэтому идет на ощупь, набивает шишки, что в общем наверное естественно. Плохо что не пытается понять приводимые ему резоны и пытается стоять на своем, такая негибкость только вредна. Ну и вообще если у него весь codebase ГК, то сделать из него конфетку быстро не реально, сначала гк, потом уже потихоньку, болезненно придется вытягивать это болото, и то при соблюдении технологических правил.

    Вобщем ТС удачи и хороших сотрудников!

  • Я Вас приглашал? ))) Не может быть. Просто в части формулировок вы даже меня переплюнули, а это, поверьте,, не 10 лет "энтерпраз" программировать :biggrin:

    Мне кажется, или сакральный смымл всего противостояния будет открыт? =)

    Да, в организациях, кторые озабочены получением прибыли от качественно отрелизенного продукта, большую неделимую ставку ставят не на "гениев", а на тех, кто стандартно качстсвенно и без изысков пишет в рамках воркфлоу, предсказуемо, с запланированными багами (да, по времени и количеству! чудо!), с запланированной скоростью (божемой, как это возможжно!) и много чего еще имеет в плюс. И да - с запланированным кодестайлом, запланированными инпрувментами, реальными эстимацииями и кучей разно чисто рабочей фигни, включая +- оценку расходов бизнеса на "этот проект" на следующие пару лет...

    Чудо прям, не знаю как описать. :biggrin:

    Non solum oportet, sed etiam necessese est

  • В ответ на: Спасибо, что считаете меня перспективным спецом, надеюсь у меня еще действительно есть куда расти, несмотря на 10+ лет стажа преимущественно тем самым пресловутым enterprise программистом:миг:

    Что касается ТС, то ему видимо просто сложно получить требуемый опыт сидя по уши в ГК, он возможно из тех кто умеет подковывать блоху, но
    Главное, чтобы высказывающийся сам верил в то, что говорит/пишет. А то, бывает, порисуется на нгс, а потом утыкается в переполненную багзиллу своего чудо-как-идеального проекта. Повторюсь, но жизнь показывает, что те, кто часто произносит/пишет фразу "ГК", часто очень близко находятся с озвученной субстанцией :миг:
    Особо доставляет удовольствие, когда "настоящие специалисты" о стаже говорят. Это первый звоночек... Если при этом дуют щёки, то вообще отпад
    :хехе:

    42

  • В ответ на: Чудо прям, не знаю как описать. :biggrin:
    Да говорили уже о конвейере. Действительно, всё достаточно буднично без элемента экзистенции, как в анекдоте про скучающую на отдыхе проститутку "а вокруг станки, станки..."
    Тема-то о том, что получает ТС такого отработанного станочника (скорее всего не самого лучшего) и удивляется переменам в окружающем мире... Напоминает старинное кино с Ч.Чаплиным, когда мужик после рабочего дня выходит с конвейера Форда забавным дурачком.
    Кому-то грустно, а кто-то гордится своим образом жизни.

    42

  • "кукушка хвалит петуха за то, что хвалит он кукушку". (с) А. Крылов.

    Вы так здорово расплевались по тому коду "как стало", и так скромно умолчали о той части "как было"... "как было" - сами писали, не? Или "там всё нормально" всегда так пишу...:миг:

    "Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин:улыб:(а не на "вертикаль власти" надеяться)

  • В ответ на: Что касается ТС, то ему видимо просто сложно получить требуемый опыт сидя по уши в ГК
    А вот это я бы выделил жирным шрифтом. Потому что это и есть РЕАЛЬНАЯ адекватная оценка труда "энтерпрайз программистов со стажем", которые как раз и писали весь этот ГК. Причем, что характерно, оценка "ИЗНУТРИ" от коллеги...

    Собственно это и есть основная причина создания топика...

    Меня теперь волнует несколько другой вопрос:

    Согласно закону об авторском праве, имена авторов этого ГК, обязаны к указанию где-нибудь на страницах портала... потому как авторское право должно быть соблюдено...

    ... однако, согласно закону о защите персональных данных... этого делать низзя...

    Как быть? Вот мне почему-то кажется что страна должна знать своих героев...:миг:

    "Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин:улыб:(а не на "вертикаль власти" надеяться)

    Исправлено пользователем tolstopuz (01.03.12 10:54)

  • А можно было ответить и по поводу проверки аргументов, которую если не ошибаюсь вы же и презрительно прокомментировали, я вполне конкретно и наглядно обозначил почему скепсис там неуместен. Но вы ответили так как ответили. Вот на сентенцию выше мне ответить собственно нечего :dnknow:

  • > Вы так здорово расплевались по тому коду "как стало", и так скромно умолчали о той части "как было"... "как было" - сами писали, не? Или "там всё нормально" всегда так пишу...

    Еще раз глянул, там тоже плохо, но немного по другому :))
    Ну как было наверное хуже, но на таких маленьких примеров замерить что хуже сложно. Есть же "как надо", а есть "как не надо":миг:

  • Можно сколько угодно ругать труд коллег, злится и т.п.

    а) это не конструктивно

    б) это Вас не красит

    в) на все есть причины. Если производственный процесс не налажен, то вина в этом не на программистах, а скорее на тех кто его так отстроил. Вы и сами теперь в той же упряжке энтерпрайз программирования, через некоторое время когда через энное количество бранчей, мержей и рефакторингов в коммит логах будет только Ваши логины, Вы и сами превратитесь в этого "героя" :ухмылка:

  • > Тема-то о том, что получает ТС такого отработанного станочника (скорее всего не самого лучшего) и удивляется переменам в окружающем мире...

    бубубу

    раньше и трава была зеленее и деревья выше :biggrin:

  • На предыдущее:

    В ответ на: Еще раз глянул, там тоже плохо, но немного по другому :))
    Ну как было наверное хуже, но на таких маленьких примеров замерить что хуже сложно
    Во-от! В том то всё и дело, что РАЗОБРАТЬСЯ в том коде который был - Вам оказалось по-просту не под силу... зато делать замечания про "не феншуйный" пример - а то! в лёт... "энтерпрайз", аднака... за версту видно. А ведь это был, всего лишь "пример ПРЕОБРАЗОВАНИЯ кода" практически МЕХАНИЧЕСКИМИ методами... чего Вам дочитать также не удалось... а вовсе не пример феншуйного оформления, как все красны девицы здесь подумали...:миг:

    зато и конструктивно, и красит то как!:миг:

    ДО СИХ ПОР никто из оппонентов СВОЙ пример кода так и НЕ выложил... увы, но я понимаю - банально стыдно.

    зато радостно кричать "нашел косяк" в том, что предлагалось для ДРУГИХ целей - ай, да молодцы! и красиво то как!

    "Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин:улыб:(а не на "вертикаль власти" надеяться)

  • Презрительно откомментировал, потому что "где надо" - это тоже отдельный уровень понимания программистом поставленной задачи. Вот где НЕ надо - они у Вас стоят... а где надо как раз и отсутствуют..

    Как пример: ajax отправляет запрос серверу, на удаление данных из БД... на простой вопрос "энерпрайзу" а почему у тебя отсутствует код в блоке .onError()? недоуменное "а зачем?"... Гы. Пока смотрел страничку и отправлял запрос сессия протухла (1), сервер сдох(2), мускуль сдох(3), пришедший набор для удаления уже удален другим оператором(4), пришедший запрос нельзя обработать потому что данные уже ушли дальше по бизнес-модели и их банально нету(5)...

    Думаете как народ пишет операцию вставки в БД? Просто! $this->insert(...); Фсё. Заворачивать в транзакцию серию таких операторов - нафига? Сервер БД сам разберется! Обрамлять кодом try{}catch{} - зачем? Исключение сверху поймают (там правда уже все равно сделать ничего нельзя...), проверять результат метода (а он иногда! только false возвращает, так сказать молча...) - вот же глупость какая!

    ... и ведь большинству просто недвомек, что сервер БД - это удаленная машинка, которая банально может быть выключена на момент операции...

    а вот ставить проверки на тот код, который был приведен в примере - как раз и есть прямое разводилово Заказчика... потому как процедура внутренняя, а проверками в системе ваще-то занимается другой слой ПО... о чем и было писано и не токмо мною. Чего Вы опять же невнимательно читали... бывает. Там, кстати, большая часть кода - как раз проверки и остались. Только реально нужные...

    "Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин:улыб:(а не на "вертикаль власти" надеяться)

    Исправлено пользователем tolstopuz (01.03.12 14:11)

  • В ответ на: А можно было ответить и по поводу проверки аргументов, которую если не ошибаюсь вы же и презрительно прокомментировали
    А если бы ещё и далее прочитали, то увидели бы, что автор того кода нашёл-таки в .Net подходящие средства для выражения программирования по контракту вместо собственного "лисапеда"
    А я вот бы мог попросить Вас привести в пример открытый проект от слонов индустрии, где бы вот так были "защищены" все аргументы каждой функции и каждого метода. Вы бы не надсадились? Но скорее всего Вы не сможете ничего привести, потому что не читали код.
    И дальше бы двинул ход про то, что как мало же надо в своей жизни писать и видеть добротного кода, чтобы городить такой частокол вокруг каждого песочного куличика.

    ps и кстати enterprise программист для меня звучит уничижительно. потому что сильно много людей там прячется за спинами тех, кто действительно волокёт

    42

  • В ответ на: потому как процедура внутренняя, а проверками в системе ваще-то занимается другой слой ПО...
    Ну зачем Вы всё раскрыли? Пускай таки люди "со стажем" пишут как хотят. У них же другая реальность. "Другой слой ПО" - это другой человек этажом выше, такой же пуп земли со стажем. Каждый модуль у них обязан быть бункером, потому что кого возьмут с улицы на работу в следующий раз - не известно. У них программы из проверки параметров друг у друга состоят. На задачу заказчика по остаточному принципу. Но ровно до момента пока не замаячит дедлайн, и за спиной в затылок не задышит возбуждённый пм :ха-ха!:

    42

  • В ответ на: Кстати, хозяйкам на заметку - решение озвученного мной парадокса "майнти-холла" никто не привел - чудо, да?
    Наши программисты такие программисты. что страшно бывает...
    Здесь всё просто - эта задача такой боян, что все успели переср@ться по поводу решения еще задолго до нас.

    Что-то новое мы вряд ли сможем придумать:улыб:

  • Не расстраиваейтесь, нервные клетки не восстанавливаются:миг:

    > всего лишь "пример ПРЕОБРАЗОВАНИЯ кода" практически МЕХАНИЧЕСКИМИ методами... а вовсе не пример феншуйного оформления

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

    > ДО СИХ ПОР никто из оппонентов СВОЙ пример кода так и НЕ выложил... увы, но я понимаю - банально стыдно.

    Лично мне банально ничего не надо доказывать. А там уж понимайте как умеете:улыб:

  • вербализовывать надо свои соображения, а не прикрываться умными фразами типа "уровнем понимания".

    Расставлять проверки надо совершенно точно там, где в результате ошибочных входных данных возникнет исключительная ситуация, причина которой уже будет неочевидна / сложна для восстановления. Это минимум. А так надо чекать все, это нормально, две три строчки в начале метода только добавляют понимания, у вас больше аргументов или сильно замороченная проверка? Значит непорядок с дизайном скорее всего. Приватные методы чекать не надо. Вот и весь уровень понимания, на уровне правило, из которого бывают исключения конечно (каламбур, да)

    Про транзакции посмотрите что такое декларативные транзакции в частности и аспекты вообще. Это интересно. Ручное управление транзакциями давно не актуально.

    > а вот ставить проверки на тот код, который был приведен в примере - как раз и есть прямое разводилово Заказчика... потому как процедура внутренняя

    Вы продаете Заказчику строчки? Афигеть!

    И из контекста ваще непонятно было что процедура внутренняя, чем докажите? :ха-ха!:

  • А подскажите мне какое-нибудь средство в дот нете чтобы выкинуть свой эксепшен на ошибку валидации, а?

    Ну посмотрел, java.awt.image.BufferedImage, чем-то перекликается со случаем ТС, нормально все там с валидацией. И чо?

    Ну а волокут то наверное не энтерпрайз программисты, а чудо человеки великаны.

    Короче давайте поконструктивней, можно с наездами, но по делу, мы же профессионалы, да? :umnik:

  • Поставьте себе уже нормальную IDE, которая позволит рутинные операции делать легко и непринужденно. Не бойтесь добавить отдельную строчку или создать отдельный класс, это не страшно и не сложно, в конце концов купите побольше жесткий диск если вдруг писать широко Вам мешает клаустрофобия дискового пространства. И жизнь заиграет новыми красками!

  • А чего тогда было так бурно в тему влезать? Ни понял... покрасоваться чтоли?

    В ответ на: Я повторятся не буду, оставайтесь при своей религии если хотите
    Моя "религия" достаточно проста: код должен писаться ровно тот, который нужен. Писаться грамотно. "Грамотно" - это:
    а) лаконично. исполняемая часть кода должна быть оптимизирована "максимально возможно". То есть как можно меньше жрать процессорное время на избыточности кодирования. "Лишние вычисления" - это всегда впустую потраченное процессорное (и не только!) время, снижение надежности.

    б) лаконично. Данные должны как можно меньше переприсваиваться и преобразовываться. Структуры, особенно временные, не должны содержать какой-либо избыточности. "Лишние" данные - это ВСЕГДА лишние пересылки = нагрузки трактов, опять же время работы, опять же надежность.

    в) лаконично. Код должен быть максимально модульным. Одно действие должно делаться в ОДНОМ месте кода. "Лишний" код - это всегда копипаст, который приводит к увеличению чтения, интерпретации, объемов, снижению надежности и качества работы ПО. И резко повышает стоимость дальнейшего сопровождения и развития.

    г) лаконично. Код НЕ должен содержать хардкодовых констант. По возможности, НИКАКИХ ваще. Ни текстовых, ни числовых. Всё должно выноситься в файлы настроек, таблицы настроек, локализаций, ресурсов и т.д. Корму что больше нравится...

    д) развернуто. В части документирования и описания созданного ПО.

    Замечу, что п1-4, для интерпретирующих языков (PHP, из модных Рельсы Рубика) имеют особую важность, потому как кроме выполняемых затрат, есть ещё и затраты на интерпретацию и подготовку выполнения...

    Вроде как ничего сложного в моей религи нет. Да, профессиональных копрокодеров вовсе не приглашаю в неё. Каждый делает свой выбор самостоятельно. Только не надо навязывать Заказчику свою копрокодерскую религию словами "купите себе монитор пошире, жесткий диск побольше, сервер покруче" (нужное подчеркнуть)...

    Современные настольные однопользовательские железки, по мощности ПРЕВОСХОДЯТ старшие модели IBM 360 в разы... и то что они НЕ справляются в простыми задачами - и есть результат ДЕГРАДАЦИИ отрасли, точнее перевода в копроэкономику...

    В ответ на: Лично мне банально ничего не надо доказывать. А там уж понимайте как умеете
    Ещё раз... а чего так бурно влезли в тему тогда? Напомню начало: тема была (и есть) о деградации в ИТ отрасли, завышенных требованиях неграмотных специалистов "со стажем (копрокодирования)" к ожидаемой зарплате... Вы вроде как кинулись возражать... дескать всё не так, это аффтар дурак.

    ... а теперь "не надо доказывать"... собственно, согласен. Чего тут можно доказывать? По Вашим текстам, Ваша позиция понятна и прозрачна.:миг:

    "Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин:улыб:(а не на "вертикаль власти" надеяться)

  • деградация она практически во всех отраслях. а/и ИТ лишь часть этого айсберга.

  • tolstopuz вы как мысленное упражнение попытайтесь представить разработку действительно большого продукта с миллионами строк кода, создаваемого сотней программистов.

    Просто ИМХО у вас мышление "Левши который блоху подковал". Такой "Левша" найдет много проблем в коде и архитектуре любого большого продукта но сам он такой продукт никогда создать не сможет. Не сможет просто потому что иррационально смотрит на вещи:
    - занимается premature оптимизацией
    - уверен что его код не ломается и багов после поставки не должно быть
    - думает что тесты писать не стоит т.к. его код не ломается:улыб:
    - думает что все коллеги должны быть такими же Левшами.

    В реальной жизни большого проекта все как раз наоборот:
    - Premature оптимизация ВРЕДНА. Основной принцип keep it stupid simple - большие программы пишуться "для людей" а не для того чтобы экономить циклы процессора
    - Код ломается. Ломается обычно после изменений (представьте проект со 100 программистами и как в таком проекте делают рефакторинги и изменения)
    - Если нет автоматического теста то код либо уже поломан либо БУДЕТ поломан в будущем
    - Коллеги бывают разные и не все они Левши. Во многом люди "ломают" код не потому что они неквалифицированные а из-за:
    * противоречий в требованиях - новая фича "ломает" предудущую про которую программист даже не в курсе (а тестов то нет опачки!)
    * из-за сложности понимания всех тонкостей и особенности работы системы
    * из-за невнимательности

  • Кстати примеры "косяков" ваших бывших коллег (отсутствие обработки ошибки сервера/получения данных, не использование транзакций) просто наглядно показывает что ваша система в зачаточном состоянии (либо никому не нужна и никем не используется). Т.к. это просто детские ошибки.

    Также вам стоит учитывать что язык PHP известен огромным количеством малоквалифицированных прогаммистов т.к. на этом языке издервле клепают поделки. Я вообще за всю жизнь видел очень мало стоящих программистов на PHP т.к. нормальные программисты старались его избегать. Много лет это был уродец еше тот, только в 5 версии вроде появилось нормальное ООП (но и сейчас я бы не стал выбирать PHP). Но раз уж у вас используется эта технология то вам приходится мириться с этим "контингентом":улыб:

  • В ответ на: Основной принцип keep it stupid simple
    "однако Пушкина порядком переврали"
    ... simple, stupid
    ... stupidly simple
    Вы всерьёз оправдываете тот код, что привёл ТС от того самого stupid, и который вышел далеко не simple и более того - неправильным? То есть легче написать было, как в первом варианте? А тот, кто пишет сразу правильно, коротко и понятно - занудный оптимизатор и еретик?

    42

  • В ответ на: А подскажите мне какое-нибудь средство в дот нете чтобы выкинуть свой эксепшен на ошибку валидации, а?

    Ну посмотрел, java.awt.image.BufferedImage, чем-то перекликается со случаем ТС, нормально все там с валидацией. И чо?
    Спасибо, что Вы есть :appl:
    Спасибо, что не понимаете разницу между границами своего приложения, своих объектов и модулей и границами внешней библиотеки/компоненты. Восхищает, что Вы не закостенели после 10 лет стажа и делаете смелые попытки чтения чужого кода. Пусть даже так
    И за мудрый совет по IDE отдельное спасибо. Право, даже не подозревал...
    Я зря беспокоился, что ТС вносит элемент обучения. Оказывается его посты толком почти никто не читает. Люди со стажем лишь ищут возможность присоветовать IDE.

    Ну не томите же, какая IDE облегчит всем жизнь?

    42

  • В ответ на: мало стоящих программистов на PHP т.к. нормальные программисты старались его избегать.
    Мерилом языку всегда является задача клиента.
    Конечно можно делать всё одной отвёрткой, но наверно лучше иметь набор. Глупо избегать инструмент ради понтов только потому, что кто-то, пардон, бзднул на форуме, что windows must die

    42

  • В ответ на: tolstopuz вы как мысленное упражнение попытайтесь представить разработку действительно большого продукта с миллионами строк кода, создаваемого сотней программистов.
    Зачем мысленно? Первый, мною сколоченный (небольшой правда) программистский коллектив, повзрослев стал на ноги самостоятельно и теперь имеет оборот около 10млн у.е. в год (если уже не больше, данные на 2001г.)... Не сказать что удачно сколоченный, ну так на то и "первый"... многие из Вас туда регулярно на работу просятся, ежели вчё.

    В ответ на: - занимается premature оптимизацией
    - уверен что его код не ломается и багов после поставки не должно быть
    - думает что тесты писать не стоит т.к. его код не ломается :улыб:
    - думает что все коллеги должны быть такими же Левшами.
    ?!? Что в этом плохого, если ВСЕ коллеги будут повышать свою квалификацию и становится Левшами? Аналогично и по другим пунктам... плиз. Хотя, после этого:

    В ответ на: Premature оптимизация ВРЕДНА
    Поясните пожалуйста простой вопрос: КОМУ ВРЕДНА и для КОГО озвученные пункты моей религи реально плохи?

    "Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин:улыб:(а не на "вертикаль власти" надеяться)

  • В ответ на: - Код ломается. Ломается обычно после изменений (представьте проект со 100 программистами и как в таком проекте делают рефакторинги и изменения)
    На это отвечу отдельно. Уже не раз писал обратное, но Вас это, видимо ничему НЕ учит.

    Ломается копрокод, потому что фиксовое поведение хардкодено в его основу. Отсутствие достаточного количества необходимых проверок (зачем? и так нормально!) входных данных - никак не покрывается сколь угодно большим количеством тестов (Дейкстра). Проблема в том, что в данном случае волшебные слова "необходимых" и "досточное количество" - как раз и определяют уровень квалификации разработчика. Не верите мне - читайте классиков.

    Просто, если Вы не видели нормального кода, который работает ГОДАМИ, то это никак не означает, что его не бывает. Как пример могу привести такой момент:

    Самая быстрая СУБД мира - Mumps, код которой разработан в 1979 году и НЕ меняется до сих пор. Вы такой не знаете и ею никто не пользуется??? Да ну? Я Вам "по секрету" открою, что ускорение работы SQL баз данных делается за счет создания ИНДЕКСИРОВАННЫХ массивов, в народе по-просту - индексы. Так вот, ядро Mumps - и есть код для работы с этими индексными файлами... вот так-то. Mumps - и есть иерархическая БД индексных массивов (глобалей). Там больше ничего собственно-то и нету.

    Или, аналогично, могу подсказать что Фотошоп, Гимп и многие другие графические системы в своей основе содержат библиотеку графики, работающую весьма успешно с тех же лохматых 80-х... поэтому когда дезигнеры начинают холивар "что лучше" - мне становится смешно... ЭТО ОДНО И ТОЖЕ в своей основе.

    "Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин:улыб:(а не на "вертикаль власти" надеяться)

  • Несколько советов, по созданию нормально работающего ПО:

    1. Настраиваемость кода. В коде, по возможности НЕ должно быть совсем константных значений хардкодом. Они все обязаны выносится в инструменты настройки ПО. На проектах студентов, в свое время, снижал по 0.5 балла за каждую константу в коде проекта.

    if тра_ля_ля == 1 then чего-то делаем endif -- -0.5 балла за константу (1) и минус 0.5 балла за отсутствующий блок else, если не докажешь что он гарантированно не нужен.

    2. Создание ВСЕХ элементов ветвлений (if-elseif-else, switch-default) даже если в них делать нечего (как правило "пока нечего")... вот как раз там где "нечего" и можно втыкать различные диагностические сообщения типа "ой... странное значение... новый тип параметра = способ обработки? Добавьте сюда код тоже..." Это не просто "полезно", а в больших проектах как раз является гигантским подспорьем по "потеряшкам" функционала... далеко не каждый юз-кейс используется регулярно... и когда через пару лет, кто-то нарвется на такое сообщение - оно сильно помогает. Проверено на практике.

    3. Проверка всех входящих данных, которые приходят от:
    а) пользователей. "Человеку свойственно ошибаться", а часто - сознательно;
    б) внешних программ, работающих асинхронно. "Прога может и не работать в данный момент";
    ... и т.п.
    И совсем "не важно" как тут думают, что результат приватного метода проверять НЕ надо... необходимость проверки зависит не от приватности метода выдавшего результат, а от возможной степени недоверия к входным данным. Так данные взятые из БД - зачастую есть смысл перепроверять (как в примере выше с ресайзингом картинок), несмотря на то что вроде как сами же их туда и сложили... Почему? Да просто всё: если сервер НЕ вернул данные (асинхронный код - может себе позволить такое легко!), то ... "вот он большой банан"...

    В принимавшихся проектах студентов, недостаточность проверок данных снижала оценку на 1 балл за каждую отсутствующую проверку...

    4. Постоянный рефакторинг собственного кода. Когда-то это даже подавалось как метод писания проекта "снизу вверх", кажется... Поначалу и сам пишу код "как получится"... с теми же константами и т.п. Это достаточно быстро и сразу работает. Но, как только появляется кусок кода, который надо просто скопировать и заменить в нем пару символов... вот тут надо приучить себя бить по пальцам! Это первый звоночек по рефакторингу... своего же копрокода. Потому что, то что было написано "сразу" - это далеко НЕ продакшн...

    Для любознательных, отправлю к книжкам ИБМ-овцев (то ли Баррон, то ли кто-то другой) "Теория второй системы"... как-то так... вот эту схему писания кода и надо вбить себе в пальцы. На автоматике.

    5. Оптимизация исполнения. Как ни странно, но занимаясь этим вопросом ещё на стадии создания первой версии кода, устраняются многие проблемы, неявно присутствующие в плохо проектированных ТЗ, в том числе и в части структур данных.

    Так что, можете посмотреть с точки зрения этих требований на свой код и если оценка окажется отрицательной... учитесь дальше...:миг:

    "Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин:улыб:(а не на "вертикаль власти" надеяться)

  • Гениально. Просто гениально.

    До этого момента я лично был знаком только с одним гением - это мой сосед, дядя Миша.

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

    Я у него время от времени спрашиваю: "Дядь Миш, ты вот такой умный, а чо в депутаты не пойдёшь? Весь наш подъезд за тебя проголосовал бы...". Но он грустно смотрит на меня и идёт наливать себе стакан...

  • Спасибо конечно за ваши советы, но я их и до вас знал:улыб:

    На самое интересное - про авто тесты - вы и не ответили. Сколько бы вы не расставляли "лишние" else от них будет не сильно много толку если ошибка "ой что-то неправильно" вылетит у клиента - а просто сделать патч для этой версии будет стоить примерно 100 тыс долларов. 100 тыс долларов на то, чтобы саппорт идентифицировал проблему, передал ее в отдел разработки, там ее исправили (пара строк кода), создали патч или минорную версию продукта, продукт прошел QA, был отослан клиенту, клиент остановил кластер их 20 машин, задеплоил новую версию приложения, запусти кластер и подождал пока он "прогреется" (кеши заполнятся часто используемыми данными). И это не какой-то rocket science - а обычная крупная enterprise система.

    А теперь еще прикиньте что все шаги кроме самого первого надо повторить для 5 версий продукта и продукт обновить у еще 100 клиентов.

    ---

    Я же говорю вы живете в идеальном мире где все системы написны исключительно правильно что любое изменение максимально локализовано. Только опять таки вам в голову не приходят варианты измений вызванные новыми требованиями которые затрагивают несколько слоев и компонентов (да бывают и такие). И не надо говорить что программисты должны быть телепатами что начальная архитектура должна предусматривать все возможные изменения. Хотя безусловно опыт и чутье влияет на гибкость архитектуры.

    ---

    Ну а уж про вредность premature optimization вы и без меня почитаете например тут http://c2.com/cgi/wiki?PrematureOptimization. Важно понять что под оптимизацией я понимаю ухудшение читабельности и сопровождаемости кода во имя экономии памяти или процессора.

    ---

    to олдж: простите что перевлал цитату, хотя смысл остался тем же. У меня плохая память на имена, даты, цитаты:улыб:

    Исправлено пользователем elfking (03.03.12 13:17)

  • В общем мы с вами не сходимся в одной мысли. Вы считаете что "класс" это самое важное. А я думаю что порядок и организация "бьет" класс.

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

    Ваш пример с БД некоректен. Движок БД это как раз не крупная система - его могут написать 2-3 спеца за обозримое время. И тут то как раз требования вряд ли будут существенно меняться много лет подряд.

  • В ответ на: Просто, если Вы не видели нормального кода, который работает ГОДАМИ, то это никак не означает, что его не бывает. Как пример могу привести такой момент:
    только одно замечание, работающий код годами сам по себе содержит багу - он устарел за это время хз сколько раз.
    В ответ на: Или, аналогично, могу подсказать что Фотошоп, Гимп и многие другие графические системы в своей основе содержат библиотеку графики, работающую весьма успешно с тех же лохматых 80-х... поэтому когда дезигнеры начинают холивар "что лучше" - мне становится смешно... ЭТО ОДНО И ТОЖЕ в своей основе.
    расскажу знакомым дизигнерам, как анекдот, поржем. :rofl: да, кстати забыл спросить общий код зовется standart C library? :rofl:
    В ответ на: Самая быстрая СУБД мира - Mumps
    как бэ для скорости реляционные БД не самое лучшее решение :миг:

    ктати жигулятор и бентли тоже одно и тоже, там тоже есть общее - металл. :rofl:

    Схватил жопку в брюсселе
    бабами любимы
    тёплые коты
    а чего добился
    в этой жизни ты

  • В ответ на: только одно замечание, работающий код годами сам по себе содержит багу - он устарел за это время хз сколько раз.
    точно! нужна новая модель именно этого года. Модель прошлого года должна идти со скидкой

    В ответ на: расскажу знакомым дизигнерам, как анекдот, поржем. :rofl: да, кстати забыл спросить общий код зовется standart C library? :rofl:
    Вы так легко и со смехом садитесь в лужу, что остаётся только ржать с дизайнерами
    C standard library очень древняя, да?

    В ответ на:
    В ответ на: Самая быстрая СУБД мира - Mumps
    как бэ для скорости реляционные БД не самое лучшее решение :миг:
    Вам голоса в голове сказали про реляционные БД? Причём здесь MUMPS?
    Или уже не важно и можно без повода ржать? :хехе:

    42

  • несколько замечаний

    > Данные должны как можно меньше переприсваиваться и преобразовываться. Структуры, особенно временные, не должны содержать какой-либо избыточности.

    Именно поэтому Вы использовали массив в качестве ответа, а не спец класс? Тогда для сведения, и по памяти и по процессору оба решения идентичные, а вот по качеству коду нет.

    > лаконично. Код должен быть максимально модульным. Одно действие должно делаться в ОДНОМ месте кода. "Лишний" код - это всегда копипаст, который приводит к увеличению чтения, интерпретации

    Код должен быть слабо связанным. Для этого деление на модули (архитектура) должно быть в первую очередь сделано исходя из функциональных зависимостей и во вторую очередь исходя из технических. Только в этом случае реализация новой фишки или существенные изменения в поведении системы могут быть произведены относительно безболезненно. Сильно связанный код становится мертвым кодом, его нельзя менять, в одном месте поменяешь в другом отвалится и т.п. сложности.

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

    > лаконично. Код НЕ должен содержать хардкодовых констант. По возможности, НИКАКИХ ваще.

    А чего тогда у Вас в коде была константа SAFE_EQUALS = 0.0001 ? Кстати в этом случае она уместна, так что правило это не годится, но в подавляющем большинстве случаев это действительно так, хотя я надеюсь не имелись ввиду захардкоженные имена событий или там ключей по которым эти значения вытаскиваются :)) Ну и в качестве придирки - это не про лаконичность.

    > развернуто. В части документирования и описания созданного ПО.

    Я бы хотел добавить, что код должен писаться так, чтобы он был self documenting. Потому что чтобы вы не написали в комментарии и в спецификации - работать будет код и только он, как бы это банально не звучало. Еще и поэтому важны проверки, они еще и "документируют" код. Еще и поэтому важны юнит тесты - чтобы понять как реально работать с каким то модулем - я обязательно загляну в его юнит тесты.

    > Только не надо навязывать Заказчику свою копрокодерскую религию словами "купите себе монитор пошире, жесткий диск побольше, сервер покруче" (нужное подчеркнуть)...

    Заказчику похер на религию программистов, он покупает решению, которое должно работать на текущем железе, а не на IBM-360. И PHP это далеко не ассемблер. Очнитесь, ситуация 20 летней давности неактуальна уже 20 лет.

    З.Ы. доказывать не собираюсь приводя свой код, а в тему влез просто поговорить, просто увидел какой у Вас апломб, Вы весь в белом, вокруг одни копроделы, вот и захотелось разобраться так сказать :безум:

Записей на странице:

Перейти в форум

Модераторы: