Wiki Category: development

Костыли, говно, и ебанина

Vlad Balin:

#javascript Эта картинка вызвала оживленную дискуссию в MoscowJS. Люди не понимают разницу между ебаниной, костылями, и говном. Это очень просто, я сейчас объясню.
14572811_1234711266591045_6966028968720558313_n

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

А вот ебанина – это совсем другое дело. Она никакого отношения к рациональной реальности не имеет. Она берется не из нее, а целиком из мозга. Это победа интеллекта над разумом. Это, сцуко, Торжество Идеи.

Другими словами, если костыли – это недостаток ума или (чаще) времени, то ебанина – это напротив, избыток и того и другого.

С другой стороны, говно – это просто говно. Если у программиста руки растут из жопы (что в случае программиста надо понимать не буквально, а как отсутствие элементарного эстетического чувства), то независимо от наличия времени и ума не получаются ни костыли, ни ебанина. А выходит какое-то говно. Об этом явлении пишут поэты:

Олег за все берётся смело
Все превращается в говно
А если за говно берётся
То просто тратит меньше сил

Все просто, ну. Русский язык точен. Как можно эти вещи перепутать.

И я должен отметить – это самая правдивая и точная карта технологий JS из всех, что я видел.

просто за-бали уже до чертиков со своими высерами про цеховых рабочих

Утянул у

Gennady Dogaev full-stack web developer (freelance)

ну вот жеж, любое сравнение с обычной работой на потоке тебя подрывает неслабо, судя по прошлому комменту)

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

Чисто для примера сборки из всего готового:

  • Разработчики фреймворка вообще молодцы и создали классную вещь, но они клали на анимацию при перереходе между страницами (а без анимации SPA по ощущениям таки похуже, чем с ней, даже статья вот есть почему)
  • Разработчик плагина для той самой анимации тоже молодец и проделал огромнейшую работу, но не учел особенности при подгрузке данных с сервера и не под каждую верстку оно одинаково хорошо работает
  • Ну и разработчики UI-фреймворка тоже конечно молодцы, но они клали на всё вышеописаное

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

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

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

Тестируем маршрутизатор Symfony 4.1

Вся статья

Суть улучшений – роуты собираются в здоровенное регулярное выражение.

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

Колонка Diff показывает, насколько быстрее новый маршрутизатор Symfony, по сравнению с нашим нынешним (3.4).

Routes. 3.4 4.1 (7d29a4d) Diff
First static route 448 ms 382 ms -17%
Random static route 1621 ms 474 ms -242%
Last static route 1826 ms 544 ms -234%
First dynamic route 746 ms 527 ms -41%
Random dynamic route 1454 ms 531 ms -174%
Last dynamic route 2039 ms 524 ms -289%
Not Found 2112 ms 522 ms -304%

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

riot480x
logo-vuejs

Vue.js

Я могу подтвердить, что two-way binding иногда не так прост и не так читабелен, но большинство из этих страхов связаны с общим страданием людей от первой версии Angular, где двусторонняя привязка была, может быть, не самой лучшей. И все же… это, вероятно, не было самым большим просчетом даже в Angular. Посмотрите на мой быстрый редактор, который я накостылил недавно с Vue.js для нашей платформы на Drupal (заранее прошу прощения за дизайн, это бэкенд UI для наших операторов, а дизайнеры заняты, создавая интерфейсы для наших клиентов, так что этот кусок функционала ждет своего часа, чтобы стать красивым):

Почему мы выбрали Vue.js (а не React)

Vue.js – реактивный фронтенд фреймворк для людей

Андрей Грачёв: Vue.js или как наконец отказаться от React

02b2fcb38d164d2b90f4c16de1716d57

Почему мы выбрали Vue.js (а не React)

Мы решили использовать Vue.js после того, как построили тестовое приложение c идентичным функционалом – наш калькулятор — на React, Vue.js и Angular2.
React.js

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

Мы запилили несколько SPA и динамических виджетов на React, мы тестировали React Native (под iOS) и Redux. Я думаю, что React был большим шагом для мира JS с точки зрения осведомленности о состоянии, и он показал многим людям, что такое реальное функциональное программирование в хорошем, прагматичном ключе. Также я думаю, что React Native велик – он буквально меняет весь ландшафт мобильной разработки.

Читать дальше

Вышел PHP 7.1

Вы слушаете «Пятиминутку PHP», выпуск номер 25 — подкаст о новостях из мира PHP, интересных постах в блогах и современных подходах к разработке.

Рад всех поздравить с выходом PHP версии 7.1.0. Давайте сделаем краткий обзор RFC, вошедших в этот релиз.

Читать дальше
book-cover

Designing Data-Intensive Applications (book)

Load from dataintensive.net

Don’t just hack it together

NoSQL… Big Data… Scalability… CAP Theorem… Eventual Consistency… Sharding…

Nice buzzwords, but how does the stuff actually work?

As software engineers, we need to build applications that are reliable, scalable and maintainable in the long run. We need to understand the range of available tools and their trade-offs. For that, we have to dig deeper than buzzwords.

This book will help you navigate the diverse and fast-changing landscape of technologies for storing and processing data. We compare a broad variety of tools and approaches, so that you can see the strengths and weaknesses of each, and decide what’s best for your application

MongoDB

После трех месяцев в разработке все прекрасно работало.

Но однажды в понедельник на планерке клиент сказал, что один из инвесторов хочет новую фичу.
Он хочет иметь возможность кликнуть на имя актера и посмотреть его карьеру в телесериалах.
Он хочет список всех эпизодов во всех сериалах в хронологическом порядке, в которых этот актер снимался.

Почему вы никогда не должны использовать MongoDB


из Почему эти ваши модные NoSQL решения не так уж хороши

Пробовали MongoDB. К счастью, с этой СУБД мне пришлось работать совсем недолго. MongoDB не выдерживает никакой критики, и ее недостатки, похоже, поняли уже все, кроме, разве что, самых упоротых программистов на Node.js. Вручную шардированный PostgreSQL, который, напомню, уже давно умеет формат JSONB, с самым тупым и никем не протестированным скриптом на Python для автофейловера, будет куда более удачным выбором, чем MongoDB. Подробности смотри у Афира и еще, например, вот тут. Выбрав PostgreSQL, вы получите все тоже самое, только куда более стабильное, не теряющее данные, а также с нормальными локами, вьюхами, транзакциями, джоинами и вот этим всем.

dot_screen_teapot

WebAssembly как киллер фича, и возможный убийца 2D Canvas

я не удивлюсь если выход в массы этой технологии в связке с “Unity”подобными движками – оставит далеко позади фронтенды построенные на канвасе в плане быстродействия = комфортности работы пользователя.
технологии на самом деле редко становятся киллер фичей ПО. но, бывает. и WebAssembly для задач где только канвасом рисовать – может оказаться именно такой.

уже сейчас для таких задач надо использовать asm.js, и, минимум, морально готовится к выходу WebAssembly

Читать дальше