• Кроссворд из регулярных выражений
    0
    Кстати, в русском языке когда прочитаешь эту комбинацию, невольно усмехнешься )
  • Кроссворд из регулярных выражений
    0
    На собеседование — долго ) нужно тогда его сократить раза в три.
  • Кроссворд из регулярных выражений
    0
    Не прокатит ) разве что придумать уникальные для каждого — а это задачка уже посложнее самого решения, IMHO ))
  • Профессионализм и TDD
    +1
    По личному опыту, проблемы TDD следующие:
    Очень трудно внедрить TDD на legacy-проекте. Перед тем, как это сделать, придется существенно отрефакторить большую кучу кода, что чревато. Имеется в виду модификации старого кода или написание нового кода в интеграции или по аналогии со старым (единообразие часто бывает важнее красивости и каноничности).
    — Через TDD неудобно писать сценарные тесты. Кто-то может возразить, что сценарные тесты должны быть интеграционными, а не unit-тестами — это предмет отдельного разговора. Важно то, что если мы хотим фиксировать сценарии и пишем для этого сценарные тесты, то делать это по TDD — значит, противоречить одному из его основных положений, — движению маленькими шагами. Я не говорю, что это невозможно, нет — это вполне возможно. Но неудобно.
    — TDD не гарантирует качественной архитектуры (хотя некоторые фанаты почему-то думают иначе). Если не брать во внимание дальнейшую компонентную структуру системы, то все рискует развалиться, и никакой TDD не спасет.

    Но я лично рекомендую всем, кто против TDD для каких-либо целей, попробовать его вначале на меньших масштабах и понять, когда его стоит использовать, а когда — нет. В частности, написание кода по TDD учит разработчиков думать о тестировании и API с другой стороны, и в дальнейшем их код становится намного лучше. Учиться нужно на практике.
  • Шпаргалка Java-программиста 6. Список полезных ссылок для Java программиста
    +2
    Не думаю, что все, но распространенные задачи, пожалуй, и правда почти все решены. :-)
    Остались задачи узкого круга, требующие высокой специализации.
  • Var и val в Java?
    0
    Причем этот старый код часто бывает не покрыт тестами, и часто его даже нельзя покрыть без рефакторинга… А рефакторинг не безопасен. Порочный круг legacy :-)
  • Зачем программисту знать алгоритмы
    0
    И еще: иногда мощная IDE экономит до 80% времени разработки — и тут уже быстрота IDE становится не самым важным фактором, т.к. инструменты более мощной IDE гарантируют (до некоторой степени) корректность многих операций — а это многого стоит.
  • Зачем программисту знать алгоритмы
    0
    Мощь и скорость могут и сочетаться — такое бывает, хотя и редко. :-)
  • «Половина научных работ по Concurrency — полная чушь!» — интервью с Романом Елизаровым из Devexperts
    0
    Прежде чем публиковать, нужно из частного технического решения вычленить общую часть и формализовать алгоритм. Это не самая простая задачка, IMHO, требующая времени и усилий.
  • Большой опрос по алгоритмам
    +2
    Насчет алгоритмов… Хороший разработчик, в отличие от посредственного, обладает одной важной чертой. Нет, это не знание алгоритмов — это добро всегда можно найти и реализовать. В программировании наиболее важной является другая черта — учесть все вариации входных данных. Ключевое слово — "все". Хороший программист способен разбить все множество входных данных на классы эквивалентности, учтя при этом технические реалии (конечную память, ограничения на размеры структур данных, численные переполнения и т.д.), аккуратно их расписать, собрать одинаковые части вместе, и уже после этого написать код, который будет правильно работать для всех этих случаев.

    Да, это сложно. Но только тот, кто это может и делает, достоин звания "инженер-программист", которое у многих значится в названии должности. :-)
  • Еще возитесь с отладкой?
    +1
    А теперь небольшое слово про отладку.
    Отладка нужна тогда, когда по коду кажется, что все должно работать, но оно почему-то не работает.
    Забыли какой-то сценарий, и не можем быстро понять, какой именно. Как правило, ошибка при этом содержится в данных, а не в логике кода, а причина находится довольно далеко от неверно работающего кода. И в этом случае stack trace позволяет однозначно выцепить ветку, в которой происходит ошибка, выкинув все побочные варианты. Анализировать все варианты в голове просто дольше.
    Т.е. дебаггер — это просто средство экономии времени для таких сложных случаев. И как показывает практика, чаще ошибку проще найти путем анализа кода, ведь для дебага нужно поднять соответствующее окружение, а это часто дороже, чем анализ всех веток.
  • Еще возитесь с отладкой?
    0
    Одна из целей ООП — избежать модификации существующего кода, заменив ее наследованием.
    Это актуально при использовании всяких framework'ов, и обычно мы используем эту мощь даже не задумываясь о том, что без ООП это бы просто не работало.

    В части написания компиляторов множество классов — это более простой путь в части поддержки, т.к. это позволяет не забыть добавить обработку для всех возможных типов узлов.
    switch просто писать, но очень легко пропустить обработку нового узла, и компилятор тебе не поможет. Это можно нивелировать другими практиками (наличие default-ветки с Exception'ом + полное покрытие тестами), но не все это делают, сами понимаете. :-)

    В любом случае, ООП предназначен для вполне конкретной цели: уменьшить сложность понимания логики кода. Если при использовании ООП у вас сложность только повышается — вы не правильно используете ООП, или используете его там, где он не нужен.
  • Еще возитесь с отладкой?
    0
    IMHO, автор не понимает всей сущности автотестов.
    Что даст автотест на класс Words?
    Тестирование маленькой функции с вполне определенной семантикой.
    Это всегда просто, обычно как раз такие тесты и пишутся.

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

    Например, возьмем простой проект — калькулятор (имитирующий реальный калькулятор с памятью, это важно!). Написать тесты на сами функции — тривиальная задача. А в чем здесь наиболее вероятны ошибки? Например, в таких последовательностях нажатий кнопок: "5", "+", "=", "=" (для тех, кто не знает — попробуйте на калькуляторе Windows или на реальном). И тестировать здесь нужно не отдельные операции, а их связки.
    Если посмотреть на любой объект со стороны теории, то он выглядит как конечный автомат. И вызовы его методов меняют внутреннее состояние, после чего вызовы методов могут поменять принцип своей работы. Следовательно, нужно тестировать не отдельные вызовы, а сценарии.

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

    Вот так-то.
  • Знаешь ли ты JAVA, %username%? Часть вторая
    0
    Бинго — 7 из 7 правильно :-)
  • Хитрые задачи по Java
    +1
    Все, кроме 3, ответил корректно.
    Уже потом про P в HEX-формате вспомнил )
  • Знаешь ли ты JAVA, %username%?
    0
    6 из 10 верно, еще на двух пролетел по невнимательности :-)
    На этот раз правильно ответил на 3, 4, 5, 6, 7, 10.
  • Научиться программировать сложнее, чем кажется
    0
    Или под IE6-11, чтобы везде более-менее одинаково было. :-)
  • Научиться программировать сложнее, чем кажется
    0
    Ваш P.S. мне сильно напоминает мой стиль. :-)
    Я некоторые игры начинал с начала раз пять, прежде чем прошел до конца.
    А некоторые надоедали намного раньше, что даже удалял до прохождения — слишком однообразный принцип прохождения получался.
  • Научиться программировать сложнее, чем кажется
    0
    Все сходится к идее, что в ВУЗ студентов нужно пускать после пары лет работы по специальности :-)
  • Научиться программировать сложнее, чем кажется
    0
    А это уже вопрос организации процесса обучения.
    Если учить ставят людей, которые не разбираются в предмете, все заканчивается плачевно.
    P.S. Фишка в том, что "предмет" со стороны ученых и со стороны работодателя несколько различаются...
  • Научиться программировать сложнее, чем кажется
    0
    Дело в том, что заказчики, как правило, НЕ являются аналитиками.
    А программисты склонны принимать их "требования" в качестве ТЗ.
    А все потому, что вначале нужно научиться понимать других людей, а уже потом — программировать или требования писать...
  • Научиться программировать сложнее, чем кажется
    0
    "Скучные" задачи, как правило, монотонны, т.к. требуют повторяющихся действий.
    Соответственно, что делают настоящие разработчики в этом случае? Правильно, устраняют дублирование. В том числе дублирование в методе разработки. Это могут быть генераторы кода, конструкторы форм и т.д. — любой способ хорош. Написание одинакового кода — признак недоработки или недостаточной квалификации, чтобы увидеть эту одинаковость и суметь элегантно ее устранить. :-)
  • 8 принципов планирования разработки, упрощающих жизнь
    0
    Хороший аналитик экономит время разработчика этак раза в три. :-) При этом попутно снижая общий фоновый уровень негатива по поводу сроков. Вопрос, как определить, хороший перед тобой аналитик или не очень...
  • Что делать, если программировать становится скучно
    +1
    И если руководство считает, что разработчик должен «делать то, что нужно», а отсутствие интереса — это «личные проблемы», то это просто неадекватный менеджмент, со всеми вытекающими. Самомотивация для достижения нужного уровня концентрации также отнимает время, и от этого никуда не деться.
  • Что делать, если программировать становится скучно
    +1
    Лично за собой замечал (ибо регулярный тайм-менеджмент) следующие временные показатели.
    При отсутствии интереса к текущей деятельности производительность падает в 3-4 раза (!).
    Сравнивал временные затраты по задачам аналогичной сложности.

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

    И наиболее эффективно проблему в данном случае, ИМХО, нужно решать совместно с руководителем (команды, отдела и т.д.), который понимает суть процесса и присущие ему проблемы. Если со стороны руководства не будет понимания проблемы, затраты гарантированно будут выше, а заинтересованность разработчика в проекте — ниже.
  • Маленькие хитрости Java
    0
    instanceOf — не ООП-подход.

    Остальные аргументы слабее в данном случае.
  • Маленькие хитрости Java
    0
    Насчет сложения строк в цикле.

    Если это какой-нибудь legacy-код разбора XML, то в результате сбора строчки размером в 2 Mb можно потерять несколько драгоценных секунд. :-)
  • Маленькие хитрости Java
    0
    все зависит от того, насколько равномерно распределены элементы и отсутствие коллизий


    <irony> Ага, для массивов все именно так и происходит. :-) Прощай, скорость. :-) </irony>
  • Маленькие хитрости Java
    0
    Массив реализует ровно два интерфейса — Cloneable и Serializable.
    Об этом явно написано в JLS (который Вы, скорее всего, еще не открывали :-) ).
  • Маленькие хитрости Java
    0
    Только получим его не на проверке размера, а на обращении к «просроченному» итератору в случае foreach-нотации.
    В случае обхода List'а через size() exception'а не будет в случае обращения по индексу (в случае отсутствия конкурентного изменения несколькими потоками), однако рискуем пропустить несколько элементов в случае удаления элементов из коллекции без изменения переменной цикла. Иногда замечается у студентов-нубов, переползающих с C/C++.
  • 10 главных ошибок масштабирования систем
    0
    Немного оффтоп. :-)

    Если такой скилл — «гуглить».
    Некоторые люди находят таким способом то, что другие найти почему-то не могут.
    Потому что чтобы правильно написать поисковый запрос, нужно немного понимать принципы, по которым строится поисковая выборка.
    И это скилл также нужно прокачивать, объясняя, почему один запрос лучше другого.
  • Перевод. Срезаем углы: почему rails может убить ruby
    0
    Именно поэтому я не стал переходить с Java на Ruby.
    Красиво, быстро…
    Но когда нужно что-то понять в этом огромном множестве библиотечного динамического кода…
    И никакая IDE тебе не поможет, ибо она, в основном, оперирует статикой, т.к. анализировать динамику очень долго.

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

    IMHO, наиболее крутым было бы решение, которое бы имело два режима: framework и business.
    Причем режим framework должен быть доступен только при инициализации приложения, а при переходе к business-коду уже ничего не должно меняться в мета-структуре языка.
    Тогда этого позволило бы нашим IDE прогнать весь код из framework, построить индексы по всем получившимся mixin'ам и т.д., и в коде основной business-логики после этого уже можно бы было ориентироваться.

    Если framework меняется нечасто (хотя и чаще, чем появляются новые версии языков программирования :-) ), то такой подход позволит сочетать в себе плюсы и динамики, и статики.
  • Введение в RxJava: Почему Rx?
    +2
    :-) Ух ты! Детство! :-D
  • Зомби-код. Код, живущий своей жизнью
    0
    А еще можно прямо перед релизом, когда все экстренно фиксят баги, залить какой-нибудь особо мощный рефакторинг, включающий самую важную для релиза фичу. :-)
    И все будут плакать.
  • Зомби-код. Код, живущий своей жизнью
    0
    #define union struct

    :-)

    И потом гден-ть #undef
  • Российские учёные говорят об усилении режимных ограничений
    +4
    Тут больше проблема не в закрытости исследований, а в цензуре.
    А именно в том, для чего осуществляется эта самая цензура.
    У меня лично есть подозрение, что результаты исследований таким образом могут попадать при в руки тех, кто будет делать из них деньги. А авторов просто кинут. :-)

    Всегда полезно задавать вопрос: «Кому и зачем это нужно?»
  • Как написать красивый код и завалить проект
    0
    Видимо, была убита JVM целиком. :-)
    kill -9.
  • Как написать красивый код и завалить проект
    0
    И запятые нужно ставить иногда :-)
  • На что может рассчитывать студент в IT, и какие есть вообще варианты
    0
    Ваш скрытый текст — мое прошлое :-)
  • На что может рассчитывать студент в IT, и какие есть вообще варианты
    0
    Отдача от адекватного человека начинается через 3 месяца

    Полностью согласен.
    А отдача от senior'а будет уже через неделю-две в зависимости от сложности проекта.