Обсуждаем правила чатика. Вот тут документ, в котором можно набросать свои пожелания: https://docs.google.com/document/d/1txPSAjM1cdYfotnpktT1DuKrmNMgi1GATluAYN-v7aQ/edit?usp=sharing

Архитектурные космонавты

Взято здесь:
https://maleevdimka.wordpress.com/2011/08/22/архитектурные-астронавты/

Достаточно давно, Джоель Спольски написал отличный блог пост, о том — кто такие архитектурные астронавты.
https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/

Собственно, что за люди такие? Представте есть необходимость — закачивать файл на сайте. Просто файл — так как это видеохостинг — файл будет видео в различных форматах.

Как сделает обычный программист — закачка файла, определение по разширению, проверка валидности, и дальнейшие действия. Элементарно!

Что сделает архитектурный астронавт? В начале естественно он все это запроэктирует: визио диаграмма с тонной паттернов из всех возможных книг о паттернах программирования! Так же этот контрол будет неймоверно гибким, потому как будет состоять из взаимозаменямых модулей, который в любой момент можно переставить так, что контрол превращается в мп3 плеер. Ах да, ведь есть ещё мобильные системы — архитектру предусматривает что если пользователь зашел с моблильного телефона — конрол поддерживает возможность работы с мобильным телефоном 300т марок.

Это самый просто пример — аплоад контрол:) Представте чего может наворотить такой человек в сложной системе. Архитектурный астронавт — это не человек который решает проблему, а пытается решить шаблон проблемы. Если сравнить с доктором — это доктор которые не лечит лекарством, а ищет решение всех проблем.

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

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

Ритм работы

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

Специализация — удел насекомых.

Роберт Хайнлайн, Достаточно времени для любви, 1973

— Извиняюсь, — перебил его Швондер, — вот именно по поводу тестировщика и дизайнера мы и пришли поговорить. Руководство компании просит вас добровольно, в порядке трудовой дисциплины, отказаться от тестировщика. Тестировщиков нет ни у кого в Москве.

— Даже у ВКонтакте, — звонко крикнула женщина.

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

— И от дизайнера также, — продолжал Швондер, — задачи дизайнера прекрасно можно соединить с задачами фронтендера.

— Угу, — молвил Филипп Филиппович каким-то странным голосом, — а кто же должен верстать фронтенд?

— Фуллстэк, — хором ответили все четверо.

Багровость Филиппа Филипповича приняла несколько сероватый оттенок.

— Фуллстэк верстает фронтенд, — заговорил он слегка придушенным голосом, — аналитик тестирует, фронтендер дизайнит, проект-менеджер анализирует, а тестировщик заливает на прод. Очень возможно, что ВКонтакте так и делает. Может быть, они на проде гоняют нагрузочные, а в песочницу форвардят VIP кастомеров. Может быть. Но я не ВКонтакте!.. — Вдруг рявкнул он и багровость его стала желтой. — У нас тестировать будет тестировщик, а дизайнить — дизайнер! Передайте это руководству компании и покорнейше вас прошу вернуться к вашим делам, а мне предоставить возможность проводить нагрузочные там, где их проводят все нормальные люди, то есть на стейджинге, а не в песочнице, и не на проде.

(c) не моё

В чём сила, прототипировщики?
anonymous poll

moqups.com – 8
👍👍👍👍👍👍👍 38%

axure.com – 8
👍👍👍👍👍👍👍 38%

invisionapp.com – 5
👍👍👍👍 24%

👥 21 people voted so far.

«Главное, чему научил меня Фрэнсис Коппола, — это идти сквозь создавая множество различных слоев.

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

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

Джордж Лукас (режиссер "Звездных войн")

Из терминологии REST API

Запрос GET - плевок. Характерная фраза "плюнули запросом в апи... "

Любопытно, что такое запрос POST?

Максим Мошков поправляет:
Плевок - это POST.
GET - это клевок.

Про Хилтон

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

Примерно за 2 недели до часа Х стучится ко мне в скайп наш Гениальный (время примерно 18:00мск):
- Дим! Ну чё там по срокам?
- Всё норм, всё по срокам.
- Ты знаешь... Я тут в Джакарту прилетел, у меня завтра в 7:00мск презентация нашего сервиса местным министрам! Успеваешь?

