Экстраполяция IT
2.46K subscribers
89 photos
25 videos
305 links
Канал об IT в целом и о программировании в частности.

На канале объявлено военное положение и поэтому по вопросам рекламы пишите: @aratak, а деньги отправляйте сюда: https://send.monobank.ua/jar/97f7LwGQJF
加入频道
Лонгриды или коротенькие твиты?
Демагогия с философией (🤔), шутки с афоризмами (😂), новости и ссылки (🌎) или практические советы (👨‍🔧)?
Поэкспериментировать с разными форматами? Видеоподкаст там, аудиоподкаст.
Только около программирования или разбавлять всяким непрограммированием?
Стòит ли добавить рекламу?
 Ребята, на каждый пост в экстраполяции у вас наверняка есть свое мнение. Буду несказанно рад, если личным сообщением вы будете писать мне то, что думаете по поводу того или иного поста. Все хорошее будет обязательно опубликовано.


Хорошие курсы дают задачи на которых ты учишься. Учишься решать задачи. Иногда типичные задачи и часто типичными подходами. На хороших курсах не навязывают подходы но объясняют какие лучше. И инструмент решения - тот же php или ruby. Плохие курсы учат языку. Хорошие - решать задачи.

Самостоятельно сложно освоить и фундаментал и язык тк нет общей картины, что и зачем и какие задачи вообще надо решать. Как-то так.

(#экстраакадемия от подписчика, поддержите лайком, чтобы писал еще, клево же пишет!)
Итак, подошло к концу голосование и вот несколько мыслей по этому поводу:

1. Уж не знаю что сделать с аудио-видео, но я попробую в качестве эксперимента. Только не судите строго, это будут эксперименты.

2. Приятно удивлён тому, что вам хочется лонгридов. Ну как «лонгридов», особых телеграмовских лонгридов, который просто текст на несколько абзацев, а не 250 символов.

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

4. Что касается рекламы, добавил я этот пункт ради хохмы и хотел увидеть пару сообщений в личку, вроде «А! Ты же уверенно заявлял, что рекламы не будет! Дизлайк-отписка!». И, удивительно, таких сообщений нет, а почти половина проголосовавших совершенно не против рекламы. Планов зарабатывать на рекламе в канале все ещё нет, но подумать как использовать рекламу по-другому же можно? Пришлите мне личным сообщением (@aratak) идеи как можно использовать рекламу, если у вас есть мысли по этому поводу. Мне пока только приходит в голову идея розыгрыша вознаграждения за рекламу среди тех, кто по ней кликнул :-)

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

6. Уж не знаю как вам, но мне очень хочется видеть больше постов от Димы и Андрея, которые уже публиковались в Экстраполяции неоднократно. Поддержите лайком и Диму и Андрея, пожалуйста.

Всех обнимаю.
Когда стоит задача именно убеждать, что вы крутые? Правильный вопрос — это когда клиенту надо понять, хватит ли у него денег на вас. Потому что если не хватит, то вам обоим это сотрудничество не надо. А если хватит, но не на всё, то надо понимать, что ему стоит выбрать. Если ему хватит на всё - агонь. Если вы сказали, что ему хватит на все, а потом оказалось, что не на всё - вы больше не классные.

