Smalltalk *

Кажется, что слово «революция» применительно к искусственному интеллекту используют слишком легко. Каждый новый продукт теперь «революционный», каждая новая модель «меняет всё», а через полгода выходит следующая.

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

Я считаю, что революция искусственного интеллекта уже началась.

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

Революция — это процесс. И процесс уже идёт.

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

Именно так происходило раньше.

Программисты пишут свои вики в obsidian, в org файлах и других инструментах. С ними готовятся к собеседованию, ищут команды для баша, хранят информацию про их сервер и много чего еще.

Почему бы не использовать такой подход для кода, а не только для текста? У меня хранится куча вспомогательных скриптов, я пробую новые библиотеки и часто начинаю новые пет-проекты. Даже если проект никогда не зарелизится, все может остаться в такой “вики”, и потом это можно переиспользовать.

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

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

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

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

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

Ответьте себе на вопрос: где проходит ваша граница доверия с вашим агентом? Что вы готовы ему простить? А что для вас жесткий ред-флаг?

Готовы ли вы делегировать агенту задачу, в которой вы не разбираетесь, и взять за это ответственность, если что-то пойдет не так? А если наоборот, все будет очень хорошо — искренне признать, что по факту это не совсем ваш труд?

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

У меня есть несколько смешных кейсов, которые я вам сейчас расскажу, но смеяться вы скорее всего не будете.

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

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

В октябре 1998 года, разочарованный упрощенным пониманием ООП, Алан Кей написал сообществу Squeak знаковое письмо. В нем он напомнил, что главная идея Smalltalk, о которой все забыли, — это не классы, а отправка сообщений. Это письмо стало манифестом, отделяющим оригинальную философию объектов от ее популярной интерпретации. Публикуем перевод этого короткого, но исторически важного документа.

Привет, Хабр.

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

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

Мостик между этими двумя мирами — автотесты, они нужны и тестированию, и разработке. Фреймворк JUnit сознательно писали как можно более простым — в первую очередь для того, чтобы сделать его повседневным инструментом для разработчиков. Люди, работавшие с первыми фреймворками автотестирования, стали также авторами подходов экстремального программирования (XP) и разработки через тестирование (TDD) — т. е. подходов, настаивающих на том, что тестирование — это не «обязаловка», а неотъемлемая часть разработки.

С учётом этого, я решил заняться «археологией» автотестирования: посмотреть на прародителя современных фреймворков xUnit, SUnit для Smalltalk. Я хотел потрогать его руками, а также понять, что двигало его автором. В результате получилось довольно интересное путешествие, которым я хотел бы с вами поделиться.

Вначале я посмотрю на то, что из себя представляло автоматизированное тестирование в 1990-е. Чтобы понять, что добавил SUnit, попробую запустить на нём несколько примитивных тестов. А потом посмотрю, что можно наскрести по сусекам интернета о мотивации создателей и пользователей. Как они пришли к тому, что барьер между разработкой и тестированием надо преодолеть? Сам я не был участником этого процесса (годами не вышел), так что придётся опираться на вторичные источники.

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

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

Бывают моменты, когда сидишь в чате и вдруг осознаёшь: ты стал молчаливее. У тебя вроде бы есть слова — но они прячутся где-то под слоями «ок», «норм» и эмодзи.

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

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

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

Самым сложным в этой статье было выбрать понятное и не душное название. С этим я не справился.

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

Суровый 2022ой неслабо перетряхнул бизнес в России, и ощутимо расшевелил всю сферу IT и ИБ. В то время, как исконно российские безопасники штудируют новую доктрину ИБ, переводят новые законы с бюрократического на общечеловеческий язык и метят в ТОП менеджмент, менеджеры ИБ международных компаний открыли для себя множество иных вопросов, единого ответа на которые пока что нет.

Спойлер: все описанное ниже является моим субъективным мнением, при описании которого я опирался на свой скромный опыт, и опыт 2-3 моих знакомых. Текст не претендует на объективное описание сферы ИБ, посему рекомендую воспринимать текст с иронией.

Личное наблюдение: в Российских компаниях чаще звучит термин «защита информации» - как бесконечный процесс, а сами безопасники являются Администраторами безопасности, в то время как в международных как правило формулируют «безопасность информации» как недостижимый результат, а специалистов гордо именуют Менеджерами ИБ.

Наступают длинные зимние каникулы. Во многих IT-компаниях уже объявлен режим freeze - заморозка новых активностей до конца праздников. Особенно длительной будет пауза у тех, кто сотрудничает с европейскими партнерами - они уходят на каникулы уже в 20х числах декабря, а российские офисы откроются после праздников лишь 3 недели спустя.

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

• Аннотация и Введение

I. 1960–66 — Становление ООП и другие новые идеи 60-х

The Early History Of Smalltalk

Аннотация

Источник

Ральф Джонсон, один из членов "Банды четырёх", однажды показал, как синтаксис языка Smalltalk-80 можно уместить на почтовой открытке. Сейчас, спустя почти 30 лет после появления первой версии Smalltalk, самым быстроразвивающимся диалектом Smalltalk является Pharo, почтовую открытку которого далее и разберём.

Друзья, добрый день.

Давно не писал, и тут подписался на рассылку компании Абвгд. Красивые письма пишут мОлодцы :) Уговаривают вложиться в ПАММ счета. Что это такое не знаю. Зато понятно, как эти данные анализировать.

Терминология – есть ПАММ-счет и у него есть управляющий. Буду использовать термин «ПАММ-счет» и «управляющий» — здесь это синонимы.

По теме хотелось сделать визуализацию в инструменте Tableau Public. Статьи об этом «в доступной для меня форме» не нашел. Она ниже.

План атаки:

1. Формулируем задачу,
2. Собираем данные,
3. Причёсываем,
4. Делаем несколько графиков,
5. Сводим на один дашборд,
6. Выкладываем на https://public.tableau.com
7. Формулируем резюме. Профит.

Задача

Работаю на работе работу. Получаю зарплату, аванс там или ещё что-то. Пусть деньги приходят еженедельно в ночь с воскресенья на понедельник. Хочу вложиться в высокодоходные активы, например в ПАММ счет. И вкладываться еженедельно понемногу.

Надо понимать, когда и куда вкладываться. Доходность нужна высокая, просадки должны быть минимальными.

1. Онтологическое наследование указывает на специализацию: вот эта штука — специфическая разновидность той штуки (футбольный мяч — это сфера и у неё такой-то радиус).
2. Наследование абстрактного типа данных указывает на замещение: у этой штуки такие же свойства, как у той штуки, и такое-то поведение (это принцип подстановки Барбары Лисков).
3. Наследование реализации связано с совместным использованием кода: эта штука принимает некоторые свойства той штуки и переопределяет или дополняет их таким-то образом. Наследование в моей статье «О наследовании» именно такого и только такого типа.