Как компьютер хранит звук

Если хранить текст, изображения и даже мысли (в виде того же текста) человек научился давно, то со звуком долгое время были проблемы. В 19 веке Томас Эдисон изобрел фонограф — первое устройство для записи и воспроизведения звука. Записывало оно с помощью фиксации вибраций от звуковой волны сначала на фольге, а затем на воске.

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

#видео

Программирование — не только код, но и мышление: разбираемся с парадигмами

Почему одни программисты «думают» циклами и условиями, а другие — через потоки данных и события? Всё дело в парадигмах. Это не модные тренды, а способы мыслить, проектировать и писать код.

Если вы хотите лучше понимать, почему айтишники спорят о «функциональном» и «объектно-ориентированном» — эта статья объяснит простыми словами:
— что такое парадигма программирования и зачем она нужна;
— какие бывают подходы к написанию кода и в чём их отличия;
— как выбор парадигмы влияет на архитектуру, поддержку и масштабируемость проекта.

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

#программирование #парадигмы #мышление

Вы следуете каким-нибудь принципам программирования? SOSAL?

Именно так теперь вы можете начать беседу с айтишником. SOSAL — это принципы программирования, которые предлагают альтернативный подход в сравнении с SOLID, DRY, KISS и другими.

Подход состоит из пяти принципом:

— Socially-Conscious Code (Социально-осознанный код)
— Open by Default (Открытость по умолчанию)
— Simple Scalability (Сбалансированная/простая масштабируемость)
— Agile Adaptivity (Адаптивность выше догм)
— Learning-Driven Logic (Логика, основанная на обучении)

Подробнее о каждом принципе и преимуществах подхода можно узнать в статье. И хотя подход скорее мемный, здравое зерно в нём есть.

У кого такое было ставит ❤️

​Как родился первый язык программирования

Вы когда-нибудь задумывались, как программисты писали код в 1950-х годах? Это была кропотливая работа с машинными кодами на перфокартах.

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

#статья #история

Когда IT-вечеринка стала вирусной — и пришла полиция

Что получится, если IT-шутка выйдет из-под контроля? В Берлине решили проверить. Компания Cluely, которая делает обучающие игры и квизы по IT, решила отметить релиз новой фичи… шумно. Анонсировали вечеринку в стиле Project X — с алкоголем, танцами, диджеями и даже бесплатным баром для тех, кто принесёт собственный баг-репорт.

Ожидали 300 человек. Пришло больше 2000. А закончилось всё полицией. Подробности у нас на сайте.

#новости

Справедливо ли это?

ИИ должен помогать, а не мешать: почему техлиды разочарованы

Кажется, что AI-инструменты — это сплошной буст для команд: код подскажет, баги найдёт, документацию напишет. Но на деле всё сложнее.

Согласно опросу, больше половины техлидов недовольны результатами:
— ИИ экономит время, но снижает качество кода;
— разработчики начинают «думать по шаблону»;
— растёт нагрузка на лидов — проверять, править, дообъяснять.

Почему так получилось и как компании адаптируют подход к AI-инструментам — рассказали в статье. Материал пригодится, если вы работаете рядом с разработчиками или сами пробуете внедрять ИИ в процессы.

#ии #новости

Что почитать айтишникам?

Многие из нас черпают знания из профессиональных книг, но на то, чтобы прочитать их все у нас банально не хватает времени.

Нашли в канале ИТ Инсайты Артёма Харченкова годные обзоры и основные мысли из книг, которые он считает наиболее полезными для ИТ-специалистов и их руководителей.

🧏🏻‍♂️ Джедайские техники. Максим Дорофеев — must have для тех, кто работает в режиме многозадачности

🦢 Чёрный Лебедь. Нассим Талеб — чтобы понять, что в этом мире может пойти не так

🐈‍⬛ Как пасти котов. Дж. Хэнк Рейнуотер — классика по управлению командой разработки

🤝 Договориться можно обо всём. Гэвин Кеннеди и 👺 Переговоры с монстрами. Игорь Рызов — взаимодополняющие работы по ведению переговоров

🤡 Кругом одни идиоты. Томас Эриксон — про то, как навешать ярлыки классифицировать людей вокруг и как найти подход к разным типам личности

⚔️ Пять пороков команды. Патрик Ленсиони — для осознания того, как быть эффективной командой, а не группой индивидуалистов

👶🏻 Общаться с ребёнком. Как? Юлия Гиппенрейтер — ведь в общении с сотрудниками и с детьми много общего

💲Сколько стоит программный проект. Стив Макконелл — для тех, кто хочет научиться оценивать разработку и перестать срывать заявленные сроки

SQLZoo: интерактивный тренажёр по SQL

Если надоело читать теорию и хочется потрогать SQL ручками — SQLZoo станет идеальным выбором. Здесь сразу на сайте можно выполнять задания, строить запросы к реальным базам и видеть результат.

Есть пошаговые туториалы, задания на SELECT, JOIN, GROUP BY, подзапросы и задачки на логику.

Как выглядят подходы разные к программированию по мнению ИИ:

305 RAMAC — прародитель современных жестких дисков

Прародителем современных HDD стал 305 RAMAC от корпорации IBM. Название это расшифровывается как "Random Access Method of Accounting and Control" (Метод случайного доступа к учету и контролю).

305 RAMAC обладал колоссальными размерами, напоминающими промышленный рефрижератор, и весил почти одну тонну — точнее, 970 килограммов. Устройство представляло собой систему из 50 алюминиевых пластин, покрытых ферромагнетиком, каждая из которых имела диаметр 24 дюйма (61 сантиметр).

На тот момент это было настоящее технологическое чудо, несмотря на его внушительные габариты. 305 RAMAC прокладывал путь к современным жестким дискам, которые сегодня можно держать в руке.

#ibm #hdd #историяit

Перформеры в команде: кто тащит, а кто тормозит

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

🐢 Лоуперформеры (low performers)

Это сотрудники, чья работа систематически ниже ожиданий. Они не справляются с задачами, часто тормозят процессы, не успевают в дедлайны или делают некачественно. Это не обязательно лень — причин может быть много:
— не хватает навыков;
— не поняли задачу (или бизнес сам не смог нормально объяснить);
— плохая мотивация или выгорание;
— не подходит текущая роль.

🧑‍💼 Мидперформеры (middle performers)

Таких большинство. Работают стабильно, иногда делают больше, чем нужно, но не стремятся «брать на себя» или выходить за рамки. Командный «скелет»: без них всё развалится, но они — не звёзды.

🚀 Хайперформеры (high performers)

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

Что делать с лоуперформерами?

Важно не рубить с плеча. Сначала — разобраться:
— это проблема навыков, мотивации или условий?
— можно ли переобучить, переставить, поддержать?

Если да — даём шанс. Если нет и прогресса нет — лучше расстаться. Лоуперформеры — это не приговор, но игнорировать их — вредно для всей команды.

Об этом подробнее рассказал Никита Ульшин у себя в канале.

💬 А вы с кем работали чаще?

#softskillz #менеджмент