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

Я прислушался к вашим советам и попробовал на голосовом вводе произнести фразу "please merge two arrays ". У меня получилось следующее " please merge to erase". Я вбил эту же фразу в гугл переводчик и включил произношение, у него получилось следующее " please match two arrays".
А что получается у вас?

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

Хочу поделиться списком рекомендованной литературы для разработчика. За один день такой объем, конечно, не осилить, но как долгосрочная цель - ок.

https://dckms.github.io/system-architecture/emacsway/it/self-education/self-education-for-software-engineer.html

#книга #рекомендация

Кухарке на заметку, разница между параметрами и аргументами:

function someF(a, b)...

someF(1, 2)

a,b - параметры
1, 2 - аргументы

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

Интересно на эту тему почитать статью Mark Seemann - https://blog.ploeh.dk/2020/01/13/on-doing-katas/

Хороший вопрос про английский. Мой опыт таков:
1. Я могу читать даже очень сложные тексты (например, на arxiv.org), но скорость чтения раза в 3-4 меньше чем русского текста.
При этом дело не в том, что мне не хвататет лексики. Не знаю с чем это связно, просто английский текст жрет "батарейку" сильнее, быстрее устаю.
2. Практики устной речи, да еще с теми для кого английский - родной язык, у меня было очень мало. Почти всегда - переписка. Причем, я отвратительно знаю грамматику.

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

Из моего опыта - устная речь чтением не прокачивается от слова совсем. Грамматику тоже надо тюнить, но читая названия коммитов к англоязычным репозиториям, замечаю, что, скажем, с артиклями никто не парится.

Так что если нет практики, причем ее надо очень много, то крайне сложно прокачать речь.

https://youtu.be/vjTO0BqZwsY

Футболки с логотипом канала продолжают уходить в массы, сейчас в нашу банду соеров входит три человека - Михаил Фленов и Денис Westwind.Galeaf

Ссылку на стрим Дениса где он в футболке прилагаю.

https://youtu.be/y9_xbFiXxjY

А это видос Михаила Фленова где он в футболке соера.

Очень давно я вел свой блог codeart.ru, я давно его удалил, но некоторые заметки ушли в Интернет. И вот пару из них я недавно нашел. Решил перепечатать их сюда:
Заметка из 2007: https://telegra.ph/10-razlichij-mezhdu-stroitelyami-i-programmistami-07-04

Вторая заметка, написана позже, но не помню в каком именно году. https://telegra.ph/Maska-podseti-Vy-uvereny-chto-ponimaete-dlya-chego-ona-nuzhna-07-04

Ну и последняя, моя самая любимая, тоже из 2007.
https://telegra.ph/Skazka-o-tom-kak-ya-stroil-zamok-iz-peska-07-04

Количество WEB API растет не так уж и быстро, рост достаточно "крутой", но все же линейный.
Т.е. говорить, что современная разработка - это исключительно борьба API - очень смело.
Мне кажется, что значительная часть рынка - это по-прежнему монолиты без четких архитектурных границ, и соответственно без связывающих API.

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

Я так понимаю, что майнить крипту при текущем курсе этой самой крипты и стоимости видеокарт стало невыгодно. Поэтому спрос на карты упал.

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

Но вот что-то пошло не так.
https://www.theverge.com/2022/7/1/23191634/nvidia-amd-gpu-shortage-over-3080-3070-3060-radeon-rx-6900-6800

Поздравляю resivalex с получением PRO сертификата за участие в проекте https://github.com/soerdev/soer

Сертификат ушел на почту.

Напоминаю, что самый активный контрибьютер месяца получает PRO. Задачки, которые можно решить, есть в Issue проекта

Ребята, а если 9 или 10 июля (выходные на этой неделе) замутить встречу канала S0ER?
Поставьте палец вверх кто хочет и может прийти. А в комментах можно написать когда лучше.

Место предлагаю Сочи на морпорте кафе "Мой кофе".

Задорная книга о связи математики и программирования. Объясняется на примере Python. Сначала делается введение в Python, затем основные сущности математики, необходимые программисту, показываются через синтаксис языка.

В книге нет ответа на вопрос "Зачем?". Часто людей интересует сугубо практический вопрос "Что я получу, если буду использовать математику?". Ожидается какой-то емкий, измеримый ответ. Но этот вопрос из серии риторических "В чем смысл жизни?". Каждый для себя должен решить сам, какие бонусы ему дает математика. В любом случае, обойтись без математики можно. А если еще и плохо знаете математику, то точно никаких бонусов не будет.

Книга хороша для тех кто учил математику, но забыл. Потому что те кто хорошо владеют, например, теорией множеств, будут постоянно ловить "капитана очевидность". В этом смысле есть некоторая бесполезность книги - тем кто плох в математике вроде как и не надо, тем кто хорошо и так все понятно.

#книга #отзыв

Продолжаю делиться своими миниисториям в NowApp. Мне удалось ещё туда затащить Дена и теперь в ленте стало чуть поживее

https://dev.to/nx/nx-the-fastest-growing-monorepo-solution-in-the-js-ecosystem-5en9

К монорепозиториям у меня двоякое отношение, с одной стороны есть очевидные преимущества:
- все лежит вместе и обновляется "сразу"
- можно использовать генерацию кода сразу под структуру монорепозитория
- меньше гемора с управлением зависимостей
- удобное тестирование только измененного кода
- удобна совместная разработка

Но на практике дополнительная автоматизация (в данном случае nx) - это дополнительные затраты на изучение и сопровождения. Мало того, что в работе постоянно появляются новые библиотеки, так еще надо колупаться и разбираться "а что там добавили в nx?".

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

Я не согласен с утверждением, что программисты большую часть времени сосредоточены на коде бизнес-логики. Программисты большую часть времени сосредоточены на стыке бизнес-логики и инфраструктуры, потому что постоянно приходится делать "кодирование" понятий естественных для человека, в понятие естественные для компьютера. Цвет - r, g, b, фотография - набор <x, y, r, g, b>[] и т.д.
Большую часть времени мы думаем как "хочу найти самые дешевые билеты" превратилось в "сделать краулинг, сделать парсинг, продумать структуру для быстрого поиска" и т.д.

Получается что, инфраструктура - стандартна (БД, MQ, HTTP), бизнес-логика "скудна" (хочу быстро найти, хочу оптимизировать затраты, хочу построить план), а вот "клей" (как бизнес соеденить с инфраструктурой) он самый сложный, причем именно с ним чаще всего возникают вопросы - а куда его отнести?

Так что деление на инфраструктуру, сервисы и бизнес-логику хоть и универсально, но не так уж и точно отражает суть проектирования.

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

Из того что не понравилось - поверхностное изложение функционального программирования, водянистость примеров. И малое количество эвристик для оценки качества теста. Было бы лучше больше примеров в стиле хорошо/плохо.

В целом книга лёгкая и годная.

#книга #отзыв