Похоже, что ЛеКун (VP & Chief AI Scientist в FAIR) реально становится тем единственным человеком (или всё же он засланец из космоса?), который с помощью своего интеллекта поставит окончательную точку в нашей цивилизации :) Пока основной причиной, почему не получалось создать "AI, который захватит мир", считалось бабло. Не хватало его прозаически для масштабных прорывных исследований. И вот наконец ЛеКуну дали таки мультимиллиардные бюджеты: вписали FAIR в подразделение Метавселенных, куда ресурсов под модную темку выделено просто немеряно.
На радостях гуру опубликовал мощный материал
"A Path Towards Autonomous Machine Intelligence Version 0.9.2, 2022-06-27"
Дескать, сопротивление бесполезно.
Увы, но в данном случае действительно ничего серьёзного, что можно было бы FAIR противопоставить, нигде в мире больше и близко не видно.
На радостях гуру опубликовал мощный материал
"A Path Towards Autonomous Machine Intelligence Version 0.9.2, 2022-06-27"
Дескать, сопротивление бесполезно.
Увы, но в данном случае действительно ничего серьёзного, что можно было бы FAIR противопоставить, нигде в мире больше и близко не видно.
В своей знаменитой книге "Как стать хакером" Эрик Рэйнмонд (один из основателей Open Source Initiative) заявил: "ни одна проблема не должна решаться дважды". Обычно мы следуем этому принципу, создавая библиотеки, выдумывая искусственные приляпки вроде принципа DRY, и т. п. То есть, имея два схожих компонента и достаточно денег, почти всегда можно сделать систему "лучше", представив их одним "многократно используемым" компонентом с настройками.
Однако чтобы лозунг Раймонда стал буквальной правдой, единственный путь вперед тут только такой: автоматическая генерация программ (Program Synthesis) + AI.
Да, Copilot пока выглядит ужасающе :) Но, это ведь только начало.
Однако чтобы лозунг Раймонда стал буквальной правдой, единственный путь вперед тут только такой: автоматическая генерация программ (Program Synthesis) + AI.
Да, Copilot пока выглядит ужасающе :) Но, это ведь только начало.
Разработчики, в университетах не обучавшиеся, "в ходе самообразования" или "на онлайн-курсах" быстро нахватываются множества когнитивных багов и потом тащат их с собой всю свою карьеру, потому что не имеют в уме никакой фундаментальной защиты от подобного.
Простой пример, что даже в SQL делаются явные ошибочные различия между базовыми таблицами и представлениями на уровне синтаксиса: CREATE TABLE и CREATE VIEW. Естественно, что человек, не обученный теоретически мыслить в реляционной вычислительной модели, и дальше начинает их "различать" в своей практике, хотя по сути это одно и то же.
По мелочи, в CREATE VIEW сразу указывать список столбцов плохой стиль, не надо так: всегда делайте AS.
И WITH CHECK OPTION для апдейтов добавлять полезно.
В целом, если у вас в проекте между таблицами и представлениями возникают какие-то ощутимые различия (для "пользователя" ваших запросов они выглядят явно по-разному например), значит, всё надо переделывать.
Просто запомните, что таблицы и представления в реляционной модели -- это одно и то же, поэтому и в вашем проекте должно быть ровно так.
Простой пример, что даже в SQL делаются явные ошибочные различия между базовыми таблицами и представлениями на уровне синтаксиса: CREATE TABLE и CREATE VIEW. Естественно, что человек, не обученный теоретически мыслить в реляционной вычислительной модели, и дальше начинает их "различать" в своей практике, хотя по сути это одно и то же.
По мелочи, в CREATE VIEW сразу указывать список столбцов плохой стиль, не надо так: всегда делайте AS.
И WITH CHECK OPTION для апдейтов добавлять полезно.
В целом, если у вас в проекте между таблицами и представлениями возникают какие-то ощутимые различия (для "пользователя" ваших запросов они выглядят явно по-разному например), значит, всё надо переделывать.
Просто запомните, что таблицы и представления в реляционной модели -- это одно и то же, поэтому и в вашем проекте должно быть ровно так.
По следам наших выступлений :)
"Госдума в третьем чтении одобрила поправки в Налоговый кодекс, которые расширяют налоговые льготы для IT-отрасли."
Ну, да, процент по ипотеке ещё снизили, проще стало попасть в ИТ-реестр (но халявщиков вроде банков и маркетплейсов наоборот собираются исключить, и поделом) и т. п.
В целом однако, надо признать, что с другой стороны и так избалованные айтишники избаловываются ещё больше, и это плохо. Стратегическая цель зарплата 300k/сек пока далековата )))
На самом деле, в ИТ есть одна самая главная большая боль, где государство могло бы очень здорово помочь, при этом сильно выиграв и само. Ведь его цель -- получить в ближайшие годы как можно больше программистов на российском рынке, и сделать это можно легко и просто.
Сейчас ключевая проблема, что в цепочке "обучение - работа" имеется огромный разрыв интеграции.
Даже явно способным джуниорам с хорошей подготовкой сегодня весьма трудно найти первую работу. Процесс может затягиваться на многие месяцы.
При том, что уже через 2-3 года работы они идут нарасхват по отличным зарплатам. Но связываться с ними с нуля компании не хотят, и этому есть такая основная причина, что процесс найма в ИТ -- полный зашквар, а в отделах кадров работают преимущественно рептилоиды (как подбор сотрудников устроен за кулисами изнутри, подробно разбираю на курсе карьеры).
И вот тут правительство могло бы реально помочь, очень быстро получив на рынке тысячи уже фактически готовых специалистов. Надо просто взять на себя те небольшие (на фоне других мер поддержки ИТ) риски, связанные с поддержкой начинающих джуниоров, с помощью именно в устройстве на первую работу. Например, вычитать из налогов зарплаты джунам и расходы на их обучение, и т. п.
Тут достаточно совсем простых мер, а в результате до работы в ИТ будет уже прямо завтра добираться множество способных молодых ребят, с нормальными базовыми знаниями, полных энтузиазма, хорошо обучаемых, и не надо будет выдумывать глупые меры по попыткам обучения ИТ толп школьников с околонулевым выхлопом. Потому что иначе в итоге подобных глупых мер войти в ИТ даже самому способному начинающему в диких толпах оленей станет просто невозможно.
"Госдума в третьем чтении одобрила поправки в Налоговый кодекс, которые расширяют налоговые льготы для 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".
Потом я однажды прочитал знаменитое эссе Дуга Макилроя (легендарный американский математик и программист, автор пайпланов в 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 млрд. рублей; освоение этого бюджета начнётся уже ближайшей осенью, а где быстро найти много свободных программистов под это всё, я пояснял позавчера.
Кстати, если вы эйчар/рекрутер, ну или просто ищете хороших джуниоров: напишите мне в тг или в основной паблик вк, иногда у меня в занимающихся бывают очень способные, которые ищут первую работу без опыта. Иногда -- не в том смысле, что "иногда очень способные" -- у меня все очень способные :) , потому что достаточно строгий отбор на курсы, а в том смысле, что "иногда ищут работу". Как правило из регионов, поэтому ищут удалёнку, ну и понятно, что в такой ситуации "сразу на удалёнку без опыта" возникают определённые проблемы с поиском. Сведу вас бесплатно.
Пишите основные скиллы которые от кандидата хотите (напомню, речь только про "на удалёнку без опыта"), и обязательно вилка зарплат под них (никаких "по договорённости", "надо сперва с человеком поговорить" ...). Без конкретных цифр зарплат сразу в бан :)
Мишустин постановил сформировать 35 индустриальных центров компетенций, которые будут координировать разработку тяжёлого корпоративного софта (PLM-системы например) по импортозамещению. Выделяется 37 млрд. рублей; освоение этого бюджета начнётся уже ближайшей осенью, а где быстро найти много свободных программистов под это всё, я пояснял позавчера.
Кстати, если вы эйчар/рекрутер, ну или просто ищете хороших джуниоров: напишите мне в тг или в основной паблик вк, иногда у меня в занимающихся бывают очень способные, которые ищут первую работу без опыта. Иногда -- не в том смысле, что "иногда очень способные" -- у меня все очень способные :) , потому что достаточно строгий отбор на курсы, а в том смысле, что "иногда ищут работу". Как правило из регионов, поэтому ищут удалёнку, ну и понятно, что в такой ситуации "сразу на удалёнку без опыта" возникают определённые проблемы с поиском. Сведу вас бесплатно.
Пишите основные скиллы которые от кандидата хотите (напомню, речь только про "на удалёнку без опыта"), и обязательно вилка зарплат под них (никаких "по договорённости", "надо сперва с человеком поговорить" ...). Без конкретных цифр зарплат сразу в бан :)
Микро-хак первых курсов хорошего университетского образования: что важно хорошо понимать любому программисту, уважающему себя и свой коллектив. Осваивать это надо именно в нижеприведённом порядке.
1. Ясный код.
2. Вычислительное мышление.
Это пока были хипстерские шаги, а вот далее начинается секретная кроличья нора :)
3. Чистое функциональное программирование.
4. Транспиляция (эквивалентные преобразования исходных текстов программ на разных языках) -- запилить свой транспайлер.
5. Гомоиконичность (изоморфность синтаксиса и AST, код как сущность первого класса) -- попрактиковаться в Лиспе на сотне задачек с акцентом на "code as data".
6. Ссылочная прозрачность.
7. "Well typed programs cannot go wrong" Robin Milner 1978
8. Изоморфизм Карри-Ховарда.
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 септиллионов лет! Вот на что я готов ради вас, дорогие! )))
Для программистов наверное нагляднее будет йоттабайт (тысяча миллиардов терабайтов), хотя это не точно,
и СИ для септиллиона байтов (наибольшая кстати стандартная единица) рекомендует название йобибайт.
И это не так и много: флешка на йобибайт будет размером всего с египетскую пирамиду.
Технически, в каждом дне 900 тханг чит, в году их 328500.
В великой кальпе 4,32 миллиарда лет, да на тысячу,
получаем 1 419 120 000 000 000 000 тханг чит.
Берём это как дни, да на три неисчислимые кальпы, да на, допустим, 9 миллиардов раз,
и получаем округлённо в годах
100 000 000 000 000 000 000 000 000
100 септиллионов лет! Вот на что я готов ради вас, дорогие! )))
Для программистов наверное нагляднее будет йоттабайт (тысяча миллиардов терабайтов), хотя это не точно,
и СИ для септиллиона байтов (наибольшая кстати стандартная единица) рекомендует название йобибайт.
И это не так и много: флешка на йобибайт будет размером всего с египетскую пирамиду.
Удивительно, сколь много "специалистов" не понимают, что информационная безопасность -- это не напихивание в систему тучи защитных фич; это прежде всего удаление из проекта всех опасных мест.
Хотя конечно, когда проект исходно был спроектирован криво, он весь целиком одна сплошная опасность :) И надо всё переделывать с нуля.
Хотя конечно, когда проект исходно был спроектирован криво, он весь целиком одна сплошная опасность :) И надо всё переделывать с нуля.
Мы все часто слышим, что написанию хорошего кода (и качественной разработке в целом) можно научиться только опытным путём, методом проб и ошибок, через реальные проекты; или даже, возможно, хорошими программистами рождаются, а не становятся. И при этом мы постоянно читаем о принципах, которые лежат в основе хорошего кода: инкапсуляция, модульность, связность... Многие из них контринтуитивны, то есть были изобретены/открыты в академических кругах, мировыми специалистами в 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.
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.
GitHub
GitHub - mingrammer/diagrams: :art: Diagram as Code for prototyping cloud system architectures
:art: Diagram as Code for prototyping cloud system architectures - mingrammer/diagrams
Отличное выступление на 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-адрес (мой курс Ясный Код в помощь).
"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-адрес (мой курс Ясный Код в помощь).
YouTube
Raymond Hettinger - Beyond PEP 8 -- Best practices for beautiful intelligible code - PyCon 2015
"Speaker: Raymond Hettinger
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…
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…
Джуниоры нужны всё меньше?
"Storyboard Programming" разработана в Массачусетском технологическом институте нашими с вами друзьями. Автоматическая генерация кода, реализующего операции над различными структурами данных (чем мы на курсах по АСД занимаемся вручную) на основании картинок, которые программист рисует мышкой "интуитивно" (квадратики и стрелочки) и добавляет примеры ввода-вывода.
Тут есть видео, как это происходит.
А брат этого товарища занимается разработкой фреймворка синтеза программ, который оптимизирует сам себя, и умеет генерировать formula simplifiers под конкретные предметные области.
В СильныхИдеях сделаю небольшой разбор этой темы, которая в наших прозаических целях очень важна прежде всего тем, что, как показано математически, даже сильно сложные функции (логику) в повседневном кодинге можно конструировать из очень небольшого числа строительных блоков, микро-паттернов (на курсах для начинающих, впрочем, делаю на этом особый акцент уже не один год).
"Storyboard Programming" разработана в Массачусетском технологическом институте нашими с вами друзьями. Автоматическая генерация кода, реализующего операции над различными структурами данных (чем мы на курсах по АСД занимаемся вручную) на основании картинок, которые программист рисует мышкой "интуитивно" (квадратики и стрелочки) и добавляет примеры ввода-вывода.
Тут есть видео, как это происходит.
А брат этого товарища занимается разработкой фреймворка синтеза программ, который оптимизирует сам себя, и умеет генерировать formula simplifiers под конкретные предметные области.
В СильныхИдеях сделаю небольшой разбор этой темы, которая в наших прозаических целях очень важна прежде всего тем, что, как показано математически, даже сильно сложные функции (логику) в повседневном кодинге можно конструировать из очень небольшого числа строительных блоков, микро-паттернов (на курсах для начинающих, впрочем, делаю на этом особый акцент уже не один год).
Доктор философии скрестил ежа с ужом Питон с Лиспом. Получилось очень забавно.
Фишка из web3 — как организовывать журналирование без, например, SS-таблиц или LSM-деревьев, когда ноды могут покидать сеть и возвращаться в неё произвольно по своему усмотрению: брать цепочку proof-of-work в качестве целостной и доказанно корректной информации о том, что произошло, пока узла не было в онлайне.
...то странное чувство, когда как обычно внезапно закончились минуты на каршеринг GitLab CI/CD, а оплата долларами теперь традиционно сильно усложнена, и в результате вся система у знакомых пацанов встала почти намертво )))
Остаётся импортозамещённый cicd яндекс, причём они даже вроде с GitLab как-то совместимы, хотя там честно говорится, что "Пайплайн CI/CD сложно применять для больших и сложных монолитных систем". Так CI/CD как раз и нужны именно для таких систем в первую очередь )
Маленькие и несложные монолиты полезно как раз вручную обслуживать.
Остаётся импортозамещённый cicd яндекс, причём они даже вроде с GitLab как-то совместимы, хотя там честно говорится, что "Пайплайн CI/CD сложно применять для больших и сложных монолитных систем". Так CI/CD как раз и нужны именно для таких систем в первую очередь )
Маленькие и несложные монолиты полезно как раз вручную обслуживать.
Многострадальный Python превратили ещё и в функциональный язык.
coconut-lang.org
Coconut Programming Language
Simple, elegant, Pythonic functional programming.