OMG...  Ситуация - жесть полная. Но что-то же делать надо? Что у нас в наличии? В принципе действительно всё неплохо, надо пару мест подпилить и выкатится без пары фич. Тогда преза получится норм.

Договариваюсь со всей командой... Ну как договариваюсь... Кому-то денег обещаю, кому-то отпуск, кому-то увольнение... Решили короче. Собрались и начали жечь.

Не хватает самой малости, - листа текста а4 на индеонезийском языке. Без него сервис не будет говорить на родном языке индонезийцев. И обойтись ни как. Стучусь к Гениальному:

- Нужен текст на индонезийском!
- Ничем не могу помочь. Я даже на английском не разговариваю!
- Эм.... А ты сейчас где? В такси? Можешь попросить таксиста текст перевести с английского на иднонезийский?
- Не могу. Он не знает никакого языка кроме индонезийского...

Ооооооооок! Чешу репу. Снова стучусь к Гениальному:
- А отели какие-то знаешь в Джакарте?
- Да! Хилтон!

Время уже где-то 00:30мск. Чё делать-то? Терять нечего. Позади Москва.

Звоним в отель, объясняем, что мы несчастные русские стартаперы, хотим осчастливить Индонезию своим стартапом, не хватает листа а4 на индонезийском.

- Вот наш e-mail, присылайте текст, мы переведём!

Через 2 часа мы получили текст и запустились! Гениальный был счастлив!

https://t.me/ctorecordschat/9729
Разъяснения про отпуска, бонусы и увольнения.

В чём сила, пыхеры?
anonymous poll

За мкадом^W в пыхе жизнь нет! Пыщ-пыщ! – 13
👍👍👍👍👍👍👍 76%

https://github.com/swoole/swoole-src – 3
👍👍 18%

https://github.com/walkor/Workerman – 1
👍 6%

👥 17 people voted so far.

Влад Балин пишет про ООП. Часть 1

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

Ну, то есть, как. Есть, конечно Computer Science - это серьезные дяди-теоретики (и тети - например Барбара Лисков) из университетов, которые пишут статьи, книги, и диссертации. Но книги и статьи получаются слишком сложные, так что типичный говнокодер их не читает.

Есть Software Engineering - это суровые насупленные практики, которые иногда преподают, иногда работают, и иногда тоже пишут диссертации. Которые, разумеется, тоже никто не читает, потому, что они слишком длинные. Он, говнокодер, в наше время вообще ничего не читает, кроме разве что стековерфлоу. А зачем, если можно обучающий видосик посмотреть, где процесс говнокоденья показан медленно, по шагам.

Так как экспериментальные и теоретические дисциплины прошли мимо него, у говнокодера нет знаний и понимания. Их место занимают Мнения. И так как среди множества мнений надо как-то выбирать "правильные" - есть Авторитеты, Мнению Которых надо Верить.

Я понятия не имею, кто из муда^D^D^D^D авторитетов распространил в сообществе фронтенд-разработчиков мнение, что ООП - говно, перечеркнув 40 лет опыта индустрии. Популярно так же заблуждение, что ООП - это просто, и каждый, кто умеет писать слово class уже его знает. Сюрприз. ООП - это не просто. Мы можем сделать в этих условиях единственную вещь - объяснить, что это на самом деле такое, постаравшись сделать это кратко, и понятно.

Но для начала надо разобраться с одной проблемой. Разве можно что-то объяснить тому, кто уже все знает?

> А че там? Я читал про ключевое слово class, я знаю ООП, там все просто, и интуитивно понятно.

Сейчас проверим. Есть у тебя два сту^D^D^D класса. Один - "Квадрат". Другой - "Прямоугольник". Рисуем их - без поворотов, стороны вертикальны и горизонтальны. Какое утверждение из перечисленных верно? Объяснить почему:

А) Квадрат наследуется от Прямоугольника
Б) Прямоугольник наследуется от Квадрата
В) Их нельзя наследовать друг от друга.

