98% сеньоров-питонистов срезаются на этом вопросе на собесе!!1

В чём разница между [0]*3 и [0,0,0] ?

/rtfm разница между мутабельными и иммутабельными объектами

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

Вот сермяга (отсюда):
"Из тысячи доступных архитектурных практик ты, скорее всего, используешь три: микросервисы, REST и вечные попытки убедить команду обновить версии библиотек."

/defer swift всё? как его в эппле убивают в погоне за прибылью.

Первое правило геймдева: как можно быстрее сделать самый первый уровень.

Иначе вы быстро запутаетесь в куче технических нюансов и потеряете мотивацию.

Разбираю структуру игры "7 billion humans" (рассказывал тут , насколько она полезна для программистов). И нашёл в ней баг (или фичу , которая всё же на 51% баг).

Первое задание - надо сделать простую программу из трёх команд.
И тут сразу появляется нетривиальное: как отследить успешное прохождение уровня? Просто проверять конечную позицию тупо на совпадение с шаблоном неверно по многим причинам, и "7 billion" такого конечно не допускает. Однако , похоже , игра прозаически смотрит длину программы. Вот пример , когда я сделал достаточно длинную программу , которая приводит к нужному результату - но долгим путём. И "7 billion" её уже не засчитывает!
Или даже , не исключено , выполняется просто сравнение "кода" решения с эталонным.

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

/dev мощно обновились mini apps 2.0 для тележки.

Из свежих отчётов курсантов (с формата hard work)

...Порой встречаю на пулл реквестах ужасные составные конструкции из условий, где 2-3 уровня вложенности с блоками else для каждой. Даже не понимаю, почему не возникает ествественного желания немного хотя бы улучшить код. Поэтому, пройдя текущее задание, буду думать над докладом на команду, чтобы поделиться, видимо, сакральными знаниями об условных операторах и почему с ними нужно бороться.

...Изучил материал, грустно конечно. В смысле, материал великолепен, просто грустно что никто это не изучает и не понимает. С другой стороны откуда им это вообще изучать, если в РУ Сегменте вы один, а в EU... Ну это надо быть явно заинтересованным чтобы святых (computer science) читать.
(это по заданию "создать функциональный интерфейс с помощью F-ограниченного полиморфизма":)

...Несколько лет назад увидел в одной статье такую фразу: "Циклы в вашей программе - это баги". Тогда я её не понял, но предложенная там же идея заменять циклы на функциональные конструкции типа map-reduce мне понравилась.

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

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

...Это занятие заставила меня хорошо подумать и переосмыслить свои подходы в разработке. Кажется, в свой список подходов и методологии разработки - aka советы, я добавлю несколько подходов из материала. Одно из занятий, что сильно поменяли мою картину мира разработки. Хочу, чтобы дальнешие занятия были увлекальнее и полезнее. Подобные материалы я искал бессонными ночами, наконец я их нашел. Все рядышком друг к другу.

/win в js появился новый оператор безопасного присваивания
?=
срочно забираем. (впн)

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

5% адекватных просто говорят: "X лучше потому, что Y". Это реальный аргумент, с которым можно работать и, соответственно, найти лучшее решение для данного проекта.

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

Мастерство -- это когда данная пропорция становится 20/80.

/eureka Такую физику мы одобряем: расчёт траекторий движения котиков.

Из отчёта курсанта:

Почти 2 недели не возвращатся к проекту по ETL процессам, т.к. были срочные рабочие задачи. Всегда сложно после перерыва вникать обратно в проект, даже если бОльшую его часть написал ты сам. Это больше моя психологическая проблема. Решение наверное уделять проекту постоянно хотя бы 15 минут в день, чтобы контекст не пропадал.

Да, у многих так; вы придерживаетесь рекомендаций по скоростному ведению заметок с трека "Элитный программист"? Я там третий материал добавил недавно в подборку "Технологии поддержки мгновенной перефокусировки".

Ну и документировать проект конечно очень желательно , на третьем логическом уровне, где что зачем. За 15 минут , просто что-то ковыряя в коде , вы скорее всего ещё больше запутаетесь. Лучше за эти 15 минут пишите документацию и комментарии (мышление письмом).

Обновлённый список наших блогеров.

В этом месяце безусловные победители: Новиков и Доронин! 💥🤘🚀

Конечно, 80% со временем сливаются, ну штош...

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

Такое мы забираем:
Marten (.NET Transactional Document DB and Event Store on PostgreSQL)
Use proven PostgreSQL database engine, its fantastic JSON support and ACID compliance as the underlying data store.

Пост ВКонтакте:
Почему подходы мейнстрима, где кодовые базы — сплошные big balls of mud, почему весь этот "детский сад штаны на лямках", так популярны, и какую алгебру (с учётом тотального детского сада) вам надо изучать прежде всего.

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

...В одном нагрузочном (как предполагается:) проекте посоветовал пацанам выбрать эрланг 🙈

Почему Erlang? Ну потому что с учётом всех его технических плюсов, оказывается также очень удобно интегрировать семантику бизнес-процессов и его семантику. Почему удобно? :) Потому что он прозрачно маппится в алгебру процессов (π--calculus), но это уже совсем другая темка...

/rtfm Обычно люди, которые покупают книги по программированию, никогда их не читают. Между прочим, /rtfm читается также, как read the fine manual

