Лаборатория Математики и Программирования Сергея Бобровского – Telegram
Лаборатория Математики и Программирования Сергея Бобровского
1.29K subscribers
1.19K photos
24 videos
931 links
ЛаМПовое с Бобровским
Download Telegram
Разработчики, в университетах не обучавшиеся, "в ходе самообразования" или "на онлайн-курсах" быстро нахватываются множества когнитивных багов и потом тащат их с собой всю свою карьеру, потому что не имеют в уме никакой фундаментальной защиты от подобного.

Простой пример, что даже в SQL делаются явные ошибочные различия между базовыми таблицами и представлениями на уровне синтаксиса: CREATE TABLE и CREATE VIEW. Естественно, что человек, не обученный теоретически мыслить в реляционной вычислительной модели, и дальше начинает их "различать" в своей практике, хотя по сути это одно и то же.

По мелочи, в CREATE VIEW сразу указывать список столбцов плохой стиль, не надо так: всегда делайте AS.
И WITH CHECK OPTION для апдейтов добавлять полезно.

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

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

"Госдума в третьем чтении одобрила поправки в Налоговый кодекс, которые расширяют налоговые льготы для IT-отрасли."

Ну, да, процент по ипотеке ещё снизили, проще стало попасть в ИТ-реестр (но халявщиков вроде банков и маркетплейсов наоборот собираются исключить, и поделом) и т. п.

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

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

Сейчас ключевая проблема, что в цепочке "обучение - работа" имеется огромный разрыв интеграции.

Даже явно способным джуниорам с хорошей подготовкой сегодня весьма трудно найти первую работу. Процесс может затягиваться на многие месяцы.

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

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

Тут достаточно совсем простых мер, а в результате до работы в ИТ будет уже прямо завтра добираться множество способных молодых ребят, с нормальными базовыми знаниями, полных энтузиазма, хорошо обучаемых, и не надо будет выдумывать глупые меры по попыткам обучения ИТ толп школьников с околонулевым выхлопом. Потому что иначе в итоге подобных глупых мер войти в ИТ даже самому способному начинающему в диких толпах оленей станет просто невозможно.
По мере погружения в computer science и ФП я одно время горячо верил в активное повторное использование небольших функций. Очевидно, полная глупость, когда огромное количество самых разных приложений в моём компьютере имеют каждый свою собственную проверку орфографии и систему логина; и сколько мозгов было потрачено на создание практически идентичной функциональности? Однако со временем я всё чаще наблюдал, как команды с энтузиазмом подключали готовые компоненты, но затем быстро задумывались об их замене, как только понимали, что могут получить на 10% меньший размер программы, создав собственную версию с меньшим количеством функций.

Потом я однажды прочитал знаменитое эссе Дуга Макилроя (легендарный американский математик и программист, автор пайпланов в Unix и многих утилит, принимавший участие в проектировании PL/I, Снобол, C++...) "Компоненты программного обеспечения массового производства" ("Mass-Produced Software Components", "a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7th to 11th October 1968") в котором вместо универсальных библиотек предлагались "семейства библиотек", "генерирующие" варианты библиотек, подходящие для конкретного приложения.

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

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

В СильныхИдеях выложил по этой теме материал
"4 универсальных принципа проектирования API".
По следам наших выступлений :)

Мишустин постановил сформировать 35 индустриальных центров компетенций, которые будут координировать разработку тяжёлого корпоративного софта (PLM-системы например) по импортозамещению. Выделяется 37 млрд. рублей; освоение этого бюджета начнётся уже ближайшей осенью, а где быстро найти много свободных программистов под это всё, я пояснял позавчера.

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

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

1. Ясный код.

2. Вычислительное мышление.

Это пока были хипстерские шаги, а вот далее начинается секретная кроличья нора :)

3. Чистое функциональное программирование.

4. Транспиляция (эквивалентные преобразования исходных текстов программ на разных языках) -- запилить свой транспайлер.

5. Гомоиконичность (изоморфность синтаксиса и AST, код как сущность первого класса) -- попрактиковаться в Лиспе на сотне задачек с акцентом на "code as data".

6. Ссылочная прозрачность.

7. "Well typed programs cannot go wrong" Robin Milner 1978

8. Изоморфизм Карри-Ховарда.
Я всегда радуюсь, когда мне удалось обучить очередное живое существо программированию с целью сделать этот мир чуточку лучше, и даю обет бодхисатвы всегда этим заниматься с безмерным усердием, даже если для этого мне придётся мучиться в адах в миллиарды раз дольше трёх неисчислимых великих кальп, равных количеству временных промежутков (thang cig) в каждом дне из тысячи великих кальп!

Технически, в каждом дне 900 тханг чит, в году их 328500.
В великой кальпе 4,32 миллиарда лет, да на тысячу,
получаем 1 419 120 000 000 000 000 тханг чит.
Берём это как дни, да на три неисчислимые кальпы, да на, допустим, 9 миллиардов раз,
и получаем округлённо в годах
100 000 000 000 000 000 000 000 000