У меня большой опыт с этой задачей - я задавал ее на собеседовании каждому программисту, и это за последние двадцать лет, наверное, больше сотни человек. Вообще-то, правильный ответ В. Это вариант Ellipse-Circle Problem, представляющей собой известный пример нарушения Liskov Substitution Principle. Никто ни разу не давал на этот вопрос правильный ответ. Это и не требовалось - наибольший интерес представляет "объясните почему", и следующая за этим дискуссия о природе ОО. Вот тут кошмарная бездна "понимания ООП" открывается. Причем, совершенно не важно, говорит человек, что он знаком с LSP, или нет.

Трое из четверых (и это поразительно), сходу говорят "Б". Почему?

- Ну, квадрат определяется одной стороной, а прямоугольник - двумя, так мы отнаследуемся от квадрата, добавим еще сторону, и будет норм.
- А разве не любой объект подкласса должен также являться объектом базового класса?
- Любой.
- Так прямоугольник же - он же не квадрат?
- Не квадрат.
- Так как наследовать то будем?

Задумчивость. Человек понимает, что началось что-то не то, и почва явно уходит из под ног. Ну окей.

- Тогда А - Квадрат от Прямоугольника!
- Почему?
- Ну, множество квадратов - это подмножество прямоугольников. Квадрат - это прямоугольник, но не каждый прямоугольник - это квадрат.

Доволен. Улыбается. Хорошо. Пришло время вспомнить, а что же такое вообще класс, и чем он отличается от структуры. А отличие очень простое - класс определяется своим поведением, а не структурой. Это означает, что нет методов - нет класса. Знающий ООП человек должен был с порога нафиг послать с этими прямоугольниками - методы покажи.

- Теперь я добавляю в прямоугольник метод - растянуть его по оси о-икс. rect.stretch( a ), где a - коэффициент, во сколько раз растянуть. Могу я добавить такой метод в прямоугольник?
- Да, конечно, нет проблем.
- Каким именно образом этот метод будет вести себя в квадрате?

Шок. Ступор.

Влад Балин пишет про ООП. Часть 2

- Теперь я добавляю в прямоугольник метод - растянуть его по оси о-икс. rect.stretch( a ), где a - коэффициент, во сколько раз растянуть. Могу я добавить такой метод в прямоугольник?
- Да, конечно, нет проблем.
- Каким именно образом этот метод будет вести себя в квадрате?

Шок. Ступор.


- Исключение бросит.
- И он все равно будет подклассом?
- Да.
- То есть, он, как подкласс, в том числе прямоугольник, и его можно передавать параметром везде, где прямоугольник принимают, так?
- Ну да.
- А если там, куда его передали, вызовут stretch? Прямоугольнику разве положено в этом месте падать?

В этом месте часть продолжает уверять вас, что исключение в подклассе в половине методов базового класса - это нормально, всегда так говнокодили, и это нормальные ООП практики. Другая часть говорит, что получается, что правильный вариант В.

Далее, тем кто добрался до В, мы задаем контрольный вопрос. Сугубо теоретический. "Круто, еще одна задачка. У нас есть действительные и комплексные числа. Что от чего наследуется?"

- Комплексные от действительных.
- Почему?!
- Ну как, очевидно же - при наследовании добавим к действительной части мнимую, и будет хорошо. Не наоборот же, ну, иначе с памятью херня какая-то получится.
- ...(аналогом метода stretch тут будет корень из -1, если кому интересно).

Есть очень небольшая категория людей (единицы в моей практике собеседований), которая быстро понимает, что проблема вызвана "замкнутостью" методов (метод не может выводить объект из его класса), и предлагает решение. Сделать метод stretch() immutable - пусть он не меняет состояние класса, а всегда создает вместо этого новый прямоугольник. И все.

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

И вот тут часть людей говорят:

- А я всегда говорил, что ООП - говно!
- Почему это вдруг?
- Ну вот, потому, что круг с квадратом наследовать друг от друга нельзя, проблемы какие-то возникают!
- А причем тут ООП?
- Ну, ООП - это же наследование?

ОО - это в первую очередь не трюки вроде наследования, а идея "абстрактного типа данных". Абстрактный он потому, что определяется не описанием своей структуры, а перечнем операций над ним. Класс - это то, что можно делать с его объектами. Умеет крякать? Плавать? Летать? Утка. Есть крылья? Ласты? Хвост? Что за расчлененка, ты зачем утку убил, извращенец?

