Продолжаем рубрику #экстракибернетика об интеллекте. И в этот раз цитата про язык. Как всегда, лайк и репост для продолжения.

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

​​Противники гибкой методологии и приверженцы подхода «давайте сделаем всё за один раз, но качественно» приводят в пример строительство дома или проектирование автомобиля. Мол, там же смотрите как всё хорошо и делается всё за один раз.

Короче, если этого не видно, не значит что этого нет.

Иногда (а, если честно, почти всегда), очень тяжело остановиться программировать, особенно если очень остановиться надо.

Вот сейчас кипит работа одним прототипом, где, казалось бы, хватило бы связанных между собою статических аштээмелек, чтобы посмотреть на работу прототипа и ещё и другим показать. Но вот оказывается, что одни и те же данные показываются на странице, скажем, юзера и на странице заказа. «Зачем же дублировать? Давайте данные в переменные вынесем». Потом оказывается, что юзеры между собой могут быть связанными и, дабы не усложнять себе и без того копипастсткую жизнь, выносим связи в пишем лёгкий и ненавязчивый map. Потом такой же map появляется в соседних страничках, потом счётчики тоже бы неплохо показать настоящие и приходится писать userts.count. И где-то потом становится очень тяжело остановиться. В какой-то момент приходит светлая идея, что если вот эти вот аккуратно оформленные и структурированные YML-файлы сложить в базу в нужные таблички, то станет чуточку проще. И в итоге я не замечаю как прототип превращается в полноценное приложение.

К рекламе на Фейсбуке зацепил комментарий. Реклама сама об обучении ребёнка программированию и нацелена на американских родителей.

"Unless and until corporations stop sending these jobs overseas, there will be NO opportunities for "coding" in America. I personally know a LOT of people who were replaced by overseas contractors - along with engineers, paralegals, accountants, customer service - just to name a few."

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

#dimoneverything

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

Ваше следующее задание — оцентровать <div> по вертикали.

Мне тут недавно рассказали в чём кардинальное преимущество сеньора перед вон теми вот остальными милордами и сэрами или как там они называются. Говорят, что сеньор разработчик точно знает как надо делать. Мол, учитывает все подводные камни, возможные пути развития кода и выбирает самый оптимальный способ написать код вот прям здесь и прям сейчас.

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

​​Сегодня опять #экстрастереотипы и в этот раз поговорим о Бритве Оккама.

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

Во-первых, попрошу заметить, не Окка́ма, а О́ккама. Но это так, литературная фигня. Ещё вообще не важно, но тоже стоит упомянуть, что сам Уильям Оккама ни о какой бритве знать не знал, это просто его именем назвали принцип сильно позже.

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

Во-третьих и самых главных, нельзя сравнивать два абстрактрых объяснения между собой этим принципом. К двум утверждениям «давайте данные Монго будем складывать» и «давайте лучше в Постгрес и рядом Редис ещё развернём» Бритва применима? Подсказывает ли Оккама нам, что лучше начать с Монго, вместо Постгреса с Редисом, потому что там два, а тут один? Нет! Из двух утверждений «А вместе с Б» и «только В» вообще нельзя делать никаких выводов, потому как совершенно нельзя определить что из этого проще. Вполне может оказаться, что А+Б выйдет сильно проще, чем В. А может и не выйдет, Оккама тут бессилен вам помочь, давайте уж как-нибудь сами.

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

Самое интересное занятие при разработке — придумывать полезные функции.

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

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

Если честно, отношение двоякое. Сначала была твёрдая уверенность, что телеграмм — это такая себе платформа, где каждый может себе слепить то, чего хочется, с кнопками, реакциями и вообще всем, чем хочешь. А сейчас всё больше ощущения очередной реинкарнации ЖЖ.

Не то, чтобы это было плохо. Уверен, создатели телеграм тоже задумывали его, как платформу, а потом пришли настоящие пользователи и захотели вот это вот всё.

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


expect(client.phone).to eq(client.phone)


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

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

Во-вторых очередной раз убедился, что скваш (squash) коммитов — это неудобно.

В-третьих добавлю, что комментарии в гит-коммите должны быть самодостаточны. Комментарии, вроде Fixed issue CN-ERT-5553, наверное, помогают быстрее писать комментарии и быстрее принимать пулл реквесты, но совершенно теряют историческую ценность. Как вы понимаете, своим внутренним баг-трекером писатели кода делиться не собирались.

В итоге дедуктивного расследования выяснилось, что в какой-то момент деньги стали заканчиваться быстрее, чем набор несделанных фич и приходилось на чём-то экономить. И экономить начали на времени разработки. Сначала тест появился, как следует, с внятной плоской проверкой, вроде eq('+380999999999’). Потом попросили писать номер в определённом формате. Добавив валидацию, оказалось, что создание объекта для теста выходит чуточку сложнее. В итоге сначала убрали все вольные создания объектов и заменили на системный фабричный подход и тут (внимание) упало несколько тестов, которые говорят, мол, у вас там какой-то непонятный международный формат, а у нас тут надо просто кучу девяток. И программист в спешке решал чему же должен быть равен сгенерированный случайный номер телефона по определённому формату. Оказалось, что номер телефона строго равен номеру телефона и больше ничему другому не равен. Просто удалить тест он, конечно же, не мог, потому что падающие метрики никому не нужны.

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

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

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

И самое интересное, что это работает на всех уровнях абстракции. Ну, вот пишу я в специальном файлике resources :projects, а оно мне подготавливает целый набор урлов с правильными гетами, постами и патчами, которые указывают на специальные классы и методы в этих классах. Причем, если написать resource :project будет почти такое же самое, но, как говорит Василий Иваныч, есть один нюанс.

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

«Любая более-менее развитая технология неотличима от фреймворка».

#dimoneverything

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

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


https://thewire.in/tekfog/en/1.html

Синдром самозванца.

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

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

Иными словами нужно всегда держать внутреннего самозванца в тонусе.

«Закон Мура гласит, что объём папки node_modules удваивается каждый новый релиз»

Ребята, как вы? Давайте устроим перекличку и слова поддержки в комментариях.

Ребята, есть кто там в районах потише и в состоянии программировать?

> Нужен программист PYTHON. Есть огромные списки телеграм каналов проросейских ботов. На каждый из них нужно кидать репорт. Вручную это вечность.
> В API методах телеги есть функция account.reportPeer#c5ba3d86 peer:InputPeer reason:ReportReason message:string = Bool;
> Кто может написать Telegram БОТА, которая будет принимать в себя список телеграм каналов из текстового файла и автоматом кидать репорты на весь список (возможно выдать список обратно тех, которые не нашлись/уже заблокированы)