(#экстрасейлз от подписчиков)
Еще один #экстрасейлз от подписчика.

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

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

Итак, по словам подписчика «Экстраполяции» Павла нужно:

1. Дополнить отзывы нормальным описанием как именно мы работали с этим клиентом, какие методы использовали и почему они помогли.
2. Сделать с клиентом совместную двухдневную стратегическую работу. Прям вместе с ним определить, что за проблему он решает, как проблема проявляется, кого она затрагивает. Еще определить как клиент поймёт, что проблема решена и как будет выглядеть первая попытка ее решения.
3. Вместо громких рассказов о том, что «мы все из себя аджайл и работаем по скраму» простым языком объяснять, что поставлять мы будем помалу, но часто и сразу работающее, а самого клиента постоянно привлекать к обсуждению приоритетов, требований и результата.
4. Предложить контракт, в котором платежи будут завязаны на вот эти вот мелкие поставки: если мы определили цикл в две недели, привлекаем клиента к планированию в начале, координации в процессе и приемке в конце, то оплата идёт по результатам приемки. Если не успели, то оплаты не будет, пока не осилим.
Давайте затронем одну из самых животрепещущих тем айти, которые не связаны напрямую с программированием. Я имею ввиду рекрутинг. Тема обширная, и сказать есть много чего, так что все вместе почитать можно по тегу #экстрарекрутинг (блин, эта приставка «экстра» надоела даже мне, но что поделать, уникальность тегов и все такое).

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

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

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

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

Давайте «китайской комнатой» назовём некую способность человека правдоподобно общаться на заданную тему совершенно в ней не разбираясь. Если честно, я даже не понимаю порицание ли это рекрутерам в айти или комплимент.
Два шага назад и один вперед.

Большинство приложений, в которых я принимал участие, придерживалось принципа добавления новых возможностей с каждым релизом. В лучшем случае фичу просят пользователи, в худшем её придумывает команда, но результат всегда один и тот же, новые возможности в приложение нужно добавить без изменения работы старых. Иногда, конечно же, проводится ревизия и лишнюю функциональность удаляют, но стимулом сделать это, как правило, служит все те же отзывы пользователей или воображение владельцев продукта. Типа, «пользователи жалуются, что настройки стали слишком запутанные, давайте удалим то, чем не пользуются». В дополнении практически все популярные методологии разработки просто вопят о том, что инициация любых изменений в системе должна исходить от пользователей.

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

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

#китайскаякомната
Обратная сторона рекрутинга. Оказывается (внезапно!), что основная масса разработчиков достаточно умна, чтобы говорить о технологиях, выражать своё мнение, спорить и даже делать доклады, совершенно не разбираясь в предмете. Более того, обычное программирование в большинстве своём поощряет именно такой стиль работы.

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

#китайскаякомната
Собеседование на работу очень сильно похоже на первое свидание. И как на любом свидании, развиваться оно может по трём сценариям.

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

2. Когда кандидатов много и работодатель устраивает конкурс, вроде «а можно всех посмотреть» или «всем спасибо, у кого рост ниже 185 и грудь меньше третьего».

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

Побывав неоднократно по обе стороны баррикад, могу сказать, что первое, что нужно выяснять на собеседовании — это какой стратегии придерживается оппонент и решить стоит ли вообще дальше продолжать диалог. Иначе может выйти конфуз.

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

#экстрарекрутинг
Недавно личным сообщением мне написала подписчица Валерия, которая работает над проведением чемпионатов по программированию от мейлру (https://yangx.top/mrgchamps). У них много всяких соревнований проходит с призами и фондами. Предлагает новый вид развлечений в «Экстраполяции» — чемпионаты, задачки и всякие алгоритмические штуки. Я когда-то пытался что-то подобное сделать, но нужно что-то круче просто алгоритмических задачек, да?

Как вам идея Валерии? Устроим состязания какие-нибудь?
Внезапно Дмитрий напомнил о такой животрепещущей теме, как «микросервисная архитектура» шикарной цитатой из рабочей переписки:

«Ну ликвидируем мы свой монолит. Ликвидируем его месте с остатками понимания, ибо большие рефакторинги стоят долго и дорого. И что дальше? Не нравится слово "Монолит", так будет у нас какая-нибудь другая "микросервисная архиектура". Какая разница? Мы-то останемся все теми же самыми...»
. Подсмотрел формат на одном небезызвестном канале, решил попробовать. Дело в том, что этот пост уже был в Экстраполяции, но был давно. Многие его вообще не читали, а остальные забыли. Реагируем кнопочками за продолжение рубрики.

В общем, в эфире #перечитываяэкстраполяцию

——

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

В 2004 году был сформулирован принцип «ложной слепоты». Этот термин объеденяет в себе несколько разнообразных феноменов нашего восприятия. Обычно выделяют два вида ложной слепоты: слепоту невнимания и слепоту к изменениям. Слепота невнимания (или перцептивная слепота) подразумевает неготовность нашего мозга воспринимать изменения, которые мы не ожидаем увидеть. Как гориллу в ролике, которую уже окрестили «невидимой гориллой» и даже сайт отдельный есть по этому поводу. Еще причиной называют рассеянность, которая вызванная необходимостью полностью сконцентрировать внимание. Очевидно, что на себе вы этот феномен можете почувствовать только если о нем не знаете. И действительно, при повторном эксперименте с другими футболистами и совершенно другой макакой вы ее обязательно заметите, так как ожидаете ее увидеть.

Слепоту к изменениям тоже можно заметить гораздо проще, есть довольно много роликов в интернете на эту тему. Даже BBC снял передачу, посвященную этому феномену. В обычных условиях изменение наблюдаемой картины мгновенно обращает на себя внимание. Однако мы можем не замечать изменения, если они совпадают с коротким прерыванием наблюдаемой картинки. Это может быть кратковременное моргание экрана, монтажный стык видео или короткая помеха. В экспериментах по слепоте к изменениям обнаружилось, что почти 70% испытуемых не замечали подмены главного действующего лица, а изменения менее существенных деталей оставались проигнорированными почти в 100% случаев.

Казалось бы, отвязанный от программирования термин и совершенно не понятно как знание о этой слепоте можно применить. Но можно. Разработчик может быть настолько сосредоточен на решении конкретной задачи, которая полностью захватывает его внимание, что не видит очевидных проблем в соседнем методе или решает задачу каким-то странным образом. Отсюда и возникает требование делать ревью кода, идеи парного программирования и концепция работы по технике помидорок, хотя не все могут четко сформулировать почему эти требования существуют. Еще в команде всегда найдется такой разработчик, который будет неимоверно крут на фоне всех остальных, и его код, как правило, отсматривается сквозь пальцы. И менее опытные разработчики стесняются делать замечания более опытному товарищу. При отсмотре кода своего коллеги внимательно изучайте то, что могло быть пропущено по этому принципу и помните про эффект ложной слепоты.
Жили-были в одном городишке два ассенизатора — синьор и джун. Канализации у них там не было, а просто ямы с этим самым. И они это самое вычерпывали ведром и заливали в свою бочку, причем синьор, как более опытный специалист, спускался в яму, а джун сверху подавал ему ведро. И вот однажды джун это ведро не удержал и обрушил обратно на синьора. Ну, тот утерся, посмотрел на него снизу вверх и сказал ему с горечью: «Чучело ты, — говорит, — огородное, тундра! Никакого толка в тебе не видно. Так всю жизнь наверху и проторчишь».
 В эфире «Экстраполяции» наш постоянный автор Дима и, я думаю, уже пора прекращать каждый пост его отдельно помечать эпиграфом. Теперь у него будет фирменный тег.


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

Я вот могу затолкать себе в голову большой объём легаси-кода, выполнить его в уме, просочетать в разных вариантах, понять, что происходит и найти, что и как надо сделать, чтобы исправить баг или добавить фичу. А, значит, с неизбежностью, я и буду это делать. Потому что такая работа на рынке есть, её умеют делать не все, и за неё платят чуть больше, чем за клепание контроллеров и моделек с нуля, рассуждая о модульной архитектуре, SOLID, KISS, DCI и таком прочем. Потому что второе может больше народа.

Причём, легаси-код в любом проекте появляется за полгода, так что, от него не спасут даже серьёзные попытки не браться за легаси, а плясать по "generate new projectname" стартапчикам. Легаси-код неизбежен, как всадники апокалипсиса — проект или обрастает легаси-кодом, или аннигилируется заказчиком. В этом месте можете возражать и доказывать, что это не так, и что я не очень, надо просто хорошо писать и всё такое. Вспоминается старый анекдот про «и вы тоже рассказывайте».

#dimoneverything