Category: it

Category was added automatically. Read all entries about "it".

animated

Про разработку программ и продуктов

Я тут может очевидное кому-то скажу, а кому-то может неочевидное.

Часто бывают программеры, которые типа "на проекте был бардак - ни четких ТЗ, ни куда гребем непонятно". Это от непонимания, что никто никогда не знает зачем ПО вообще делают, и куда дорога вывезет. За редкими исключениями.

Давайте от противного. Вот есть, условно, MS Word. Туда никаких фичей, кроме текущих - и не надо. Да и тех что есть - можно выкосить половину. Можно ли сделать точно также? Да, думаю где-то за 100M баксов - вполне. Что копейки по сравнению с продажами. Можно ли достать 100 лямов, переписать Word - и зарабатывать как MS? Неа. Потому что срать будет всем на ваш новый Word. Чтобы стать продуктом, Office-у пришлось прожить с людьми десятилетия, делать фичи типа "радужный 3D-текст Comic Sans-ом с тенью" - потому что тогда это было модно. А потом - поддерживать эти фичи. Учить поколения людей форматировать пробелами. И так, не мытьем, но катаньем, они захватили рынок.

Сложность и сила ПО - не в текущем его наборе фич, а в возможности его постоянно менять. А талант программиста - не в том чтобы по спеке сделать с тестами. Он про то, чтобы предсказать куда дует ветер, и про вычленить те кусочки, которые скорее всего пригодятся - когда надо будет разобрать и собрать всё заново. Или понять что хер угадаешь куда вывезет, и просто писать код быстро, просто и без ошибок. А как поменялось - стирать и переписывать.

Сам код - вообще имеет отрицательную ценность - чем его больше, тем хуже, если ценность продукта постоянна.
animated

Вопросы на собесах №3

Что я понял со своего опыта - на собесе надо обязательно просить писать код. Причём не на бумажке - а в приближенных к боевым условиям: в IDE, в консоли хрома, где удобно. Очень часто люди либо подкупают хорошими soft skills, либо хорошо рубят в теории - и ты под впечатлением такой: "ну тут - джедай, тут даже как-то неудобно просить задачки решать". Но надо заставлять писать код, и смотреть как это кандидат делает. Ты же не пиздабола покупаешь, а программиста. Бывает, что люди с улыбкой и весело рассказывают про заоблачные дали, а код писать - не умеют. Банально не умеют простейшие алгоритмы написать с третьего раза, не умеют пользоваться IDE.

Короче. Я даю такую примерно задачку C#-ерам:

string[] cities = { "Moscow", "Minsk", "Kyiv" };
string input = "I live in Moscow.";

Написать алгоритм, который найдет в input ровно одно вхождение строки из массива cities, и выведет его. Если вхождений ноль, или больше одного - выведет "none".

Дальше события развиваются по-разному. Некоторые - про LINQ только слышали, да и через foreach не могут решить. Люди которые не смогли даже это за час нормально сделать - мне попадались. Это уже даже не смешно.

Дальше мы усложняем, в зависимости от успеха с предыдущим заданием, и смотрим как умело человек жонглирует кодом и IDE:

1. Добавляем еще такое:
string[] skills = { ".NET", "Java", "JS" };
string input = "I write .NET in Minsk";
И просим найти ровно одно вхождение из обоих массивов.
2. Представим что городов 100к. Как ускорим твой O(N)?
3. Давай обработаем "HELLO,MINSK!"
4. У городов бывают разные написания (Kyiv/Kiev), давай заведем каждому городу синонимы
5. Что будет если справочники в БД?
- какая табличка будет
- какие индексы повесить
(кстати нетривиально, если подумать - мы же не знаем на клиенте какие слова означают города)

Человека умеющего - видно сразу. У него и пальцы по кнопкам попадают. И F5 ему религия не позволит нажать пока ни одного лишнего пробела не по conventions не будет. И чик-чик подрефачили - ибо перфекционизм. И ничего лишнего в коде не будет.

Короче просите человека сделать то, ради чего вы его нанимаете. А не "как работает GC"? Если бы меня спросили "как работает GC", я бы ответил: "заебись он работает, за свои 12 лет с дотнетом - ни разу туда не лазил".
animated

Вопрос на собесах #2

Любые, претендующие на какую-либо работу с вебом - как правило это фронтэндеры-еры JS-еры, подвергаются мною чудовищному, нечеловечному испытанию:

Есть разметка:
<div class="parent">
  <div class="child child1">
    Child1
  </div>
  <div class="child child2">
    Child2
  </div>
