• Рекрутерам посвящается…
    +4
    " Фундаментальные знания по информатике с каждым месяцом становятся всё более бесполезными и узкоспециализированными."

    Бугагашечки. Узкоспециализированные фундаментальные знания это чтото новое.

    "Почему я так легкомысленно отношусь к фундаментальным знаниям? А очень просто. Я закончил 3й курс университета."

    Ну это уж совсем бугагашечки. Я рыдалъ.
  • Интересные задания для джуниора — миф или реальность?
    0
    Не тупиковая — забить на чрезмерно узкую и однобокую специализацию, понять, что Java и технологии вокруг нее это всё мелочь, и развиваться как программист.
  • Интересные задания для джуниора — миф или реальность?
    0
    То есть вы не согласны, что чистый XXX-программист (вместо XXX подставить что угодно, начиная с Java) — это ни фига не специалист? Ну, чтобы иметь право быть несогласным с таким мнением, надо как минимум много лет как не быть джуниором.
  • Перенос Linux на другой компьютер
    +1
    После такого заголовка ожидал увидеть рассказ про перенос с x86_64 на sparc32…

    Так же не ясно, на фига донора-то выключать? cpio или даже tar через netcat прекрасно справились бы. А вообще, практически во всех дистрибутивах есть и штатные средства для клонирования. Скорее всего, федора не исключение.
  • Пишем свой Windows service
    0
    Ну, вот примерчик реализации (для Java и Clojure):

    clojure101.blogspot.com/2009/05/creating-clojure-repl-in-your.html
  • Пишем свой Windows service
    0
    Есть и вариант наоборот (для .NET и Java и вообще любой рефлексивной среды работает идеально) — встроить в приложение консоль для отладки. REPL какого либо скриптового языка, к которому можно подцепиться telnet-ом, и не прерывая работы выполнить произвольный код в контексте приложения.
  • Пишем свой Windows service
    0
    Все эти симптомы говорят, что реальная ошибка где-то вовсе за пределами этого блока кода. Довольно редкий случай в .NET, правда, если unmanaged-вызовами особо не баловаться.
  • Пишем свой Windows service
    +1
    А вы лог флашили?

    Вообще, первое правило — писать вывод логов и ассерты сразу и везде. Это, кроме всего прочего, еще и дополнительные аннотации к коду, проще читать потом будет. Нельзя проверки просто навешать потом на код вокруг подозрительного места — ведь реально ошибка может быть где-то еще, далеко от того, где все сломалось.
  • Пишем свой Windows service
    +4
    Вообще интерактивный дебаг как бы не нужен. Точнее, он очень нужен для посмертного вскрытия корок, и для отладки чужого и очень плохого кода.

    А свой код можно и нужно изначально писать так, чтобы пользоваться правильными техниками отладки. Без всяких там break points и прочего.
  • Интересные задания для джуниора — миф или реальность?
    +7
    Впервые вижу такое определение «интересной задачи», где интерес пропорционален номеру версии всяких мелких библиотечишек.
  • Пишем свой Windows service
    +15
    Для «вменяемой отладки» достаточно писать вменяемые логи и расставлять вменяемые ассерты.

    О, поколение, испорченное дебаггерами…
  • Каково соотношение тестировщиков и разработчиков в вашей компании?
    0
    Вот вы опять. Я не говорил, что тестер должен «разрабатывать» GUI. Он должен участвовать в его проектировании, на каждом этапе. GUI надо начинать тестировать на живых людях еще когда он существует в виде картинок в тетрадке.

    И проиграли именно вы. Вы несете несусветную чушь, да еще и с чванством и с апломбом. Это глупо. Ваше примитивное мнение не имеет абсолютно ничего общего с устоявшимися в мире практиками.
  • Начальники и как с ними жить
    –1
    В той стране, где орать по уставу положено, идут сами.
  • Начальники и как с ними жить
    –3
    В армию идут сознательно, и ор выслушивать готовы. Там по другому и нельзя, собственно, там вообще из людей личность выдавливать надо и палками вышибать, для их же блага. Так что я бы не стал сравнивать армию и работу.
  • Начальники и как с ними жить
    +8
    Если человек смеет повышать голос, то это паршивый человек, в общем и целом. Работать с паршивым человеком глупо — ничему хорошему у него не научишься, и следовательно никакого смысла оставаться на такой работе нет.
  • Начальники и как с ними жить
    +4
    А на фига жить с начальником, который может себе позволить наорать на подчиненного? Странные вы советы даете. Типа, вас имеют, а вы терпите.
  • Некоторые малоизвестные факты о программировании
    0
    Ну, график несколько некорректный. Многочисленные измерения показывают, что средний инженер продуктивен в лучшем случае 4 часа в день. Остальное время он пинает балду, чаи гоняет, делает вид, что думает (без результата), интернет читает, журнальчики. Если всю эту деятельность исключить, то можно уходить домой и раньше.
  • Некоторые малоизвестные факты о программировании
    0
    У меня как раз за несколько лет такая продуктивность и была. Код с Fortran 77 на C++ частично переписывался (а местами и на C#).
  • Некоторые малоизвестные факты о программировании
    0
    У меня одно время была продуктивность в минус пять сотен строк в день. Код чистил.
  • Каково соотношение тестировщиков и разработчиков в вашей компании?
    –1
    "Оно может и так, но к сожаленью 80% тестировщиков даже базовых основ программирования не знают, куда уж там до умения…"

    Скажите, у вас какой-то тестировщик жену увёл, да? Какой-то вы на них озлобленный.
  • История успеха русского шестнадцатилетнего юноши
    +1
    Знаете, все, кто рассуждал так, как вы, оказывались в конце концов подонками. Подонкам нужно оправдывать себя тем, что «все такие же».
  • Каково соотношение тестировщиков и разработчиков в вашей компании?
    0
    Скиллы программиста и тестировщика лишь немного пересекаются. Мало какой программист может быть хорошим тестировщиком. Не потому что «скучно», отставьте своё подростковое высокомерие, а потому что просто не может, мозги по другому заточены, нет нужных знаний и умений.
  • Каково соотношение тестировщиков и разработчиков в вашей компании?
    0
    Опять глупостями разговариваете. Когда ж словами говорить научитесь?

    Вы узколобо упускаете множество вариантов. Например:

    — Никакого GUI не было, но вдруг потребовалось таковой прикрутить

    — GUI было, но концепция поменялась и GUI приходится переделывать

    Вы очевидно мыслите в терминах проектов, где 90% функциональности это UI. Я говорю про проекты, где на долю UI приходится 1-5%.
  • Некоторые малоизвестные факты о программировании
    0
    80% рутины получается как раз если не думать. А если думать, то ее будет процентов 20. Как раз самое то, чтобы дать мозгам отдохнуть (или чтобы посадить на эту рутину студента).

    И если думать, то и тесты будут куда как более адекватными. Видал я результаты бездумного применения TDD — жалкое, душераздирающее зрелище!
  • Некоторые малоизвестные факты о программировании
    +1
    Вы о программировании говорите, или о формошлёпстве? К формошлёпству ваши слова еще (с очень-очень большой натяжкой) применить можно. К программированию — нельзя.

    Я пишу компиляторы. Так что, соотношение именно такое, как я описал. Или я сяду тупо кодировать какую либо ad hoc оптимизацию, которая мне в башку пришла, или даже известную оптимизацию, но сделаю в лоб, то получится много весьма бестолкового кода. А если я сяду с бумажкой и ручкой, и буду долго думать, то в конце концов получится 100 строк очень качественного, вылизанного кода, которые будут делать ту же оптимизацию, но гораздо эффективнее.

    К вопросу о рутине — я её автоматизирую. Я подумаю пару часов и за 10 минут сделаю автомат, который одну и ту же рутинную операцию потом будет месяцами выполнять, и это намного лучше чем если я каждый день на эту же рутину буду тратить час.
  • Некоторые малоизвестные факты о программировании
    0
    Я лучше пять часов подумаю и потом за 20 минут напишу более функциональный код, чем получился бы, если бы я все 5 часов просто кодировал. Он еще и в двадцать раз короче при этом получится.
  • Некоторые малоизвестные факты о программировании
    –1
    Это пошло с тех времён, когда какой-то идиот придумал copy and paste.
  • Некоторые малоизвестные факты о программировании
    +1
    Функциональность не пропорциональна числу строк кода.
  • Некоторые малоизвестные факты о программировании
    +1
    Конечно не один.

    en.wikipedia.org/wiki/Literate_programming

  • Каково соотношение тестировщиков и разработчиков в вашей компании?
    0
    Кстати, вы еще и врунишка. Вы не предлагали использовать метаязык для «улучшения качества кода». Вы предложили его использовать как убер-панацею, которая сделает трудоемкое ручное тестирование ненужным. Разницу не видите? Ну да куда уж вам, вы же «аналитические системы» разрабатываете. Логика вам в работе не требуется, вот вы ей и не владеете.
  • Каково соотношение тестировщиков и разработчиков в вашей компании?
    0
    На соседнее сообщение ответить слабо?

    Читать выборочно — это хамство и глупость. Ну да с вами и так уже давно всем всё ясно.
  • Каково соотношение тестировщиков и разработчиков в вашей компании?
    0
    Смотрите мой последний блогпост. Там используется метаязык для описания компилятора Си, в 3000 строк кода с комментариями.

    Так что не буду доказывать, что это «чушь». В конце концов, метаязыки — это моя специальноть. А вот почему все не так просто с промышленными компиляторами я вам уже объяснял. Вы, как и положенно упертым и самоуверенным людям, читаете очень выборочно. С вами невозможно вести нормальную дискуссию, все неудобные вам аргументы вы просто игнорируете. Своих же аргументов, кроме anecdotical evidence, у вас нет вообще.
  • Каково соотношение тестировщиков и разработчиков в вашей компании?
    0
    Ну так что, кроме смешного чванливого бла-бла-бла, будет что либо конкретное?

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

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

    Что, будете снова свою чванку включать и заливаться, что мол вы там все дураки, а вот грамотный архитектор, руку набивший ажно на Аналитических Финансовых Системах (читать с придыханием) вам быстро бы придумал опупенные абстракции и гламурные метаязыки, из которых бы при этом генерился заоптимизированный до крайности код? Не советую. Не лезте в область, в которой вы настолько полный ноль.

    И это я только про синтаксис. Семантику языка тоже, знаете ли, распрекрасно можно на красивом и простом метаязыке описать, благо, тема давно вдоль и поперёк изученная, способов описания операционной и денотационной семантик множество. Но только это будет игрушка. Идеально для reference implementation, неприминимо для практики. Ну да разработчики финансовой аналитики конечно же гораздо лучше всё знают, просто они настолько суровы, что знания при себе держат, на CiteSeer никаких следов по себе не оставляют.
  • Каково соотношение тестировщиков и разработчиков в вашей компании?
    –2
    Зачем говорите глупостями? Зачем свой куцый частный опыт проецируете?

    Во первых, специалисты по юзабилити обязаны быть тестировщиками. Вам понятие user experience testing ничего не говорит? Во вторых, часто GUI появляется намного позже, чем функциональность. Если вы ничем кроме самого примитивного формошлепства не занимались, то вряд ли поймете, почему оно так бывает.
  • Каково соотношение тестировщиков и разработчиков в вашей компании?
    0
    Ясно, вы не имеете ровным счетом ни малейшего представления о разработке компиляторов. Поздравляю. Упёртости, чванства и самоурвенности у вас хоть отбавляй — если бы еще знания были на том же уровне. Но обычно так не бывает.

    Вы, кстати, уже облажались со страшной силой про алгоритмическую сложность. Теперь пытаетесь еще глубже опозориться, неся несусветную чушь про «метаязыки». Скажите честно, вам что, совсем, нисколечко не стыдно?
  • Каково соотношение тестировщиков и разработчиков в вашей компании?
    –1
    Нет, это до вас так и не дошло то, о чем я говорю. Что работа тестировщика не в том, чтобы «ошибки» искать. Это тоже, да, но есть и гораздо более важные задачи, которые разработчик выполнить не может. Это и user experience testing (юзеры из разработчиков херовейшие получаются), и занудное тестирование на соответствие букве спецификации (мало какой разработчик сможет вогнать себя в ментальное состояние, позволяющее хотя бы осилить пару страниц какого либо стандарта).

    Про метаязык для описания спецификации — фиг вам. Не бывает. Спецификации как правило пишутся идиотами. Они не поддаются какой либо формализации.

    Так что вы тут не теоретизируйте. Теоретизирования не интересны. Сможете такой метаязык продемонстрировать — тогда будет о чем поговорить. Такой, чтобы, например, кривую и противоречивую спецификацию C99 мог описать.
  • Язык Go с точки зрения PHP-разработчика
  • Язык Go с точки зрения PHP-разработчика
    0
    Пардон, не понял сразу, на какой вы стороне.
  • Язык Go с точки зрения PHP-разработчика
    0
    the term strong typing is used to describe those situations where programming languages specify one or more restrictions on how operations involving values having different data types can be intermixed. Its antonym is weak typing

    Прочитайте еще раз процитированное. Внимательно. Это никак не относится к статической типизации, то есть к типизации во время компиляции. Это только лишь о том, что есть связанные с типами ограничения. В рантайме они применяются, или во время компиляции — не уточняется.
  • Язык Go с точки зрения PHP-разработчика
    +1
    Термин не очень-то строгий, много значений:

    en.wikipedia.org/wiki/Strongly_typed_programming_language