В честь дня математики написал пост в вк.

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

Я не забросил кстати игру для обучения программированию (которую обещал к 1 декабря :). На самом деле 80% времени ушло на UI. Я перебрал с десяток самых разных 2D-движков - ни одного и близко нету , чтобы отвечал моим достаточно простым требованиям. Поэтому как обычно пришлось всё делать самому :) графика , анимация, переопределение кучи стандартных контролов UI...
Возможно к 1 января сделаю какой-то альфа-прототип с начальными уровнями, если снова не возникнет засад с UI (не забывая, что всем абсолютно пофиг:) .

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

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

После чего достаточно естественно мы приходим к языкам наподобие Erlang, где модель акторов прекрасно формализуется с помощью activity semigroups (фундаментальная часть математической семантики эрланга), ну и т.д.
Загадывать ничего не буду конечно, ведь надо ещё и что-то кушать...

=

"Не учишь матан -- превратишься в метан." (с)
(матан на самом деле наименее востребован в cs, а что надо - в закрепе основного паблика)

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

Где-то с уровня рекурсии пропадает классическая схема составления кода из последовательности инструкций, "оно" какой-то магией начинает работать само, но как правильно составлять подходящие сложные заклинания, совершенно непонятно, а вся предыдущая муть императивщина и 100500 решённых задачек на литкоде/с собесов с этим вообще никаким боком не стыкуется.

"Ну и что полезненького мне даст вся эта ваша математика??"

Например, вот как писать код по-взрослому:
Dependently-typed HTTP headers in Idris
(моделирование HTTP-заголовков строго по RFC )

Дана сермяга с достаточно подробным разбором: завтипы, correctness by construction, making illegal state unpresentable etc.

Для повседневных задач получается конечно накладно, но такой (абсолютный) уровень качества обычно и не требуется. А вот для критически важных систем критически важно.

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

Вдогонку-2. На самом деле практически в любом функциональном языке вы можете легко и просто реализовать парадигму MISU (marking illegal states unrepresentable)! Потому что по большому счёту ФП именно MISU и подразумевает автоматически.

Вам остаётся лишь make representable states valid. Для этого вам прежде всего понадобятся sum types: если вы с их помощью определите набор допустимых состояний, то все эти состояния должны быть корректными и иметь определённую семантику. Другими словами, если ваш тип описывает все возможные состояния, то каждое из этих состояний должно иметь осмысленное значение в контексте вашей программы. Нельзя оставлять "дырки" в определении типа (когда некоторые состояния не имеют смысла).

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

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

AI изобрёл ветряк, который в 7 раз эффективнее традиционной версии, настраивается на турбулентность окружающих зданий, эффективно работает при скорости ветра 3,6 м/с (номинал большинства турбин -- 10 м/с) и т.п.
(отсюда)

Белковый инженер до таких конструкций (справа вверху) скорее всего не додумался бы в принципе :)

Подозрение, что и будущие ИТ-архитектуры, которые станет создавать AI с нуля, тоже смогут работать значительно продуктивнее современных, но... внутри будут так невероятно "запутанны" для человеческого понимания, что кожаным станут совершенно недоступны.

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

Вместо значений — "волновые функции", вместо ИЛИ -- их "суперпозиция", вместо И -- их "коллапс" и т.п. Такие "калкулусы" могут быть представлены многомерными тензорными вычислениями, где каждое измерение соответствует отдельной "оси" параллельных операций etc.

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

А по-взрослому, донам сегодня выложил очередной материал "Отладка как наука". Существует ли теория отладки в целом? В основе теории отладки лежит универсальный метод: вы можете её ускорить так [...]

Думаю вот, а тем ли я вообще занимаюсь? ↑↑↑

Программист приходит к гадалке, она ему:
-- Я вижу в вашем будущем много кофе и бессонных ночей...
-- Да это не будущее, это мой обычный спринт!

ит-работодатели: я открыл вакансию джуниора, и мне за день насыпалось 100500 резюме гы гы гы

ит-сеньоры: я открыл своё резюме, и мне за день насыпалось 100500 вакансий гы гы гы

Хвастанье, что толпа ломится на джуниора -- это просто от безысходности (хотя конечно щёки приходится надувать: дескать у нас такая крутая команда супер-пупер-спецов, просто вот в помощь им набираем; ага ага).

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

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

Вам могут дать тестовое задание с "секретным" компонентом без исходников, а когда вы его активируете, ваш компьютер скушает вирус-шифровальщик. Или симпатичная эйчарка разведёт нас на секс крипту. Или вам "гарантируют" помощь и трудоустройство с постоплатой со своей зарплаты, вы найдёте работу на 98% своими усилиями, но потом будете месяцами отдавать до 80% зарплаты. (И не исключено, что вас выгонят достаточно быстро: возможно, это был целиком развод со стороны пары рекрутер-кадровик для распила корпоративного бюджета.)
Или вы будете бесплатно работать "за опыт" над реальными проектами. итд итп.
Это всё реальные неоднократные случаи, на ютубе можете легко найти.

=

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

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

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

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

Но, с другой стороны, всё более вероятно, что на этой вакансии вообще никто не получил и не получит работу…

Будь осторожен. Следи за собой. (с)