• Я порчу разрабам жизни своими код ревью и больше так не хочу
    +2
    Мы, когда-то, сильно облегчили процесс Code Review тем, что внедрили в работу Online Catalog of Refactorings. Раньше он выглядел немного по другому, там была краткая информация, диаграмма, и в правом верхнем углу — номер страницы книги, на которой разработчик мог получить исчерпывающую информацию. Использование этого каталога сильно экономило время, достаточно быстро повышало общий уровень разработчиков, устраняло эмоциональность из процесса. После выпуска в этом году второго издания книги, каталог был переделан, по моему, сугубо субъективному, мнению, не в лучшую сторону. Но он все еще остается полезным для процесса Code Review. Так же заметно устранили эмоциональность из процесса каталоги Code Smells так как они вносили в разногласия достаточно авторитетную аргументацию, которую признавали все.
  • Оценка новых проектов
    0
    VolCh говорит правильно, есть такая проблема (с оценкой в частности, и с мотивацией вообще) в аутсорсе. В продуктовых компаниях с этим существенно легче.

    А вообще, существует разница между оценкой (estimate) и обязательством (commitment).

    Есть ряд мероприятий для повышения точности оценки в Agile, например, в XP оценки делаются двухфазно, сперва Story оценивается коллективно, затем Task оценивается индивидуально. Кроме того, постоянно ведутся метрики и отслеживается динамика ресурсов, затрачиваемых на реализацию тикетов, предсказуемость эстимитов, ресурсы, отвлеченные на багфиксы и т.п., поскольку они свидетельствуют о качестве проектирования и состоянии кодовой базы. Но автор, по всей видимости, имел ввиду, оценку для проекта целиком, т.е. Waterfall.
  • Где Agile ужасен, особенно Scrum
    0
    А кто-нибудь вообще понимает?

    Я с вами полностью согласен. Основная причина неработающего Agile заключается в том, что люди не понимают что это такое, и как его применять. Это как в притче Кент Бека про автомобиль, когда водитель заехал не туда, и начал обвинять в этом автомобиль.

    Работающий Agile — это действительно редкость, особенно Scrum. Начнем с того, что Scrum — «is a framework within which you can employ various processes and techniques.». Это самое важное, что нужно знать про Scrum, и именно этим он отличается от полноценных методологий вроде XP. Итак, Scrum — это не методология, и в методологию его еще нужно превратить. Но об этом чуть позже.

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

    1. Agile во многом изобрели архитекторы. Одну из самых первых и, по сей день, одну из самых эффективных Agile методологий XP изобрел Кент Бек. Среди подписантов Agile-manifesto присутствует ряд авторитетных архитекторов.
    2. Agile означает гибкий. Достижение гибкости программы — это вопрос качества проектирования. Грубо говоря, Agile — это значит достигнуть такого качества проектирования, которое позволит дешево внедрять проектные решения не заблаговременно (up-front), а итеративно, уже в процессе разработки и развития продукта, с учетом обратной связи от практического использования продукта. Иными словами, наладить Agile-разработку могут только специалисты, компетентные в вопросах проектирования и архитектуры, иначе Agile просто обречен, но не все могут это заметить на ранней стадии.

    Вся суть Agile выражена в одном выражении Кент Бека: «If a flattened change cost curve makes XP possible, a steep change cost curve makes XP impossible.».

    Agile — это использование бизнес-выгод, которые дает качественное проектирование. Это возможность управлять бизнес-рисками в условиях неопределенности. Правда, возможно это только в том случае, если стоимость изменения программы низкая.

    А теперь самое интересное. Изначально Scrum содержал технические практики заимствованные из XP. Однако, позже решение о выборе конкретного набора технических практик было отдано на откуп самим разработчикам. Они считали, что это сдерживает проникновение Scrum в массы. Именно поэтому, Scrum — это не методология, а framework (каркас, скелет), на который еще необходимо нарастить практики.

    К сожалению, в Scrum отсутствует именно то, что поддерживает стоимости изменения программы низкой и делает Agile возможным. Одним из вариантов решения этого вопроса является комбинация Scrum и XP. На практике же разработчики не уделяют этому вопросу должного внимания, и часто вообще не используют никаких технических практик, превращая Scrum в обычный Waterfall с итеративным планированием, но при этом рост графика стоимости изменения кода не позволяет сделать разработку гибкой.

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

    Очень тяжело сделать развернутый ответ в краткой форме, поэтому, я думаю что приведенная мною выше ссылка ответит на все, что я упустил.
  • DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе
    0
    По вопросам управления бизнес-логикой и логикой приложения, статья, конечно, вызывает ряд вопросов, но это все становится ожидаемым, если учесть контекст статьи: «я пишу эти статьи, чтобы помочь себе в обучении.» Момент неполного раскрытия вопросов присутствует, но это неизбежно на стадии обретения опыта. Сам факт обретения новых горизонтов знаний уже сам по себе вызывает похвалу.
  • Работа тимлидом в 2018-ом году
    0
    Я, знаете ли, не до конца уверен, что его эффективность была всего лишь результатом применения «четырех принципов». Дело в том, что в истории нет абзаца «и вот мы внедрили эти четыре принципа в команде, и все стали работать так же быстро как он».

    Хорошее замечание, спасибо, добавил пару строк.


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

  • Работа тимлидом в 2018-ом году
    0
    Одной из самых больших проблем в компании было постоянное превышение сроков по задачам.

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

  • Работа тимлидом в 2018-ом году
    0
    Мы сразу говорим, что самое главное для нас это лишь уложиться в сроки решения задачи (называет сам исполнитель) и в конце показать рабочий код в репозитории.

    Тут вы немного нарушаете роль оценки и планирования в Agile. И раз уж Вы решили внедрить Scrum — одну из Agile методологий, то разобраться с ее ролью придется. Видеоролик на эту тему от одного из 17 подписантов Agile манифеста https://youtu.be/eisuQefYw_o

  • Прощайте, микросервисы: от ста проблемных детей до одной суперзвезды
    0
    Если коротко, то
    «My general rule of thumb: don’t violate DRY within a microservice, but be relaxed about violating DRY across all services. The evils of too much coupling between services are far worse than the problems caused by code duplication. There is one specific use case worth exploring further, though.»
    Если интересуют подробности этой проблемы, то их полностью раскрывает Sam Newman в «Building Microservices. Designing Fine-Grained Systems». Микросервисы действительно поощряют дублирование кода, но только в тех случаях где это позволяет снизить сопряжение (coupling).
  • Прощайте, микросервисы: от ста проблемных детей до одной суперзвезды
    0
    Никакого развивающегося проекта не бывает без рефакторинга. И, кстати, 90% встретившихся мне менеджеров не понимают, что такое Agile/SCRUM и как он работает.
    Причины рефакторинга бывают разными. Бывают причины потому что в мастер-бранч мержится некачественный код. Т.е. в команде отсутствует Collaborative Development. В таком случае Agile никак не оправдывает низкое качество кода, и даже, более того, предписывает его не трогать, пока он не мешает и не влияет на экономику разработки. А бывает рефакторинг как элемент реализации Evolutionary Design и YAGNI. Тогда — да, это Agile. Но в таком случае, это не рефакторинг, а Evolutionary Design.
  • Прощайте, микросервисы: от ста проблемных детей до одной суперзвезды
    0
    mad_nazgul, Вы, к сожалению, ошибаетесь. Если интересны подробности, то Sam Newman (коллега Мартина Фаулера по ThoughtWorks) отвечает на этот вопрос в своей книге “Building Microservices. Designing Fine-Grained Systems”.
  • Прощайте, микросервисы: от ста проблемных детей до одной суперзвезды
    0
    Все правильно описали. Называется этот подход Integration Database.
  • Прощайте, микросервисы: от ста проблемных детей до одной суперзвезды
    0
    сделать подобие LEFT JOIN между двумя сервисами
    Пусть он почитает книгу «NoSQL Distilled. A Brief Guide to the Emerging World of Polyglot Persistence.» by Pramod J. Sadalage, Martin Fowler. Там описано как решаются такие проблемы в распределенных системах, хотя книга и не про микросервисы.
  • Прощайте, микросервисы: от ста проблемных детей до одной суперзвезды
    0
    Микросервисы применимы не везде. Есть вещи, которые не зависят от уровня программистов. Наибольшим препятствием для использования микросервисов являются CAP-теорема и распределенные транзакции. Поэтому микросервисы применимы лишь там, где эти проблемы допускаются бизнес-логикой.
  • Прощайте, микросервисы: от ста проблемных детей до одной суперзвезды
    +1
    можно делать микросервисы внутри монолита
    Только… в таком случае они будут называться Bounded Context.
  • Hibernate — о чем молчат туториалы
    0
    Проблема 1. Наследование и полиморфные запросы.
    В объектной модели есть наследование, а в реляционной нет.

    1. PostgreSQL implements table inheritance
    2. Class Table Inheritance
    3. Single Table Inheritance
    4. Concrete Table Inheritance
  • Вопросы для собеседования бэкенд-разработчика
    0
    Раскрытие состояние объекта действительно нарушает инкапсуляцию. Объект предоставляет поведение, и скрывает состояние. Именно поэтому в некоторых языках программирования интерфейсы позволяют декларировать только методы, но не свойства.

    Мысль заключается в том, что геттеры/сеттеры предоставляют доступ к состоянию, но не предоставляют поведения. Т.е. придают объектам свойства структур данных, образуя собой объекты-гибриды, недостатки которых хорошо раскрыл Robert C. Martin в своей книге «Clean Code».

    Посмотрите, как устроены правильные OO-языки (Smalltalk, Objective-C, Ruby и т.д.). Объекты общаются посредством сообщений. Интерфейс — это протокол взаимодействия. Геттеры/сеттеры никакого взаимодействия не осуществляют, и в большинстве случаев (разумеется, не всегда) просто воплощают Code Smell под названием Feature Envy.

    Посмотрите письма Alan Kay, того самого, кто и провозгласил термин OOP:
    «I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning – it took a while to see how to do messaging in a programming language efficiently enough to be useful).» (Alan Kay)
    «OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.» (Alan Kay)
    Собственно, упомянутая oxidmod статья именно об этом. Письма Alan Kay можно найти в интернете, два наиболее важных из них я цитировал здесь. Кстати, статья по ссылке тоже посвящена этому вопросу, только уже на уровне паттерна «Event Sourcing».
  • Горе от ума, или Почему отличники пишут непонятный код
    0
    Скажу честно, в нашей команде таких проблем не бывает. Мы используем значительную часть методик XP (Экстремального Программирования), и поэтому все новички у нас быстро подтягивают свой квалификационный уровень до среднего командного уровня. Разумеется, это работает только в том случае, если в команде присутствуют разработчики (хотя бы один) с хорошим опытом в проектировании.

    На ревью мы не тратим время на борьбу мнений, — обычно проблему можно классифицировать по одному из известных каталогов Code Smells (обычно используем каталог Роберта Мартина), или же проблема основана на субъективном мнении и может быть проигнорирована.

    Мы не указываем как и что исправить, — мы просто даем линку на нужный метод исправления по каталогу www.refactoring.com/catalog. Если разработчику требуется дополнительная информация — он просто смотрит номер страницы книги по ссылке (каждый метод рефакторинга имеет номер страницы), открывает книгу на нужной странице, и получает всю необходимую информацию.

    В корпоративной культуре у нас 5 книг являются обязательными для прочтения каждым разработчиком:
    1. «Design Patterns: Elements of Reusable Object-Oriented Software» by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
    2. «Patterns of Enterprise Application Architecture» by Martin Fowler, David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, Randy Stafford
    3. «Refactoring: Improving the Design of Existing Code» by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts
    4. «Clean Code: A Handbook of Agile Software Craftsmanship» by Robert C. Martin
    5. «Code Complete» by Steve McConnell

    Кроме перечисленного, инструкторы и менеджеры должны освоить несколько книг Бека по XP. Это как минимум. На практике, для опытных разработчиков, список литературы намного шире.
  • Горе от ума, или Почему отличники пишут непонятный код
    0
    Если абстракции текут, значит, инкапсуляция не выполняет своей функции по защите абстракций) Так всегда бывает когда нет должного внимания к качеству инкапсуляции.
  • Горе от ума, или Почему отличники пишут непонятный код
    +1
    У автора, безусловно, есть неплохой потенциал писать грамотные статьи, но боюсь, что в данном конкретном случае его статья еще больше запутывает и без того непонятную для многих тему качества кода.

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

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

    Но… проблема умных людей в программировании действительно существует. Хорошо раскрывает эту тему Кент Бек в книге «Экстремальное программирование». Особенно это хорошо заметно в России, где алгоритмический аспект программирования часто превосходит коммерческий аспект сопровождаемости программы.

    На самом деле, если «умному человеку» дать немного знаний по экономике разработки ПО, а книга Бека является лучшим пособием по этому вопросу, то проблема исчезает.
  • Почему опытные разработчики пишут тупой код и как распознать новичка за километр
    0
    Верно, — именно сообщения. Чтобы хорошо понимать ООП, нужно прочитать два письма Alan Kay, я цитировал их здесь.
  • Почему опытные разработчики пишут тупой код и как распознать новичка за километр
    +1
    Интерфейс — это декларирование поведения и способ управления сложностью. В хорошей программе разработчик не должен открывать реализацию. Он открывает файл с интерфейсами, и ему все должно стать понятным.
  • Почему опытные разработчики пишут тупой код и как распознать новичка за километр
    +1
    Сложность метода измеряется количеством его обязанностей. Данный пример, конечно же прост. И во многом благодаря паттерну Repository. Каждый кто хоть раз в жизни прочитал PoEAA, знает, что этот паттерн отвечает за сокрытие деталей реализации доступа к данным. Кроме того, мне не нужно смотреть его реализации для того чтобы понять, что никаких дополнительных обязанностей (проверку прав и т.п.) он не выполняет.
  • Почему опытные разработчики пишут тупой код и как распознать новичка за километр
    +1
    Все верно. Если интерфейсы ни о чем не говорят, и разработчик вынужден подсматривать реализацию, то проектирование плохое. Программа должна читаться, а не пониматься. Просто потому, что в процессе написания кода разработчики 90% времени читают программу, и плохая читаемость на 90% влияет на темпы разработки.
  • Лабораторная работа: введение в Docker с нуля. Ваш первый микросервис
    0
    верно, — «Of course, you can do a better job if you have more tools in your toolbox than if you have fewer, but it is much more important to have a handful of tools that you know when not to use, than to know everything about everything and risk using too much solution.» (Kent Beck)

    P.S.: автор действительно молодец.
  • Как выявлять и развивать таланты в IT
    0
    Agile — это и есть способ командной работы, причем, не нуждающийся в рекламе… Я обсуждаю Ваше утверждение о том, что командная работа — это сказки.

    Вероятно, случай с талантливым Риком (а это, как мне рассказывали, описан реальный эпизод) прошел мимо Вашего внимания. Ок, есть не менее интересный эпизод касательно команды, талантов и лидеров. Я лишь слегка модифицировал оригинальный текст.
    A boy went fly-fishing for the first time in the Idaho panhandle.
    After a fruitless, sweaty day in pursuit of brook trout, he and his friends headed for home. After half an hour of stumbling through dense trees, they realized they were lost. The boy started to panic—fast breathing, tunnel vision, chills. Then someone suggested a plan—they would walk uphill until they hit a logging road they knew was up there. Instantly, the panic disappeared.

    Вопрос, кто здесь лидер, кто здесь талант, есть ли здесь команда и какова ее роль, и кого из персонажей Вы персонально взяли бы в свою команду?
  • Как выявлять и развивать таланты в IT
    0
    В технической среде не может быть никакого лидера без авторитета. А авторитет в технической среде достигается знаниями, продемонстрированными на практике. Иначе получится Рик-2.

    > Рекомендую почитать

    Я ценю Ваше беспокойство о моем графике чтения. Смею Вас заверить, он расписан на два года вперед, а с уже прочтенным (причем, прочтенным на Английском) списком литературы Вы можете ознакомиться по ссылке. Я искренне надеюсь, что Ваш совет «почитать» не голословен, и Вы так же, с удовольствием, похвастаетесь не только способностью раздавать советы, но и личными практическими достижениями в Ваших же советах.

    Вы конечно, имеете право на любое мнение. Но когда Вы противопоставляете свое мнение мнению Кента Бека, ученику Уорда Каннингема, учителю Мартина Фаулера, автору первой (и по сей день — самой эффективной) Agile методологии XP, автору TDD, автору рефакторинга, другу Эрика Гаммы, человеку, внесшему большой вклад в развитие паттернов проектирования и создавшему самые эффективные команды разработчиков на планете, то как Вы думаете, кому больше поверят? Вам, человеку, признавшемся в неспособности создавать эффективные команды (за исключением «сачков» и «равняющихся на отстающих»), или Кенту Беку?

    Из Ваших слов явствует только то, что вы никогда не работали по Agile, и даже не понимаете его смысла. Иначе расскажите пожалуйста, кому Вы отводите роль лидера в XP-команде? Ни инструктор, ни администратор для этой роли не подходят. Тимлидов — нет. Есть ревизор, но опять — мимо.

    > Для проекта уровня «Миссия невыполнима»

    Вы снова продемонстрировали полное незнание Agile. Ни про экономику разработки ПО, ни про минимизацию рисков, ни про раннюю обратную связь, вы, похоже, никогда не слышали. Ибо проектов «Миссия невыполнима» в Agile не может быть в принципе.

    > Реальный кризис отсутствия талантов более всего проявляется именно на этапе проектирования.

    Опять же, в Agile проектирования как такового нет. Это не Waterfall. Проектирование там делается через рефакторинг. Делается всеми, каждым членом команды. Поэтому нет и архитектора (в этом он и отличается от инструктора, — инструктор не принимает решений). Вы об этом бы знали, если бы хоть раз прошли хотя бы по одной моей ссылке, вместо того, чтобы усердно демонстрировать нам всем здесь Вашу талантливость.
  • Как выявлять и развивать таланты в IT
    +1
    Я мог бы с Вами согласиться, если бы Вы использовали слово «менеджер» вместо слова лидер. Действительно, мне приходилось наблюдать, как смена топ-менеджмента и бездарное управление уничтожили отличную команду менее чем за месяц.

    Но… если Вы знаете что такое истинный Agile, особенно в его натуральном виде — Extreme Programming, и хоть раз в жизни работали по нему, то Вы понимаете, что в команде просто не может быть ни одного «не таланта», иначе он потопит всю команду. Настоящий Agile без команды невозможен.

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

    «One team that used formal inspections reported that inspections quickly brought all the developers up to the level of the best developers (Tackett and Van Doren 1999).» (Steve McConnell)

    Делая акцент на индивидуальный талант, можно легко попасть в ситуацию описанную в статье "Рик, ты уволен: мы избавились от нашего лучшего сотрудника и не пожалели об этом". Разумеется, вина была не в Рике, а опять, же в менеджменте, который полагал, что для успеха достаточно иметь в команде одного «таланта». И Рик — действительно был талантливым парнем, только с недостатком знаний. Он оперировал огромным уровнем сложности (и никто не мог с ним в этом сравниться), просто потому, что не знал, что хорошая архитектура как раз и заключается в устранении этой сложности.
  • Как выявлять и развивать таланты в IT
    0
    Командная работа это нечто из области коллективного секса
    Ну… если так подходить к командной работе, то может тогда персональная талантливость и первостепенна… Не знаю… Я только XP (Agile) пробовал, а там без «Collective Ownership» — никак.
  • [Перевод] Анемичная модель предметной области — не анти-шаблон, а архитектура по принципам SOLID
    0
    Совершенно верно. Главный императив разработки ПО — управление сложностью. А кто не согласен, тот льстит себе, и думает что у него неограниченный размер черепа (если немного перефразировать известное выражение Дейкстры). Вот главный фундамент качественной архитектуры: число семь.
  • [Перевод] Анемичная модель предметной области — не анти-шаблон, а архитектура по принципам SOLID
    +1
    Молодой человек, конечно, далековат от истины. Но Вы, Naglec, схватили его суждения не за тот хвост). Потому что именно здесь он имеет кое-какие шансы так говорить.

    Вообще говоря, существует логика приложения, и бизнес-логика, которая, в свою очередь, разделяется на application-specific(dependent) бизнес-логику и, собственно, предметную бизнес-логику (извиняюсь за тавтологию).

    Предметная бизнес-логика — это логика уровня предметных (Domain) моделей. В данной статье предлагается не разделять подвиды бизнес-логики, и все засовывать в сервисы.

    А в таком случае, срабатывает принцип, изложенный Мартином Фаулером:

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

    The easier question to answer is probably when not to use it. You probably don’t need a Service Layer if your application’s business logic will only have one kind of client say, a user interface and its use case responses don’t involve multiple transactional resources. In this case your Page Controllers can manually control transactions and coordinate whatever response is required, perhaps delegating directly to the Data Source layer. But as soon as you envision a second kind of client, or a second transactional resource in use case responses, it pays to design in a Service Layer from the beginning. («Patterns of Enterprise Application Architecture» Martin Fowler)


    Тут, правда, есть нюансы, но я не хочу перегружать этот комментарий, если интересно, то после данной цитаты я их приводил в этой статье по проектированию Сервисного Слоя.
  • Как выявлять и развивать таланты в IT
    0
    Специалист должен полагаться на знания, а не на ощущение персональной талантливой исключительности. Для охарактеризования специалиста лучше подходит слово «компетентность».

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


    «Компетентный программист полностью осознает строго ограниченные размеры своего черепа, поэтому подходит к задачам программирования со всей возможной скромностью.» (Дейкстра 1972)


    Командной работе нужно учить. Вот что говорит по этому поводу Кент Бек:

    «It’s hard to collaborate. Our whole education system is tuned to individual achievement. If you work with someone on a project, the teacher calls it cheating and punishes you. The reward systems in most companies, with individual evaluations and raises (often cast as a zero sum game), also encourages individual thinking. You will likely have to learn new people skills, interacting as closely with your team as you will in XP.» («Extreme Programming Explained» by Kent Beck)


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

    «Software’s Primary Technical Imperative is managing complexity. This is greatly aided by a design focus on simplicity.» (Steve McConnell)


    «Simplicity and elegance are unpopular because they require hard work and discipline to achieve and education to be appreciated.» (Edsger W. Dijkstra)


    Ну и если человек на самом деле талантлив, то он направит свои усилия не на то чтобы оторваться от толпы и продемонстрировать свою исключительность, а на то, чтобы сделать команду лучше:

    "… it encourages communication. I like to think of the analogy of a pool of water. When an important new bit of information is learned by someone on the team, it is like putting a drop of dye in the water." (Kent Beck, XP)


    Всю информацию сюда не впихнуть, если кому интересно, то "How to quickly develop high-quality code. Team work."
  • Почему опытные разработчики пишут тупой код и как распознать новичка за километр
    0
    Понять эту статью можно только с позиции опыта. Могу ее добавить цитаты известных авторитетов на тему простоты и проблемы умных людей. Еще по теме статья М.Фаулера Is Design Dead?.
  • Как мы выбирали между Elastic и Tarantool, а сделали свою (самую быструю) in-memory БД. С Join и полнотекстовым поиском
    0
    > ACID только на уровне документа, насколько я понимаю примерно так-же, как у монги.

    Тогда, боюсь, что это не ACID, а «Transactions at the single-document level are known as
    atomic transactions». Есть еще термин BASE (Basically Available, Soft state, Eventual
    consistency) в противовес ACID.

    Проблему согласованности и атомарности данных Монга выносит на уровень приложения в виде «Two Phase Commits», как об этом говорит документация.

    Блокировать всю таблицу ради atomic transactions не нужно, оптимистической блокировки более чем достаточно. Все-таки пессимистическая блокировка существенно влияет на уровень параллелизма.

    Но если Вы замахнулись на поддержку JOIN, тогда ACID будет уместным. Но при этом вы поставите крест на возможностях шардинга (CAP-теорема). Есть небольшая книжечка, всего в 150 страниц, «NoSQL Distilled» by M.Fowler, которая кратко и очень доходчиво рассматривает все эти вопросы. Только не читайте русский перевод этой книги, он ужасен, и нередко искажает смысл оригинала.
  • Как мы выбирали между Elastic и Tarantool, а сделали свою (самую быструю) in-memory БД. С Join и полнотекстовым поиском
    +2
    > Если быть точным, в мире NoSQL, как правило, нет операции Join в чистом виде

    Ну, в этом и заключается смысл NoSQL хранилищ. Они ориентированны для работы в условиях шардинга (за исключением некоторых, например, графовых). А поскольку в условиях шардинга невозможно обеспечить ACID (в силу CAP-теоремы), то возник вопрос организации транзакций. Поэтому границами транзакций в NoSQL стали границы агрегата (композитной структуры объектов), что вписывается в распределенную модель хранения информации (и удовлетворяет DDD). Джойны по этой же причине обычно не поддерживаются (что компенсируется поддержкой вложенных объектов).

    Кстати, я не заметил, как автор решает проблему параллельного доступа к данных (транзакций). Возможно я этот момент упустил, поэтому пробежался по статье повторно, но так и не нашел. А этот момент очень важный в условиях «100К RPS».
    Поскольку в NoSQL границы транзакции совпадают с границами агрегата, там достаточно оптимистической блокировки. Совсем другое дело возникает при поддержке JOIN. В таком случае, следует как-то предотвратить чтение несогласованных данных. А способ реализации транзакций существенно влияет на уровень параллелизма (потому и существует четыре уровня ACID транзакций).

    Я не хочу затрагивать вопрос о том, что это влечет за собой способ организации клиентского кода (двухфазные транзакции и т.д.).

    Отдельно хочу затронуть тему самого термина NoSQL.

    «The original call [NoSQL Meetup] for the meetup asked for “open-source,
    distributed, nonrelational databases.» (NoSQL Distilled by M.Fowler)

    Одним из критериев NoSQL является "Designed to run on large clusters".

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

    Интересно было бы услышать характеристики используемого диска. И, в целях чистоты эксперимента, было бы интересно рассмотреть вариант монтирования файловой системы тестируемых БД в RAM.
  • Упрощаем ReactJS компоненты с помощью RxJs
    0
    Не столь важно React или Angular, но RxJs для фронтенда, действительно, более удобный чем Redux/Flux/etc., потому что он позволяет работать с классическими моделями предметной области. Реактивные потоки использовались в dojo начиная еще с 2010 года (кстати, dojo2 тоже собирается переходить на RxJs). Безусловно, Redux/Flux имеет право на существование, но фронтенд — не совсем то место, где разновидности реализаций «Event Sourcing» паттерна могут полноценно проявить свои достоинства.
  • [Перевод] Анемичная модель предметной области — не анти-шаблон, а архитектура по принципам SOLID
    +1
    VolCh, Совершенно верно!pankraty, спасибо за перевод. В кругу моих друзей уже не первый раз всплывает эта тема, поэтому решил ответить по поводу Anemic Domain Model здесь.
  • Почему плохо быть отличником
    0
    Verovir, да, на самом деле существует «проблема умных людей», и она хорошо проявляется в гибких методологиях разработки. Инстинктивно умные люди используют свое время неэффективно, и это естественно. Кент Бек в своей книге «Extreme Programming Explained» показывает как с помощью нехитрых методик сделать умных людей эффективными разработчиками и максимально эффективно использовать их умственные способности.
  • Django ORM — медленный? Оптимизируем (хардкорно)
    +1
    Ну, раз уж столько критики обрушилось в сторону Django, то поделюсь ссылкой на эту статью о проблемах Django и способах их решения.

    Прекомпиляцию запросов использовал часто, но django queryset для этого обычно не использовал. Не потому что его трудно кэшировать, а просто потому, что с ним хватает проблем и помимо этого. Django прекрасно понимает Raw-SQL, а это значит, что ответственность за создание SQL-запроса вовсе не обязательно возлагать на Django.

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

    Если автору статьи больше импонирует билдер запросов алхимии, советую обратить внимание на sqlalchemy-django-query и на другие интеграционные библиотеки которые перечислены в указанной статье.

    Django-Rest-Framework прекрасно интегрируется с SQLAlchemy на своем уровне, ссылки на интеграции тоже приведены в указанной статье.
  • Emacs + удобный менеджер окон и буферов
    0
    Он работает везде. Я тоже в терминале работаю…
  • Emacs + удобный менеджер окон и буферов
    0
    Еще как вариант speedbar, он не только файлы отображает, но и дерево содержимого самого файла.