Сегодня опять субботний анекдот с альтернативным юмором. Вспоминаем булеву алгебру и смеёмся :-)

Заходят три логика в бар. Бармен спрашивает:
— Кто-нибудь будет что-нибудь пить?
Первый:
— Не знаю
Второй:
— Не знаю
Третий:
— Нет.

Добрый вечер, ребята!

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

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

В итоге имеем два лагеря пользователей групповых чатов: первая очень сильно отвлекается на них, вторая ими не пользуется, как чатами. И полезность чатов для этих двух групп сведена к минимуму.

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

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

У каких-нибудь коренных племен каких-нибудь островов какой-нибудь Новой Зеландии может быть свой язык, терминология которого в корне не совпадает с другими языками. Сам принцип построения предложений и формулировка мысли может в корне несоответствовать тому, к чему мы привыкли. Скажем, у такого племени нет понятия «лево» и «право», а ориентируются в пространстве аборигены исключительно по сторонам света. У них есть понятие «южнее» или «восточнее», а приложение-навигатор будет объяснять не относительное положение поворота, а абсолютное. «Через сто метров держитесь южнее» или как-то так. Давайте для сгущения красок этой аллегории предположим, что у этого же племени не существует вопросительных предложений, а только лишь утвердительные. И вместо вопроса, допустим, «Как пройти в библиотеку?» на этом языке канонично говорить «Ты мне должен показать дорогу в библиотеку». И, чтобы еще сильнее вас запутать, давайте скажем, что этот язык напрочь лишен местоимений и числительных. Пример с библиотекой с этим новым правилом будет звучать, как «Чака должен показать Фасимбе дорогу в библиотеку». А Чака такой в ответ «Обезьяноподобным шагом на юго-восток и потом медвежий шаг на юг».

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

Сейчас очень модно рассуждать на тему того, что настоящий программист не должен привязывать себя к какому-либо языку и должен мыслить категориями, выходящими за рамки конкретного языка или парадигмы. Мол, формулировка собственной профессии или должности, вроде «PHP-разработчик» или «HTML-верстальщик» обречена на провал и с такими людьми лучше не стоит иметь дело. А дело как раз и состоит в том, что язык программирования в первую очередь — это язык, а во вторую — программирования. И важно знать на каком языке думает программист, чтобы понимать его основу мышления и точку опоры в дальнейших дискуссиях. Не спрашивайте на каком языке программирования умеет программировать собеседник. Спрашивайте на каком языке он думает.

Ребята, три темы на выбор и я прям не знаю с чего начать. Как думаете, о чем написать? Вам слово.

🎓 Где находится в программировании филология.
💩 Как админам правильно смотреть на код разработчиков.
🛣 Почему мэр виноват во всех ямах на всех дорогах города.

Да, вы все правильно поняли, в одном из смайликов страшный спойлер.

Этот доклад с какого-то митапа (а судя по залу, людей там не слишком много) я пересматриваю где-то раз в пару месяцев и каждый раз смеюсь до слез. Сойдет за субботнюю развлекательную программу?

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

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

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

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

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

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

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

Вспомните только когда перестает быть интересным играть в компьютерные игры в режиме «против компьютера». Когда с завидной точностью можно предсказать поведение ботов в игре. Вначале, как только знакомишься с хорошей игрой, поведение «автоматонов» выглядит непредсказуемым и интеллектуальным. Поиграв немного, человек обучается и запоминает предыдущий опыт. А боты в играх — нет. И «хорошим ИИ» считают тот, который предсказать можно реже остальных. «Идеальным ИИ» назовут такого игрового бота, которого нельзя будет предсказать, потому как его поведение будет постоянно совершенствоваться и изменяться. Знаете ли вы игры, в которых ИИ обучается на поведении игрока (или всех игроков в мире)? Напишите мне личным сообщением, я вот таких игр не знаю.

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

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

