Вспомнив про MS-DOS, продолжаем изучать открытые проекты в формате викторины.
3D Slicer - это платформа для анализа и визуализации медицинских изображений (МРТ, КТ). Проекту больше 20 лет.
Ключевые особенности:
- позволяет работать с объёмными 3D-данными,
- кроссплатформенный,
- имеет инструменты научной визуализации,
- возможность для ученых (непрограммистов) писать свои алгоритмы.
Из этого описания попробуйте угадать, какой у него стек технологий 👇
3D Slicer - это платформа для анализа и визуализации медицинских изображений (МРТ, КТ). Проекту больше 20 лет.
Ключевые особенности:
- позволяет работать с объёмными 3D-данными,
- кроссплатформенный,
- имеет инструменты научной визуализации,
- возможность для ученых (непрограммистов) писать свои алгоритмы.
Из этого описания попробуйте угадать, какой у него стек технологий 👇
🤔4🔥2💩1
Какой стек технологий у проекта 3D Slicer?
Anonymous Quiz
53%
C++, Qt, VTK, Python
7%
C#, WPF, .NET, IronPython
20%
C++, MFC, Boost
20%
Java, Java3D, Swing
No functional changes
Помню, как анализировал баг на одном проекте, и пришлось тогда восстанавливать историю коммитов по git.
В процессе наткнулся на коммит с заголовком "No functional changes".
"В смысле?" - думаю. - "Как это нет функциональных изменений? Что тогда есть?"
Начал выяснять, что же это за изменения такие "никакие". Оказалось, что внутри были простые переименования переменных.
Ну тогда это и надо писать в заголовке! Никаких вопросов бы не возникло.
Дальше-больше. Такой коммит был не один. За полтора года человек наделал под сотню коммитов с точно таким же заголовком (см. скрин). А самое печальное то, что некоторые из них все таки содержали функциональные изменения...
Я искренне считаю, что история коммитов должна читаться как книга. Писать сообщения коммитов - это отдельная работа. Причем сложная, так как далеко не все мы заправские писатели. Но до абсурда вроде "No functional changes" уж точно нельзя доводить.
—
Дополнительно:
- Поиск бага с помощью истории git: метод деления пополам
- Стратегия с WIP-коммитами для больших правок
Помню, как анализировал баг на одном проекте, и пришлось тогда восстанавливать историю коммитов по git.
В процессе наткнулся на коммит с заголовком "No functional changes".
"В смысле?" - думаю. - "Как это нет функциональных изменений? Что тогда есть?"
Начал выяснять, что же это за изменения такие "никакие". Оказалось, что внутри были простые переименования переменных.
Ну тогда это и надо писать в заголовке! Никаких вопросов бы не возникло.
Дальше-больше. Такой коммит был не один. За полтора года человек наделал под сотню коммитов с точно таким же заголовком (см. скрин). А самое печальное то, что некоторые из них все таки содержали функциональные изменения...
Я искренне считаю, что история коммитов должна читаться как книга. Писать сообщения коммитов - это отдельная работа. Причем сложная, так как далеко не все мы заправские писатели. Но до абсурда вроде "No functional changes" уж точно нельзя доводить.
—
Дополнительно:
- Поиск бага с помощью истории git: метод деления пополам
- Стратегия с WIP-коммитами для больших правок
💯4🤔2🤯1🙏1
Выше дан код C++. Какой вывод будет у программы?
Anonymous Quiz
13%
hello
47%
h
33%
Никакой. Ошибка компиляции
7%
Никакой. Ошибка выполнения
This media is not supported in your browser
VIEW IN TELEGRAM
Макет пользовательского интерфейса в
Недавно был пост про создание макетов пользовательских интерфейсов в гугл-таблицах. И если идея с табличными макетами выглядела здраво, то использование для этого гугл-таблиц звучало странно.
Только позже я вспомнил, что в
Как это делать, смотрите на видео. Ссылки внизу.
Макеты бывают полезны не только при проектировании, но и постфактум при создании отчетов. Для студенческих работ подойдет как нельзя кстати. Берите на вооружение.
📱 Смотреть на YouTube
📱 Смотреть в VKVideo
diagrams.netНедавно был пост про создание макетов пользовательских интерфейсов в гугл-таблицах. И если идея с табличными макетами выглядела здраво, то использование для этого гугл-таблиц звучало странно.
Только позже я вспомнил, что в
diagrams.net тоже можно работать с таблицами. По крайней мере собрать макет труда не составит.Как это делать, смотрите на видео. Ссылки внизу.
Макеты бывают полезны не только при проектировании, но и постфактум при создании отчетов. Для студенческих работ подойдет как нельзя кстати. Берите на вооружение.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🙏2
Airtable идентифицировал мой аккаунт как связанный с Россией и собирается его отключить.
Я не мог позволить им такую наглость и удалился оттуда до блокировки)
Но интересно другое.
Там есть страшная красная кнопка, которая удаляет аккаунт В ОДИН КЛИК.
Раз, и прощайте. Никаких тебе подтверждалок "да - нет" или отмены. Случайно нажал и улетел на домашнюю)
Мода такая что ли в интерфейсах, удалять, не спрашивая?
—
Кто не знает, Airtable - это тулза, которой я пользовался до Notion, которым я пользовался до Obsidian
Я не мог позволить им такую наглость и удалился оттуда до блокировки)
Но интересно другое.
Там есть страшная красная кнопка, которая удаляет аккаунт В ОДИН КЛИК.
Раз, и прощайте. Никаких тебе подтверждалок "да - нет" или отмены. Случайно нажал и улетел на домашнюю)
Мода такая что ли в интерфейсах, удалять, не спрашивая?
—
Кто не знает, Airtable - это тулза, которой я пользовался до Notion, которым я пользовался до Obsidian
😁2🤯2🤬2
В 80-х годах Ричард Столлман дал определение свободному программному обеспечению и выделил четыре свободы.
Свобода 0: Свобода запускать программу в любых целях.
Свобода 1: Свобода изучения работы программы и адаптация её к вашим нуждам.
Свобода 2: Свобода распространять копии.
Свобода 3: ... 👇
Свобода 0: Свобода запускать программу в любых целях.
Свобода 1: Свобода изучения работы программы и адаптация её к вашим нуждам.
Свобода 2: Свобода распространять копии.
Свобода 3: ... 👇
Как звучала "Свобода 3" по Столлману?
Anonymous Quiz
72%
Свобода улучшать программу и публиковать свои улучшения
12%
Свобода коммерчески использовать программу
4%
Свобода продавать копии и улучшения
12%
Свобода управлять данными, обрабатываемыми программой
Прозаседавшиеся
Ещё 100 лет назад Маяковский смеялся над любителями заседать.
Его герои разрывались пополам, лишь бы успеть на все заседания. В прямом смысле слова:
Но для секретаря все выглядит привычно:
Больше века прошло, а концепция все та же. Только теперь мы называем это созвоном)
—
Заседаете?
😁 - Ага, разрываюсь
👍 - Бывает, без фанатизма
🔥 - Неа
Ещё 100 лет назад Маяковский смеялся над любителями заседать.
Его герои разрывались пополам, лишь бы успеть на все заседания. В прямом смысле слова:
И вижу:
сидят людей половины.
О дьявольщина!
Где же половина другая?
Но для секретаря все выглядит привычно:
Они на двух заседаниях сразу.
В день
заседаний на двадцать
надо поспеть нам.
Поневоле приходится раздвояться.
До пояса здесь,
а остальное
там.
Больше века прошло, а концепция все та же. Только теперь мы называем это созвоном)
—
Заседаете?
😁 - Ага, разрываюсь
👍 - Бывает, без фанатизма
🔥 - Неа
😁6👍4🔥3
Какой паттерн используют, когда кучу параметров метода собирают в один объект?
Anonymous Quiz
15%
Template method
30%
Data transfer object
19%
Singleton
37%
Context object
Скепсис по ИИ: поговорим через 10 лет
Смотрю итоги и прогнозы в журнале "САПР и Графика". В отличие от прошлого года акценты сместились в сторону ИИ-инструментов.
Мнения компаний разделились: от скептицизма до оптимизма.
С оптимистами и так все ясно, куда интереснее мнение скептиков. Согласно нему ИИ - это перегретый тренд, пузырь, искусственный опыт, а его внедрение возможно "минимум через 10 лет".
Загибайте пальцы:
- проблемы Oracle,
- убыточность крупнейших ИИ-стартапов,
- финансовые потери OpenAI,
- отсутствие прибыли от внедрения ИИ,
- снижение рыночной доли ChatGPT.
Так еще и обучаются ИИ-шки не на энциклопедиях, а на постах с Реддита!
А слышали недавнюю историю о затонувшей западной подводной лодке? Подлодка успешно прошла ходовые испытания, но не всплыла после первого погружения:
Честно говоря, первоисточников я не нашел. Но, допустим.
Все это стоит аргументом к тому, что нам не надо торопиться с внедрением ИИ еще лет десять.
В то же время Китай и США наращивают ИИ-шные инвестиции. Системы будут развиваться. И есть мнение, что "на горизонте 3 - 5 лет разрыв может стать непреодолимым".
Дух неопределенности вокруг внедрения ИИ можно понять. Есть технологии, которые приходили и уходили. Вспомним 3D телевизоры и VR. Но даже эти технологии не исчезли, а только лишь спрыгнули с волны хайпа и устаканились в своих нишах.
На своей заре САПР тоже встречали с сопротивлением. Почти полвека назад первые САПР произвели революцию: теперь за день можно было сделать то, что раньше занимало месяцы. Скептики, видя угрозу своему профессиональному статусу, говорили, что молодые инженеры превращаются в простых операторов, программы становятся "черным ящиком", инженеры не обладают экспертизой разработчиков...
Тогда САПР ломали устои, а сегодня позволяют создавать сложнейшие продукты инженерной мысли. Продукты, недостижимые в прошлом.
Поэтому даже если не внедрять ИИ сейчас, по отношению к нему нужна стратегия. Устойчивость гарантирует наличие уникального, трудно воспроизводимого ингредиента. Для большинства случаев использования ИИ таким ингредиентом будут данные.
Упаковывать и структурировать данные и экспертизу можно уже сейчас. Не важно, есть ИИ-пузырь в действительности или нет. Но почему и, главное, чего нам нужно ждать еще 10 лет, мне не понятно.
—
Читать еще:
- Что такое САПР
- Как разрабатывать САПР на C++
Смотрю итоги и прогнозы в журнале "САПР и Графика". В отличие от прошлого года акценты сместились в сторону ИИ-инструментов.
Мнения компаний разделились: от скептицизма до оптимизма.
С оптимистами и так все ясно, куда интереснее мнение скептиков. Согласно нему ИИ - это перегретый тренд, пузырь, искусственный опыт, а его внедрение возможно "минимум через 10 лет".
Загибайте пальцы:
- проблемы Oracle,
- убыточность крупнейших ИИ-стартапов,
- финансовые потери OpenAI,
- отсутствие прибыли от внедрения ИИ,
- снижение рыночной доли ChatGPT.
Так еще и обучаются ИИ-шки не на энциклопедиях, а на постах с Реддита!
А слышали недавнюю историю о затонувшей западной подводной лодке? Подлодка успешно прошла ходовые испытания, но не всплыла после первого погружения:
Оказалось, что при проектировании расчеты поручили ИИ, который и посчитал всё, но без учета сотых после запятой… И никто из специалистов не проверил…
Честно говоря, первоисточников я не нашел. Но, допустим.
Все это стоит аргументом к тому, что нам не надо торопиться с внедрением ИИ еще лет десять.
В то же время Китай и США наращивают ИИ-шные инвестиции. Системы будут развиваться. И есть мнение, что "на горизонте 3 - 5 лет разрыв может стать непреодолимым".
Дух неопределенности вокруг внедрения ИИ можно понять. Есть технологии, которые приходили и уходили. Вспомним 3D телевизоры и VR. Но даже эти технологии не исчезли, а только лишь спрыгнули с волны хайпа и устаканились в своих нишах.
На своей заре САПР тоже встречали с сопротивлением. Почти полвека назад первые САПР произвели революцию: теперь за день можно было сделать то, что раньше занимало месяцы. Скептики, видя угрозу своему профессиональному статусу, говорили, что молодые инженеры превращаются в простых операторов, программы становятся "черным ящиком", инженеры не обладают экспертизой разработчиков...
Тогда САПР ломали устои, а сегодня позволяют создавать сложнейшие продукты инженерной мысли. Продукты, недостижимые в прошлом.
Поэтому даже если не внедрять ИИ сейчас, по отношению к нему нужна стратегия. Устойчивость гарантирует наличие уникального, трудно воспроизводимого ингредиента. Для большинства случаев использования ИИ таким ингредиентом будут данные.
Упаковывать и структурировать данные и экспертизу можно уже сейчас. Не важно, есть ИИ-пузырь в действительности или нет. Но почему и, главное, чего нам нужно ждать еще 10 лет, мне не понятно.
—
Читать еще:
- Что такое САПР
- Как разрабатывать САПР на C++
👍2🤔2
#include <iostream>
class MyClass {
private:
int secret = 42;
};
int main() {
MyClass obj;
int* ptr = (int*)&obj;
std::cout << *ptr;
return 0;
}
Выше дан код C++. Какой вывод будет у программы?
Anonymous Quiz
14%
0
50%
42
18%
"Мусорный" вывод
18%
Никакой. Ошибка компиляции
👍1
Ошибка компиляции или ошибка времени выполнения
Ошибка компиляции - это ошибка, которая возникает в процессе компиляции программы, когда компилятор не может преобразовать исходный код в машинный из-за нарушений синтаксиса или семантики.
Ошибка времени выполнения - это ошибка, которая возникает во время выполнения программы, после успешной компиляции.
Да, в успешно скомпилированной программе все равно могут быть ошибки!
Хотя нет, лучше так:
Да, в успешно скомпилированной программе все равно есть ошибки!
Как-то студент в ответ на мое: "Тут ошибка", сказал: "Не может быть, все скомпилилось". Пошутил, наверное... и невольно запустил монолог про зверинец ошибок времени выполнения. Защита лабораторной была полезной как никогда)
—
Читать еще:
- Синтаксис или семантика
- Исключение или код ошибки
#Словарь
Ошибка компиляции - это ошибка, которая возникает в процессе компиляции программы, когда компилятор не может преобразовать исходный код в машинный из-за нарушений синтаксиса или семантики.
Ошибка времени выполнения - это ошибка, которая возникает во время выполнения программы, после успешной компиляции.
Да, в успешно скомпилированной программе все равно могут быть ошибки!
Хотя нет, лучше так:
Да, в успешно скомпилированной программе все равно есть ошибки!
Как-то студент в ответ на мое: "Тут ошибка", сказал: "Не может быть, все скомпилилось". Пошутил, наверное... и невольно запустил монолог про зверинец ошибок времени выполнения. Защита лабораторной была полезной как никогда)
—
Читать еще:
- Синтаксис или семантика
- Исключение или код ошибки
#Словарь
👍3😁1
Нетипичная пятничная задачка. Вспомним математику)
Есть круглая мишень, вписанная в квадратный лист (касается сторон). Стрелок расстреливает мишень, укладывая пули случайно по закону равномерного распределения. Как будет соотносится количество попаданий в круг к общему числу попаданий в квадратный лист мишени?
👇
Есть круглая мишень, вписанная в квадратный лист (касается сторон). Стрелок расстреливает мишень, укладывая пули случайно по закону равномерного распределения. Как будет соотносится количество попаданий в круг к общему числу попаданий в квадратный лист мишени?
👇
🤔2🤯2
Как будет соотносится количество попаданий в круг мишени к общему числу попаданий в квадратный лист?
Anonymous Quiz
20%
π
80%
π / 4
0%
Неизвестно
0%
1
Дипломы пишутся с ИИ
На днях закончил курс от Яндекса на тему применения ИИ при подготовке дипломов. Приятно осознавать, что делаются попытки "обелить" использование инструмента.
Ранее с появлением ИИ встал вопрос эффективности практических заданий по программированию. ИИ легко выполняет большую часть из них. Задания рассчитаны на постепенное вкатывание. Они не сложные для выполнения и имеют хорошие формулировки. А это по сути - готовые промпты.
Запретить студентам использовать ИИ невозможно. И не нужно. Все равно работодатели все чаще требуют владеть этими инструментами. При этом никто не делает скидку на остальные профессиональные компетенции. Нужно уметь делать то же, что и раньше, плюс ИИ.
Поэтому предлагается завести использование ИИ в зону контроля знаний. Если та или иная учебная работа выполняется с помощью ИИ, то промпты, результаты генерации и их интерпретация становятся объектом проверки. Как структурирован промпт, как поставлена задача, какой контекст занесен, какие ограничения выставлены, как уточнен и обработан результат - все подлежит оценке. Ведь даже с плохим промптом задание может быть выполнено правильно, если модель "сгаллюционирует" в нужную сторону.
То же самое с выпускными дипломными работами. В тексте работ появляется раздел с описанием кейсов применения ИИ: для чего применялся, как выглядели промпты, как интерпретировались и проверялись результаты. Прозрачность в этом вопросе позволит избежать снижения качества работ, а также поддержит отработку навыков работы с ИИ у выпускников.
В общем, интересно участвовать в новых процессах) Тема набирает обороты, ИИ развивается и пока не понятно, где границы возможностей этих систем. Но этих возможностей становится определенно больше. Задача - их не прозевать.
На днях закончил курс от Яндекса на тему применения ИИ при подготовке дипломов. Приятно осознавать, что делаются попытки "обелить" использование инструмента.
Ранее с появлением ИИ встал вопрос эффективности практических заданий по программированию. ИИ легко выполняет большую часть из них. Задания рассчитаны на постепенное вкатывание. Они не сложные для выполнения и имеют хорошие формулировки. А это по сути - готовые промпты.
Запретить студентам использовать ИИ невозможно. И не нужно. Все равно работодатели все чаще требуют владеть этими инструментами. При этом никто не делает скидку на остальные профессиональные компетенции. Нужно уметь делать то же, что и раньше, плюс ИИ.
Поэтому предлагается завести использование ИИ в зону контроля знаний. Если та или иная учебная работа выполняется с помощью ИИ, то промпты, результаты генерации и их интерпретация становятся объектом проверки. Как структурирован промпт, как поставлена задача, какой контекст занесен, какие ограничения выставлены, как уточнен и обработан результат - все подлежит оценке. Ведь даже с плохим промптом задание может быть выполнено правильно, если модель "сгаллюционирует" в нужную сторону.
То же самое с выпускными дипломными работами. В тексте работ появляется раздел с описанием кейсов применения ИИ: для чего применялся, как выглядели промпты, как интерпретировались и проверялись результаты. Прозрачность в этом вопросе позволит избежать снижения качества работ, а также поддержит отработку навыков работы с ИИ у выпускников.
В общем, интересно участвовать в новых процессах) Тема набирает обороты, ИИ развивается и пока не понятно, где границы возможностей этих систем. Но этих возможностей становится определенно больше. Задача - их не прозевать.
👍7🤔2
import hashlib
def get_md5_hash(str):
return hashlib.md5(str.encode()).hexdigest()
s1 = input()
s2 = input()
if s1 != s2:
h1 = get_md5_hash(s1)
h2 = get_md5_hash(s2)
if h1 == h2:
print(1)
else:
print(0)
Сегодня у нас python. Давайте подумаем над выводом программы 👇
Подсказка, если не знакомы с python:
👍2