S0ER – Telegram
10.6K subscribers
333 photos
18 videos
15 files
707 links
Архитектура | Программирование | Профессиональное развитие

Соер.Клуб - https://news.1rj.ru/str/soer_live

По всем вопросам писать на @soerdev
Download Telegram
За последнюю неделю смотрел два канала на ютубе, которые запомнились. Первый - это "Пьяная муха", не буду ссылку давать, канал специфичиский для тех кто любит ассемблер и старые компы.

А вот второй, пожалуй, порекомендую - https://www.youtube.com/user/MrAnetto на канале пока три видоса и 49 подписчиков, но выглядит многообещающим. Формат стримов на айтишные темы, последний был по Python. Чекните, вероятно будет интересно.
👍18🔥5🙏1
Псевдокод - это смесь естественного языка и кода на каком либо языке программирования или смеси языков. Штука весьма недооцененная.

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

Проектирование
Кодирование
Проверка
Рефакторинг
Повторение с первого шага

Вроде все как обычно, но “изюминка” в том, что первоначально вы “накидываете” логику работу метода с помощью псевдокода в комментариях.

При этом псевдокод может быть очень свободным, отражая общие идеи, а не конкретные решения. Например:

// Этот метод находит наибольшую общую подстроку, на вход мы получаем две строки, 
// в которых ищем общую часть

// дефолтным состоянием считаем “пустую строку”

// метод не доверяет данным, поэтому делаем проверку
// а) на вход могут прийти не строки
// б) одна из строк может быть пустой
// если проверка не прошла, то мы возвращаем “пустую строку”

// для решения используем алгоритм - https://ru.wikipedia.org/wiki/Наибольшая_общая_подстрока


далее общее описание конкретизируется и заменяется на реальный код.

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

Конечно, для простых методов нет необходимости так заморачиваться, а вот для серьезной бизнес-логики, вполне годный метод.
👍68🔥27😱1
Пытливые умы заметили, что кроме того, что линейный конгруэнтный метод не подходит для шифрования, так я еще неправильно дал значение констант, которые приводят к зацикливанию в большинстве случаев после 11 чисел.
Константы 45, 21 используются с модулем m = 127, в остальных случаях нужно проверять последовательность. Там хитрая игра "битов", ее надо просчитывать.

Из-за моей ошибки коллизии были не только для одного значения "seed". ))))

Сути это, конечно, не меняет - слабый генератор ключа делает шифр абсолютно незащищенным.
👍121
👍37😁22👏3
😁73👍13💯8🥰1
👍68😁24🤡8
😁60👎5👍3🤯1
Поставил Vim плагин на VSCode под MacOS и Linux, на маке еще функцию Esc повесил на капслок.

Итог такой: на маке пользоваться удобно, так как там есть Command+<key> для всех быстрых операций, в первую очередь копипаст. На Linux идет наложение Ctrl+<key> и блокируются шорткарты к которым привык. Даже не всегда понимаешь что происходит, так как по привычке нажимаешь комбинацию клавиш, а результат - переход в непонятный режим.
Кстати, CapsLock в качестве escape - это очень удобно, но вот на Linux надо искать как перенастроить, на маке очень быстро выработалась привычка использовать, а на Linux каждый раз "WTF?".

Вывод такой: vim-плагин удобная штука, но на Linux надо тюнить (запрещать Ctrl+<key> в vim-плагине, подстраивать клавиши под себя). На маке гораздо удачнее интеграция проходит, почти незаметно.
👍18👎4
Открыл для общего гостевого доступа первый архитектурный стрим.

https://platform.soer.pro/#!/pages/streams?fid=0
👍47🔥8
Помню когда начинал работать с Linux, после винды казалось, что файловая система какая-то очень перемудренная, теперь же думаю, что все просто, локанично и главное на своем месте.