Ребята, я вернулся! Давайте назовем этот перерыв творческим отпуском, процессом переосмысления и познания себя или как-нибудь так. И я очень рад, что вы все еще со мной!


За последние два месяца тишины на этом канале произошло много чего интересного и хочется обсудить с вами все и сразу. Во-первых телеграм стал переполнен разнообразными каналами на любой вкус и цвет, обо все на свете и в каком угодно виде. Безусловно, это кажется хорошим знаком, но меня вот расстраивает упавшее качество содержимого этих каналов и засилье рекламы и «взаимного пиара» между каналами. Хочу очередной раз заметить, что платной рекламы в канале «Экстраполяция IT» нет и не будет. Еще напоминаю, что на этом канале нет еще и новостей. Что там ест на завтрак Илон Маск, как сильно подорожал биткоин и сколько лет очередной бабушке, создавшей мобильное приложение вы с легкостью узнаете на других каналах. А я слишком вас всех люблю, чтобы попусту тратить ваше время.

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

С уважением, «Экстраполяция IT».

В современном мире айти-разработки, при преобладании удаленной работы и сотрудничестве с фрилансерами появился занятный феномен перекладывания ответственности за простой в работе. В офисном мире, если у программиста нет задач, он может делать что угодно и ему за это все-равно заплатят, он же в офисе! У фрилансеров же обратная ситуация. Почему-то принято считать, что отсутствие задач у фрилансера (или удаленного сотрудника) – это проблема самого фрилансера. Решение выбирают фрилансеры вполне логичное и очевидное — берут себе несколько проектов и постоянно переключаются между ними. Из-за этого, собственно, и пошла легенда, что фрилансером быть тяжелее, чем офисным сотрудником.

А быть должно все наоборот. Только никому не говорите, что это я вам рассказал. Ставьте сами себе задачи с формулировкой «Мне же все-равно нечего делать, поэтому буду делать вот эту полезную задачу. Остановить меня можно только другой задачей». Профессиональным будет считаться не только качественное выполнение таких задач, тщательное описание до и отчет после, но и адекватность поставленных задач. Очевидно, что задач вида «перепишу-ка я вот этот модуль, потому что там код – говно» быть не должно в принципе, а вот формулировка «помнится, заказчик давно хотел вот эту фичу, а сейчас как раз подходящий момент, чтобы ее сделать» крайне удачная. Дополнительной выгодой от такой стратегии поведения будет демонстрация руководству проекта (менеджеру, если хотите) того, как по-вашему должны выглядеть поставленные вам задачи.

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

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

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

https://medium.com/@sergiodxa/how-to-keep-updated-with-the-javascript-ecosystem-97c8e36c2c3f

Тесты в первую очередь — механизм проверки того, что-то, что написано — работает. Вопрос не в том, необходимо покрывать тестами или нет, а вопрос в том, как убедится, что только что написанный код работает. Существует несколько неправильных способов писать рабочий код. Можно открывать интерактивную консоль, выполнять код там и копировать его внутрь методов, можно использовать дебаггер для перехвата управления приложением и опять же, в интерактивной консоли пробовать угадать рабочий код. Можно после каждого изменения в любом месте перезапускать сервер (возможно, в вашем фреймворке есть способ делать это автоматически) и вручную проверять поведение приложения в целом. А можно попытаться автоматизировать этот процесс и проверять код сразу в тестах. В итоге появились три запрещающих правила:

1. Табу на использование интерактивной консоли в процессе написания кода.
2. Запрет на дебаггер при разработке.
3. Нельзя держать запущенным приложение локально, чтобы иметь возможность кликать, и проверять результат.

Соблюдая эти три нехитрых правила не писать тесты просто не получается.

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

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

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

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

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

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

Но все мы знаем, что в результате побеждает стандартизация, а не профессионализм.

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

«Не смехотворно ли платить золотом за бесполезные корневища?», спрашивал какой-то там историк спустя полтора века. Да, уж. Через полтора века наверняка уже смехотворно.