Во многих языках есть штука, которую называют «тернарным оператором». Как правило, эта штука записывается, как 'c ? t : f'. Штука замечательная, без споров, но вот её название звучит как-то коряво.
Даже если вы не знаете латинского, то совершенно очевидно, что смысл слова «тернарный» означает «тройной», что по сути сводит смысл оператора к тому, что у этого оператора три, вместо двух аргументов. Ну, вот оператор сложения (a+b) — с двумя аргументами, но мы не называем его «бинарным оператором», так как таких операторов у нас много и совершенно непонятно о каком конкретно операторе речь. А вот тернарник у нас один, и все как-то привыкли, что «тернарный оператор» — это на самом деле «условный оператор в тернарной форме».
Это если бы в маленьком городке жил один негр по имени Степан Илларионович, а всё село его бы вместо этого называло «Негр». Потому что он у них такой один. Вот такое себе легкое проявление расизма в программировании, ребята.

Сегодня вспомнили о замечательном тексте с названием "Число Грэма на пальцах". Текст большой, но настолько прекрасен, что стоит потраченных на него 20 минут. Цитата из статьи для затравочки:

«Рассчитывать его бесполезно, да и не получится. Количество степеней здесь не поддается осмысленному учету. Это число невозможно представить, его невозможно описать. Никакие аналогии на пальцах™ неприменимы, число просто не с чем сравнивать. Можно говорить, что оно огромно, что грандиозно, что монументально и заглядывает за горизонт событий. То есть придать ему какие–то словесные эпитеты. Но визуализация, даже вольная и образная — невозможна. Если с тремя стрелочками еще хоть что–то удавалось сказать, нарисовать безбашню от Земли до Марса, как–то с чем–то сопоставить, то тут аналогий быть просто не может. Попробуйте вообразить себе тонкую башню из троек от Земли до Марса, рядом еще одну почти такую же и еще одну, и еще... Бескрайнее поле башень уходит вдаль, в бесконечность, башни повсюду, башни везде. И, что самое обидное, эти башни даже отношения к числу не имеют, они лишь определяют высоту других башен, которые нужно построить, чтобы получить высоту башень, чтобы получить высоту башень... чтобы через невообразимое количество времени и итераций получить само число.»

Приятного чтения!

http://sly2m.livejournal.com/620353.html

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

«Любой опытный программист пишет бабайко-устройчивый код, под бабайкой каждый понимает свой собирательный образ грабли, ударившей его по носу огромное число раз. У очень большого числа программистов это реюзабельность, у других, например, отказо-устойчивость, у третьих, "сложность" . Человек решил побороться со своей бабайкой, что вызывает уважение, но делает это достатачно топорно и не понимая, что это не объективная проблема, а его бабайка, что прискорбно.»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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