Знаю, что далеко не все знают, чем, например, отличается /mnt от /media, или /opt от /usr/local. Для всех кто хоть раз задумывался о том как содержать файловую систему своего линукса в нормальном состоянии, рекомендую посмотреть какие директории для чего должны использоваться. Да и для общего развития полезно.

https://unlix.ru/для-чего-нужна-каждая-директория-в-linux/
👍68🔥101
Поговорим про ошибки. Как известно, не ошибается только тот, кто ничего не делает. Все остальные ошибаются и очень часто. Более того, ошибаться - это нормально, и сильно переживать об этом не стоит. Но, как всегда, есть нюансы.
Ошибки бывают разные, я с ходу могу выделить следующие группы:
- ошибки проектирования - это когда хотели как лучше, а получилось как всегда. Например, заложили недостаточное количество ресурсов, и сервис лег под нагрузкой. Или неправильно поняли заказчика, или еще что-то подобное.
- ошибки конфигурирования - это ошибки, которые приводят либо к накопительным проблемам (деградация уровня сервиса со временем), либо к критическим ошибками при разворачивании системы. Бывает и в процессе эксплуатации, но намного реже.
- ошибки интеграции - это когда по отдельности все работает, а вместе - нет. Обычно говорят "ошибки на швах", под швом имеется в виду точка интеграции двух сервисов
- технические ошибки - это ошибки связанные с неправильным использованием или пониманием технологий, когда человек сам толком не понимает что делает и какие последствия будут у его решений.

Так вот, первые три группы ошибок - это как раз "нормальные" ошибки, понятно, что домен коллизий в этих группах такой, что рассмотреть все варианты - невозможно. А последняя группа - это банальная безграмотность, и если такие ошибки происходят редко (знать всего, конечно же нельзя), то это норм - признал, исправил и ок. Но если специалист часто совершает именно технические ошибки, то считать их "нормальными" никак нельзя. Очень часто, в подобных случаях свою безграмотность прикрывают тем, что мол "ошибаться - это нормально" или "программирование - это сложно".

Так что, ошибки - это норм, но если это одни и те же ошибки, которые сыпятся как из рога изобилия, то это уже профнепригодность. )
👍56🔥42🤔1
Успех - это когда твои стримы по архитектуре начинают использовать другие люди, для подготовки своих обучающих курсов. Если вы тупо не копируете видео, а просто используете информацию, которую я рассказал, то спрашивать у меня разрешения не нужно.
Я всего лишь собрал материал воедино из многих источников, плюс добавил описание своего опыта. Я не обладаю "исключительными правами" на эти знания. Более того, все мои ролики на Ютубе выходят по Creative Commons, их тоже можно использовать как хотите, не спрашивая у меня разрешения.
👍105❤‍🔥20👏9🔥4
Комментарий к видео про REST-плагины.
У меня только один вопрос: а почему не Katalon?
😁23👍1
😁75🔥13🤣10👍6👎4
Вчера записывал видос по API, рассматривал публичные API разных больших и не очень компаний. И в какой-то момент смотрю на экран, хочу сказать одно (потому что по логике уже сформировал ожидание), делаю щелчок мышкой и вижу совсем не то что ожидаю, в голове "че, за????", чтобы не рвать видео перешел в режим "говорю и думаю параллельно" общими фразами отработал, но заминка все равно заметна. И вот сейчас дилемма - вырезать этот кусок, или оставить?
Что думаете? Палец вверх - оставить как есть, палец вниз - вырезать этот позор.
👍316👎11😁3🤔3❤‍🔥1
https://www.youtube.com/watch?v=lKRD9ZnIYWk
На it каналах в ютубе периодически пытаются сделать видео в формате шоу. Я помню Форт Боярд математиков, трансляции от ExtreamCode, что-то подобное пытались делать и другие ребята. Но мне зашел вариант от Ромы Сакутина. У него уровень производства роликов значительно вырос за последнее время. Так что для пятничного расслабона можно посмотреть.

Осторожно маты!
👍25👎8😁5