</div>


Очевидно, без какого-либо CSS - дивы "child" отобразятся один под другим. Какие есть способы, в т.ч. извращенные, в т.ч. и применимые в каких-то специфических случаях - чтобы эти два дива встали горизонтально - в ряд друг за другом, типа:
[ Child 1 ] [ Child 2 ]
?

--- дальше спойлер ---

Жду два-три способа. С извращениями от бывалых и толковых - насобирал штук восемь. По ходу беседы - записываю тут же на доске названные - так задорнее. Юзаю как повод проверить hands on на flexboxes - по ним копаю глубже, типа "а как сделать минимумум в 100px". Вопрос работает и как повод для разговора: "а в наши-то времена оооо", "в вилобаджо уже сверстали всё на таблицах, и ебашат друг друга в квейк", и "слышали ли вы про новые веяния с grid layout?". У вопроса нет дна - один раз закончили на том, что transform - работает лучше чем position: absolute - потому что врубается композитинг GPU.

Спрашиваю это от входа, потому что нет никакого смысла брать даже супер-джедая-реактера - который не умеет хакать браузер. Бывает "5 лет опыта в JS, видел только бустрап, я разберусь в CSS по ходу". Но сорян - так оно не работает. Я тоже думал что CSS - это просто почитать чутка, но нет.
animated

Физики-лирики

На вменённых мне проектах, я наблюдаю такую хуйню:

Бекендер, со стажем, за выслугу лет, идет лидить проект. Но он нихуя не понимает простую вещь: бекенд нужен чтобы xx.com вообще открылась, и чтобы когда там пыщ-пыщ на UI нажимают - не проёбывались данные. Всё. Блядь всё. Всё остальное в продукте - делает фронт-энд.

Просто раньше фронт делали те же бекендеры. Или там было так жостко сложно, что "хоть бы как". А теперь - REST-API хуйнул: "нате, хуярьте свой UI", и пошел дальше докерами развлекаться.

Короче. Если вас не бесит UX микроволновки дома, и если вы сходу не придумываете как пиздануть охуенный UX для кастоюли с ТЭН-ами, если вы не видите что UI на один пиксель поехал и это "не аккуратненько" - вы из прошлого века, ваше время прошло, нельзя вам доверять тех-лидство. Можно взять себе "сделаем API как надо фронту, сделаем чтобы БД не тормозило, посрёмся с BA потому-что-пошли-они-нахуй-это-требование-всё-положит". Но отвечать за результат - уже не. Потому что результат - это что чик-чик кнопочки клацают, юзер доволен. Ну и данные не проебались, да.

К сожалению, пока часто UI-лид - 25 лет, бекенд-лид - 35 лет, "иди нахуй мальчик со своей хуйней, мы деплоим микросервисы", и на выходе блевотина.
animated

GraphQL

Посмотрел ролик: https://www.youtube.com/watch?v=783ccP__No8

Подумал что IT Science - больше не про N(n), а приведение масс людей в движение в правильном направлении.

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

Осознал, что даже такая простая хуйня как GraphQL, за 7 лет, типа еще новая для многих. Сотни лямов баксов инвестиций.

Если что, GraphQL, вообще-то - это способ закинуть весьма уёбищный аппликативный функтор считаться на сервере. Причем авторы - этого не особо понимают (хотя может просто хитрые).

Ну и повангую:
- дураку уже очевидно, что идея декларативного языка, в котором можно из O(N^4) автомагически сделать O(log(N)) - токсична. SQL должен умереть.
- понятно, что надо эволюцию, а не революцию. Нужна простая идея, опирающаяся на имеющиеся наработки
- GraphQL хитро решил проблему "что если нам закинут программу, которая ебнет сервер". Тупо white list программ и банить
- кто-то сообразит, что можно выставить API в стиле:
- кидаем WebAssembly,
- у нее есть API в стиле db.persons.byId(111)
- она выкидывает взад JSON

Короче кто не ссыт - можно ёбнуть новый мир.
animated

Должен ли программист уметь программировать?

Статья на хабре:

Почему Senior Developer'ы не могут устроиться на работу
https://habr.com/ru/post/460901/?reply_to=20426003#comment_20426003

Типа заставляют задачки решать, пидоры.

Я тут собесал как-то чувака, типа 10 лет опыта, лид/PM. Попросил открыть студию - нету студии. Ок, давай попишем где-нибудь еще. А он такой: "знаешь, у меня уже кинжал заржавел". Вот это вот "кинжал заржавел" - стало локальным мемасом. И я всегда, всех, на собесах прошу писать код. И даже клаву нормальную им притаскиваю, чтобы не тыкаться в ноут незнакомый.