Влад Балин пишет про ООП. Часть 3

Думать об объектах в терминах их составных частей - естественно, и интуитивно понятно. И это совершенно не удивительно, что мало кто может решить эту задачу старушки Лисков на "правильное наследование" (на самом деле - определение "strong behavioral subtyping"). Думать об объектах как об абстракциях, определяемых поведением, игнорируя их структуру - напротив, неестественно, и требует не просто осведомленности и тренировки, а полного разворота сознания.

Но самое интересное не это. Основная проблема, которую эффективно решает ОО (и ничего лучше для нее человечество пока не придумало) - это декомпозиции большого и сложного состояния. Ну, то есть, то самое, стонами о чем сообщество фронтенда наполнено чуть менее чем целиком - у них в простеньких страничках "state management is hard". Как же ООП помогает? Сейчас объясню, это просто.

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

Ну, разумеется, все будет так, если у автора не руки из жопы, которые на рефлексе тянутся наследовать прямоугольники от квадратов. И как мы видим по статистике задачи Круг-Эллипс - именно так и делает большинство.

- А что не говно?
- ФП!
- Неужели?
- Да. Гораздо проще, чем это ваше говенное ОО.
- Почему же?
- Ну, там все immutable, все на чистых функциях, а потому просто, и понятно.

Тут человек получают задачу сделать immutable FIFO Queue, со средней сложностью операций O(1). ФП - это же просто, ну. Ну что может быть проще? Но это уже другая история.

ЗЫ: Okasaki Queue - это и в самом деле просто. 🙂 Но вы попробуйте - без гугления, что это такое. Вообще, предполагается, что человек, говорящий «ФП это круто» должен знать ответ на этот вопрос. А не просто нихуя не понимать в ООП.

https://www.youtube.com/watch?v=PCx228KcOow
https://habr.com/post/418545/
Кто помнит "Жизнь"?

Фотошоп

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

Ну что может быть проще? Давайте их генерировать их сами! Красивые и красочные настолько, чтобы аж слюна капала! Типа вставляем в поле ввода ссылку на аппсторовский прил и тут же, как грибы после дождя будут вырастать баннера-баннерочки-баннирища!

Чешем репу и откапываем стюардессу: пытаемся обучить ImageMagic генерировать красивые классные баннера. Закапываем стюардессу и пытаемся некими лежалыми скриптами питонячьими парсить фотошоповские макеты. Херня.

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

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

Фигня-война! Мэтр снисходительно посасывает трубку и сообщает, что фотошоп умеет скрипты и там всё хорошо. YESSS!!!!!!!

Курим документацию, учим фотошоп подсасывать скрипты, брать тексты и картинки, засовывать их в фотошоповские макеты. Фотошоп кривится и сообщает, что согласно политике безопасности скрипты запускать не будет. Уговариваем его всей командой. Уговорили. Уговорили не только скрипты запускать, но и вообще всё делать, только он через некоторое время падает и говорит, что не может работать в такой обстановке! Просится в отпуск.

Курим документацию. Курим бамбук. Курим. Обучаем скрипты перезапускать фотошоп через каждые 100 генераций. Теперь он работает ещё медленнее. Каждый макет открывается по минуте. Учим его открывать макеты, генерировать баннера, а потом делать undo на всю цепочку действий. Стало почти мгновенно, - по 1 секунде на баннер.

Долго думали, куда его посадить. Сначала пробуем маки. На любых маках фотошоп тормозит. Винда прыгает, размахивает руками и кричит - "выбери меня-выбери меня, птица счастья завтрашнего дня!"

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

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

Плюём и сажаем красивую блондинку говорить ему "НЕТ!!!" Все выдохлись, сервис запустили, но теперь взбунтовался аппстор, - не много ли мне, мол, шлёте запросов?

Покупаем на корню аккаунт с платными проксями и на коленке лепим "карусель", которая ходит в аппстор по хттп из под разных стран!

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

Сотрудники Mail-RU тоже боятся случайно поставить браузер Amigo.

Из хостинговых аббревиатур
"СЦУКо"- система централизованного управления колокейшн

Из обсуждения kpi для разработчиков основная оценка производится по количество проблем, которые приносит разработчик :) Чем менее проблемный разработчик, тем более высока эффективность его работы.