100 септиллионов лет! Вот на что я готов ради вас, дорогие! )))

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

Хотя конечно, когда проект исходно был спроектирован криво, он весь целиком одна сплошная опасность :) И надо всё переделывать с нуля.
Очень надеюсь, что в ближайшие годы проекты наподобие
Bun (a fast all-in-one JavaScript runtime)
или Deno (a modern runtime for JavaScript and TypeScript)
сбросят таки node.js с пьедестала.
Мы все часто слышим, что написанию хорошего кода (и качественной разработке в целом) можно научиться только опытным путём, методом проб и ошибок, через реальные проекты; или даже, возможно, хорошими программистами рождаются, а не становятся. И при этом мы постоянно читаем о принципах, которые лежат в основе хорошего кода: инкапсуляция, модульность, связность... Многие из них контринтуитивны, то есть были изобретены/открыты в академических кругах, мировыми специалистами в computer science.

Нету ли тут некоего противоречия? :)
Diagram as Code: рисуем красивые диаграммки питон-кодом.

Diagrams lets you draw the cloud system architecture in Python code. It was born for prototyping a new system architecture design without any design tools. You can also describe or visualize the existing system architecture as well.
Отличное выступление на PyCon 2015:
"Beyond PEP 8 -- Best practices for beautiful intelligible code"
Distillation of knowledge gained from a decade of Python consulting, Python training, code reviews, and serving as a core developer. Learn to avoid some of the hazards of the PEP 8 style guide and learn what really matters for creating beautiful intelligible code.

Классный пример, как 20 строчек кода отрефакторить в 3 строки, да и вообще поразбирайтесь с этим примером, рекомендую.

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

Ну если только вы не занимаетесь у меня ))) я бы сперва настоял на том, чтобы вы прежде всего исправили магическую константу: жёстко закодированный IP-адрес (мой курс Ясный Код в помощь).
Программисту обязательно нужна раздельная/сплит клавиатура: чтобы можно было программировать на пляжном шезлонге (ну или в подобном "личном" кабинете :). Правда, в магазинах она безумно дорогая, лучше на али заказывать.
Джуниоры нужны всё меньше?

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

А брат этого товарища занимается разработкой фреймворка синтеза программ, который оптимизирует сам себя, и умеет генерировать formula simplifiers под конкретные предметные области.

В СильныхИдеях сделаю небольшой разбор этой темы, которая в наших прозаических целях очень важна прежде всего тем, что, как показано математически, даже сильно сложные функции (логику) в повседневном кодинге можно конструировать из очень небольшого числа строительных блоков, микро-паттернов (на курсах для начинающих, впрочем, делаю на этом особый акцент уже не один год).
Доктор философии скрестил ежа с ужом Питон с Лиспом. Получилось очень забавно.
Фишка из web3 — как организовывать журналирование без, например, SS-таблиц или LSM-деревьев, когда ноды могут покидать сеть и возвращаться в неё произвольно по своему усмотрению: брать цепочку proof-of-work в качестве целостной и доказанно корректной информации о том, что произошло, пока узла не было в онлайне.
...то странное чувство, когда как обычно внезапно закончились минуты на каршеринг GitLab CI/CD, а оплата долларами теперь традиционно сильно усложнена, и в результате вся система у знакомых пацанов встала почти намертво )))

Остаётся импортозамещённый cicd яндекс, причём они даже вроде с GitLab как-то совместимы, хотя там честно говорится, что "Пайплайн CI/CD сложно применять для больших и сложных монолитных систем". Так CI/CD как раз и нужны именно для таких систем в первую очередь )
Маленькие и несложные монолиты полезно как раз вручную обслуживать.
Задачка, которую 99% гуманитариев решают правильно, а 99% программистов ошибаются.

Строка "x+(x-x)+x" палиндром?
(никакого подвоха в плане кодировок символов и т.п.)

Спойлер: нет.
"Top Competitive Programmer vs. LeetCode's HARDEST Questions" )))))

"Top Competitive Programmer vs. FAANG Interview Questions" тоже хорошо.

Чем чище (в буквальном смысле) ваше вычислительное мышление, чем больше в нём абстракций и математики, тем легче вам будет справляться с детским садом собеседований, даже с незнакомыми темами, просто потому что они будут для вас "конструктивно" просты.
А вот стиль кодирования у парнишки совсем слабенький, у меня ребята после начального курса "28 задач" такой кривой код уже не пишут. Поэтому к его рекомендациям за пределами спортивного программирования рекомендую относиться с большой опаской :)
Между прочим, интерфейс AutoCloseable из Java 7, методы наподобие File.open в Ruby, паттерн RAII в Rust и C++, и даже хаскелевская bracket -- это всё один и тот же мета-паттерн, впервые реализованный как макро with-open-file в Common Lisp в 1980-х годах.
Разбираем его в очередном материале в СильныхИдеях.
Hazel is a live functional programming environment that is able to typecheck, manipulate, and even run incomplete programs, i.e. programs with holes.

Вот это действительно Наука, а не эти ваши кококопилоты )))