Прошу не красно-чёрные деревья, а прям тупо "найди в строке слова из массива". И дальше - а как-нибудь не за O(N^2)? Dictionary - ок, а как оно внутри работает? А давай мы еще запятые отпарсим. И смотришь - от входа код говно, или даже после нескольких хотелок прилично всё. А если человек кодит збс - то и в голове дальше порядочек.
animated

Про фуллстек

Наблюдаю печальные проекты, на которых лид - джавист, с представлением о фронте уровня типа: "Реакт? Мне говорили лучше ангуляр. Ну да ладно. Где тут у вас верстальщиков набирают?". Ну дальше всякое типа: "мы вам REST API вон дали, дизайнеры вон скрины нарисовали, пилите, у нас тут поважнее дела есть - микросервисы настраивать".

И начинается:
- фронты делают по 50 вызовов к API на скрин с дичайшим overquerying
- бекенд - оптимизирует эту лишнюю нагрузку
- дизайнеры рисуют компоненты на килобаксы, чисто потому что фронты молодые и без права голоса
- т.к. на бекенде особо нечем заняться - вынимай с БД да кидай в API, начинается изобретаться всякое говно типа 5 слоёв абстракции, CORS, и чего-нибудь еще модного для важности
- проблемы архитектуры сваливаются на фронтов, например "если это API лежит, рисуйте крутилку" или "если сервис A отдал ID, а в B по такому ID пока ничего нет - рисуйте крутилку и пингуйте"
- сами фронты без присмотра, всегда берут Redux, и занимаются копипаст-онанизмом

Алё, ребяты! Фронтенд сейчас - зачастую, наиболее технически сложная часть, и именно она продает продукт. А API - ключевой элемент, определяющий всю архитектуру. Нельзя технически лидить фронтовый проект, не понимая проблемы html/css/js, и не шаря в распределенных системах - чтобы строить API.

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

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

Про микросервисы

У нас на конторе сложилась архитектура Self-Contained-Systems: https://scs-architecture.org/index.html Типичный проект — это один какой-то бизнес с owner-ом, команда в ~10 человек на всё про всё, одна репа, одна БД, SPA-фронт на реакте, и бек на .NET/Java для API и каких-нибудь worker-ов, ~100 таблиц, ~20 скринов.

Интеграции делаются двумя способами: REST API для синхронных интеграций, Kafka — для асинхронных интеграций и репликации данных. Большая часть интеграций — асинхронная. Например, все данные для работы — всех сотрудников или города/страны, каждая аппа забирает себе в БД.

При этом, регулярно новые люди мне рассказывают что мы делаем не так. Что нам надо микросервисы. На вопрос: «а почему, по-твоему, штука, которая тебе employees в кафку кладет — не микросервис?», они обычно говорят что надо иметь userService, чтобы /users?get=123, и не забирать людей в каждую БД.

Таким товарищам по-кругу задаю такой пример. Есть два сервиса:

users.svc/get?age=23&city_id=2,3,1
locations.svc/get?id=1,2,3&country='RU'

Как вытащить всех пользователей с age=23 из городов с country='RU'? Вынуть все города России, и передать их ID в users? Или вынуть всех пользователей с age=23, вынуть их city_id и передать в locations?

Collapse )
animated

yarn plug-n-play

https://github.com/yarnpkg/rfcs/pull/101

Товарищи из yarn наконец-то догадались пропропатчить метод require(), и доставать модули прямо их кэша, вместо того, чтобы копировать их миллионами в node_modules. Чтобы сделать простое решение, как у всех, детям потребовалось почти 10 лет. Надо было всего-лишь повзрослеть, и перестать делать папе назло.

Вот тут детали: https://github.com/yarnpkg/rfcs/files/2378943/Plugnplay.pdf - особенно интересно в контексте "какой же пиздец в npm".

Надеюсь теперь хотя-бы npm как тула подохнет. Хотелось бы, конечно, дожить еще и до похорон node и всего говна вокруг неё.
animated

Самый пиздец в том...

Шутка в шутке - джависты показывают какие они дебилы, иллюстрацией про то, какие дебилы джаваскриптеры.



Я тут поспрашивал про картинку - оказалось что очень мало кто понимает в чем проблема с этим LinkedList. Параллельно смотрим на machine learning - вообще никто не помнит даже как матрицы умножаются.

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