• Agile — это не процесс разработки, а подход к созданию продукта
    0

    А откуда в банке такие крутые, сознательные, узкие и в то же время все умеющие специалисты, и уже готовые к любым изменениям проекты?


    Похоже на очередную фантазию.

  • Россия, Германия и Япония готовятся к синтезу элементов 119 и 120
    0
    А элементы из этого острова стабильности могут оказаться полезными в материальном мире? Иными словами, может ли быть открыт какой-нибудь вибраниум или типа того?
  • Почему "=" означает присваивание?
    +2

    Правильнее сказать, что там контекст не спутать (особенно в диалектах с LET). А так это три разные операции: императивное присваивание, декларативное утверждение равенства, и сравнение.

  • Почему "=" означает присваивание?
    +4

    Тоже думаю, что проблема преувеличена, и иммутабельность здесь не при чем.

  • Держим дизайн системы под контролем, используя изолированное юнит-тестирование
    +1

    Не смог понять, в чем цель поста… Ну да ладно, допустим, я тупой.


    Но вот конкретный вопрос (иду с конца).


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

    Серьезно? 99,9% разработчиков ужаснутся при мысли о том, что им надо серьезно переделать код, намертво (если код плохой) или более-менее приемлемо (если код ок) склееный юнит- и интеграционными тестами.


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

  • О главнейшей причине существования современных JS-фреймворков
    0

    Нет, речь о раздельных доменных событиях, а не об одном-единственном update. А это очень разные вещи. MVC — это об определенном направлении зависимостей и контроля, когда модель прямо говорит, что в ней изменилось и когда. Метод render же, грубо говоря, вообще по таймеру можно вызывать.


    Почему-то JavaScript фреймворки пошли по этому пути (и соответственно, необходимости делать кучу дополнительной работы с вытекающими тормозами). Плохо то, что они называют его MVC.


    Впрочем, мы уже видели такую массовую подмену понятий — толстые контроллеры, выдаваемые за MVC, или целая экосистема Rails, тоже выдаваемая за MVC.

  • О главнейшей причине существования современных JS-фреймворков
    0

    Не уверен. В них (и в примере в статье) нет доменных событий,
    зато есть метод render, относящийся не пойми к чему, и якобы "декларативный" подход.

  • О главнейшей причине существования современных JS-фреймворков
    0

    Боюсь задать глупый вопрос (весьма далек от всего этого), но все же.


    Что мешает сделать каноничный MVC (например, с Active Model)?


    Заводим:


    1. Модель со стейтом и событиями (в данном случае — NewAddress, DeleteAddress), реализующая шаблон Observer.
    2. Вью, подписанную на изменения модели (в данном случае — добавление некоторого html на NewAddress и удаление на DeleteAddress).

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


    ?

  • БАДы — это рэкет объёмом в $30 млрд: что на самом деле рекомендуют специалисты
    +1
    > А в случае спортпита молодежь, начитавшись качковских статей для стероидных мутантов

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

    Наркотики, гепатит и спортпит, ага…
  • БАДы — это рэкет объёмом в $30 млрд: что на самом деле рекомендуют специалисты
    0
    > спортивное питание

    а между тем спецпитание вовсю используется в медицине, и в нефрологии в частности. Например, www.bbraun.ru/cps/rde/xchg/cw-bbraun-ru-ru/hs.xsl/products.html?id=00020742600000000565&prid=PRID00002983
  • Реальность повторного использования
    +1

    В том и дело, что надо проектировать под неопределенность — делать слабосвязанные взаимозаменяемые части.

  • Реальность повторного использования
    –1

    Полная лажа. Выделение и переиспользование знаний, технологий, решений, деталей, чего угодно — основа прогресса.


    Стройте все изначально из правильных частей и не будет проблем с выделением.

  • Шаблон проектирования “минисценарий с проверкой противоречий”
    0

    Имхо у Вас в самом изначальном примере дублирование знаний (действие можно привязать к типу лица, а можно — к типу договора), и отсюда все проблемы. Атрибуты по-возможности должны быть ортогональны.

  • Проблемы при работе с кэшем и способы их решения
    –2

    Прочитайте, пожалуйста, мой коммент внимательнее. Сам код, а не что он делает, плох.

  • Проблемы при работе с кэшем и способы их решения
    –1
    Посмотрите на такой простой кусочек кода:

    Если это продакшен-код (или создан из такового), тогда он очень, очень плох… И дело не в неправильной работе с кешом, а в самом коде. Да даже и пример можно было сделать, используя нормальные практики программирования, заодно выиграв в читаемости.

  • Современный PHP без фреймворков
    0
    Огромное количество проблем в работе, совместимости и эксплуатации уязвимостей на моей памяти были связаны со словом «автоматически». А если не подгрузит «автоматически»? С инклудом хоть сразу видно будет.

    Вы гораздо больше наделаете ошибок, если будете загружать файлы руками.


    А если не подгрузит «автоматически»? С инклудом хоть сразу видно будет.

    Просто надо знать, как работает твой инструмент. И тоже все будет сразу видно.

  • Современный PHP без фреймворков
    0
    Где в Symfony сильная связанность

    Ну на самом деле куча бандлов, идущие как стандартные, представляют собой месиво, гвоздями приколоченное к некоторым основным компонентам (типа Доктрины). Как будто сделано все, чтобы показать, что наличие интерфейсов еще не означает слабую связанность :).

  • Современный PHP без фреймворков
    –1
    микрофреймворк — задачу и смежные с ней

    Нет, смысл совсем не в размере, охвате и пр.


    Суть в направлении контроля. Фреймворк вызывает Вас. Вы вызываете библиотеки.


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

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

  • Современный PHP без фреймворков
    +1
    которые и не библиотеки на самом деле а микро-фреймворки

    Нет, это именно библиотеки. А Вы не понимаете разницу между библиотекой и фреймворком.


    Статья — норм, заголовок — вполне точен.


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

  • Как объяснить родственникам кто вы в мире ИТ на примере булочек
    +5
    Как объяснить дебиродственникам кто вы в мире ИТ на примере булочек

    Лучше вообще никак не объяснять, а так — тем более.

  • REST API Best Practices
    0

    Сначала объясните, пожалуйста, что Вы понимаете под стандартным REST-подходом. Чувствую, имеет место недопонимание. На всякий случай напоминаю, я отвечал на коммент, где предлагалось делать так:


    500 {ok: false, message: 'SMTP relay fail: code 1234', trace: ['/path/to','/bla/bla','/lib/smtp',...]} — ошибка кода. когда возник необработанные ексепшн

    500: {ok: false, message: 'user is not activated yet'} — ошибка бизнесс-логики
  • REST API Best Practices
    +1

    По-вашему получается, что 200-е нельзя разделить между собой, а 500-е — можно.


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


    А сама проблема лежит глубже — REST смешивает транспортный и прикладной уровень, и подход "200 на все" эту проблему решает (правда, делая REST не нужным вообще).

  • REST API Best Practices
    +1
    всё остальное (и не важно, пропала сеть, неправльный урл, ошибка сервера, ошибка БЛ, да хоть апокалипсис) — это не получилось, тобишь ошибка.

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

  • REST API Best Practices
    0

    Плюс к экзепшенам, правильно разделенных по типам. Они позволяют строить действительно структурированный код. Если ошибка при вызове метода API была на уровне транспорта (а в случае REST API это еще надо разобраться, ха-ха) — бросаем исключение технического типа и не обрабатываем его на уровне бизнес-логики.

  • Выход из тупика тимлида: у Software Engineering Manager больше зарплаты, лучше перспективы — и мы их нанимаем пачками
    0
    когда нагрузка по непосредственной работе с кодом осталась в прошлом, уступив исключительно менеджерским обязанностям,… деятельность становится более понятной и прозрачной окружающим

    Весьма спорно...

  • Почему в Петербурге так сложно построить карьеру VP of engineering
    0

    Понятно, спасибо.


    Мое мнение — надо стремиться делать специализацию ортогональной другим свойствам организации. Весь прогресс построен на специализации, и ее роль будет только расти.

  • ZX Spectrum 128k своими руками
    0
    > Так в 286/386 машинах точно также страничная адресация по 64К

    Это совсем разная страничная адресация.

    В ZX-128 16K банки памяти «втыкались» в одно из двух фиксированных мест в адресном пространстве в 64K записью команды в определенный порт. Проц всегда работал с 64К-пространством и даже не знал, что там сейчас подключено.

    В 286 — это была просто хитрая адресация сегмент: смещение. Сами сегменты накладывались друг на друга, и это было реализовано аппаратно. Адрес перехода можно было указать или абсолютный в формате сегмент: смещение, или относительный (относительно текущего IP, если говорить о переходах), но не более 32K в ту или другую сторону. Отсюда размер com-файлов (кстати, они могут быть больше 64K) — важно то, что они не были релоцируемыми, все переходы в них относительные.
  • ZX Spectrum 128k своими руками
    0
    > Я как раз сказал что использовать адресное пространство портов

    OMG, чуваки, это была первоапрельская шутка от ZX Ревю, легенда которой заключалась в том, что к 64K можно добавить еще софтовым путем, «всего лишь» задействовав адресное пространство портов. Естественно, это не возможно по целому ряду причин.
  • ZX Spectrum 128k своими руками
    0
    > Вроде как она свопинг программ на 128 организует

    «Идея» там была такая: у нас есть 64К адресов в памяти, но ведь есть же еще 64K портов, давайте их юзать как память :)
  • ZX Spectrum 128k своими руками
    0
    > 8-битные недокомпьютеры были исторической ошибкой

    8-ми битные компьютеры — это то, что перевернуло ход истории. То, благодаря чему Вы сейчас пишете эти строки.

    Давайте еще детей выкинем, нафиг они нужны, ничего не умеют.

    > создать из 8-битного микроконтроллера компьютер

    Да Вы вообще не владеете предметной областью.
  • Чего из Rust мне не хватает в C
    +1

    Пример кроссплатформенного редактирования скомпилированной функции в студию, пожалуйста. Сравним с вызовом eval().

  • Почему в Петербурге так сложно построить карьеру VP of engineering
    0
    Мы верим в специализацию. У нас есть команда, сотрудники которой только и делают, что пишут юнит-тесты.

    А как же полноценные команды, владеющие продуктом, DevOps, и тому подобные веяния? Хотелось бы услышать побольше мыслей/идей/обоснований, т.к. давно волнует этот вопрос. Спасибо.

  • «Восемь бит»: о звуках в старых играх
    0
    Коли уж пошла такая пьянка:
    Quazatron: www.youtube.com/watch?v=Y2eSjTdWYsU
    Savage 2: www.youtube.com/watch?v=IR1TWDocL_M&t=7s
  • Кто такой программист?
    +1

    И даже это больше говорит о Вас, нежели о мире.

  • Кто такой программист?
    0

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

  • Кто такой программист?
    +2
    Хочу заметить, что молодые «программисты» не знают даже основы школьного курса математики!

    Вы сделали этот вывод на основании одного эпизода?

  • Кто такой программист?
    +1

    Я понимаю, продемонстрируйте свои решения, созданные под влиянием мышления, отточенного матаном.

  • Кто такой программист?
    –2
    если ты таксист, езжай ровнее, чтобы никого по салону не бросало.

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


    Кстати,


    У меня вообще нет никакого высокомерия по отношению к разработчикам, матана не ведающим.

    Пожалуйста, продемонстрируйте Ваш код. Или пример декомпозиции задачи. Или набросок архитектуры приложения. Или схему БД. Или книгу статейку какую-нибудь. Главное, чтобы там был матан. А мы оценим, и, может быть, восхитимся.

  • ZX Spectrum 128k своими руками
    +1
    > Но, будучи однажды налаженным, не сбоил больше никогда.
    Это большое преувеличение.
  • Где найти и как выбрать тимлида
    0

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


    Правильных решений задачи — много. И других важных задач тоже много.


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