Давайте попробуем запустить рубрику "S0ER комментирует новости", под этой записью накидайте новостей по Айти и программированию, на которые вам интересно узнать мое мнение. Выберу самые интересные и расскажу все что думаю.
Проектирование - простая штука, нужно раз за разом, последовательно выполнять всего пять шагов. Накидал памятку "юному" архитектору. Попытайтесь следовать этим шагам, не пропуская и не перепрыгивая со словами "это очевидно".
Раньше я думал, что плохих книг не бывает, что в каждой книге есть что-то полезное. Я так думал ровно до тех пор, пока не встретил «Agile in practice».
Чтобы вы ни думали о связи названия и содержания книги - вы ошибетесь. Автор подробнейшие образом (со скриншотами и пересказывание документации) рассказывает как использовать софт по управлению проектами (наподобие, Jira), тратит на это кучу времени и страниц книги. Но на действительно полезные вещи, поясняющие смысл Agile, фреймворков и оценки качества продуктов, как будто не хватило сил.
В итоге, скомканное описание теории, без примеров и нормальных аргументов, куча скриншотов и пересказа документации.
Такое ощущение, что посмотрел скринкаст по Jira, разложенный на кадры и опубликованный в книге.
Пирамида изучения показывает какие методы передачи информации лучше для восприятия и усваивания материала. Мне это нужно для моего проекта soer.pro, хочу с уровня "Аудиовизуальный контент" уйти на практику и обучение других. Пока на стадии обдумывания.
От программистов часто ожидают не только надёжного, но и безопасного поведения программы. В свое время на меня очень сильное впечатление произвели алгоритмы генерации псевдослучайных чисел. С позиции безопасности важно понимать разницу между криптографисеским и простым рандомом. Начать можно вот с этой статьи - https://habr.com/ru/post/595905/
Есть любимая игра среди программистов, называется "так писать нельзя". Кто лучше объяснит почему нельзя, тот и победил. Потом смотришь реальные проекты, а там как только не написано и проект работает, приносит деньги - бизнес работает. И я с одной стороны поддерживаю, что есть "плохой" и "хороший" код, а с другой формально посчитать сколько денег компания выиграет на "хорошем" коде, не могу. Как правило бизнес работает в терминах "рабочий" и "нерабочий" код. И это существенно проще, хотя любой код всегда лишь "частично" рабочий (баги есть всегда).
Чтобы не быть голосовным. Читаю темы подлоки на 15 августа. Темы: - как правильно организовать процесс сборки с Андрюшей Ситником - как автоматизировать написание документации - как использовать тулзы по анализу графа зависимостей
А чего не "как научиться читать и писать по букварю"? ))))
Конференции должны решать какие-то существенные проблемы или показывать достижения. Представьте конфу по робототехнике где вам расскажут "как правильно подключать шаговый двигатель" или "какой паяльник выбрать".
Тот же Ситник мог бы, наверное, что поинтереснее задвинуть. Может про алгоритмы генерации криптографисески важных случайных последовательностях для геннрации uuidов, куда интереснее и полезнее, правда и аудитория нужна более зрелая
Вчера немного поругал фронтенд, хотя и не поругал на самом-то деле, а сказал правду. Не моя же вина, что паблики про фронтенд на 99% забиты всякой чушью. Я ради интереса сейчас пробежался по паре топовых телеграм-пабликов про фронтенд и ужаснулся тому что все гораздо хуже, чем мне казалось.
Я понимаю, что каналы идут за интересами своих подписчиков - какие интересы, такие и каналы. Именно поэтому, я решил не гнаться за подписчиками, а говорить правду как есть.
S0 
