Все потоки

Доброго времени суток. Я iOS-разработчик (хлопки-хлопки).

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

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

"тебе никогда никто не расскажет😂 в нашем деле все сам 😂"

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

Я знаю, какое у вас сейчас лицо

Не замечал ли ты, читатель, что некоторые времена похожи на другие, бывавшие ранее? Может быть, интересно, когда пройдет мода на докер или вернутся другие, более славные, времена? Почему у Go, Rust, виртулизации, нейросетей и даже самого Веба нет перспектив? Ответы на эти вопросы может дать астрология!

Но сначала придется развеять некоторые мифы и предубеждения просвещением. Сразу следует сказать - изложенное ниже не является противоречащим современному состоянию науки. Более того, для правильного понимания нужно быть в курсе некоторых достижений XX века, тогда как сейчас не только большинство гуманитариев, но и многие технари не знают, что такое хэш-функция. Если готов отбросить предубеждения вроде "ведь газетные гороскопы фигня полная" (нет, мы не про это) или высокомерие к древним людям (вообще-то человеческий мозг не менялся примерно 40 тысяч лет и был таковым для вещей, необходимых тогда для выживания, современный "знающий" человек скорее тупее, так как не выживет в той среде), то - добро пожаловать под кат!

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

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

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

Если вам о чём-то говорят фамилии Зив, Хомченко и Рымкевич, иди сюда, дай обниму, бедолага-олимпиадник, то вы наверняка знаете, как важно прорешивать задачи для полноценного, осознанного и глубокого понимания изученного материала. Когда нет или совсем мало реальной практики, задачи дают возможность покрыть практикой все теоретические знания, погрузиться в неожиданные выводы, сложности, баги, препятствия. Более того, даже если практики достаточно, задачи помогают относительно быстро, комплексно и глубоко проработать типичные и нетипичные ситуации, возникающие в разработке (любой другой науке). Это всегда безопасный (никто не взрывает лабораторию и не роняет прод), доступный и удобный способ подробно разобраться в предмете. Определённо, программирования это касается в первую очередь.

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

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

Я являюсь студентом по обмену из российского ГМИГ имени Трофима Лысенко (Главный Мурманский Институт Генетики). Учился на инженера-программиста и пол года назад был отправлен в Америку в качестве студента по обмену. Это у меня получилось благодаря двойному гражданству (я гражданин Ирана и России).

К нам на лекцию пришел один из разработчиков Microsoft и рассказал про .NET 10, подробнее в самом низу статьи под спойлером.

.NET 10 или как его теперь начнут называть .NET X - это новая версия .NET, которая выйдет уже в 2024 году. Большая часть этой статьи посвящена именно новым возможностям C# 13.

Почему .NET 10 и где .NET 9?

"У нас так принято." - Дословный перевод. Больше комментариев разработчик не дал.

Начнем цикл статей нашей компании легко и непринужденно, с темы из мира front-end. Надеюсь, что статья будет полезна тем, кто хоть как то связан с миром front-end. Предупреждаю, что backend разработчикам может быть скучновато из-за того, что у них давно все стандартизировано)

Когда я провожу собеседование на позицию React разработчика, обычно задаю общий вопрос об архитектуре - "как бы ты строил архитектуру своего приложения и почему?". После обсуждения, я начинаю рассказывать небольшую часть материала из этой статьи, 5% по содержанию, приводя тезисы, по которым можно будет собрать общую картину моего видения. И обычно получаю положительную обратку. Поэтому решил изложить этот материал более развернуто здесь. Буду отправлять ссылку тем, кому это может пригодиться.

Всем привет! Я начинающий разработчик и увлекся Embedded стороной вопроса. Лучший способ запомнить информацию - написать какой нибудь конспект и поделиться им. Ниже моя краткая выжимка о CAN шине и передаче данных через нее.

Всем доброго дня!

Стал искать задачи по SQL, чтобы освежить свои знания, и к немалому удивлению обнаружил, что, несмотря на очевидную востребованность темы, интересные наборы задач на русскоязычных ресурсах можно пересчитать по пальцам. Хочу поделиться с сообществом своим мнением по поводу этих наборов, тем более что в отличие от самих задач далеко не все их авторские решения мне понравились.

Во времена dial-up под интернет-шумом был тот самый ламповый звук модема, подключающегося к серверу провайдера по телефонной линии. Достаточно было поднять трубку, чтобы услышать, как устройства «общаются» друг с другом. Шумящие модемы остались в прошлом, но сегодня в интернет-эфире все более плотным становится другой вид шума. Его вызывают блуждающие в сети пакеты.

Это статья является продолжением предыдущей темы - «Почему смерть АЗС наступит раньше, чем вы думаете?» но с более позитивным взглядом на перспективу.

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

Но так ли все однозначно может быть в отношении бывших АЗС продававших ископаемое топливо традиционным автомобилям при переходе на зарядку электромобилей? Часть АЗС обычного вида безусловно отомрут, но что может произойти с теми заправками которые находятся вдали от городов и мощных электросетей?

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

Для начала стоит определиться с различиями в градации АЗС. Так по расположению различают дорожные и городские АЗС.

У городских заправок будущее может быть печально ввиду высокой конкуренции с массой вариантов медленной зарядки у дома владельца электромобиля, а также на стоянках у супермаркетов, парковок и прочих мест где будет выгодно размещать зарядные станции. В качестве конкурентного преимущества бывшая АЗС могла бы установить более мощное зарядное оборудование, которое позволило бы зарядить автомобиль за относительно короткое время — от получаса до четырёх часов. Но тут все упирается в стоимость и мощность такой ЭЗС. Причем ограничение по мощности может оказаться даже более непреодолимым чем по цене и в итоге уже даже сейчас компании-интеграторы зарядных станций в качестве оптимального варианта рекомендуют владельцам бывших АЗС в городах устанавливать одно зарядное устройство на 2 скоростных поста и одно медленное, общей мощностью не более 100-120 кВт.

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

Я не буду расписывать аналоги, их преимущества, недостатки и т. д. Но просто расскажу, чем руководствовалась, когда собирала все эти принципы в один текст. Конечно, материалами исследований составили работы таких дизайнеров, как: Якоба Нильсен, Й. Мюллер-Брокманна, М. Ильяхова, И. Б. Бирмана, А. Лебедева, А. Горбунова, И. Иттена, А. Литриса, А. Мариока, Ш. Адамса, Пол Фитса, П Боаг, Д. Линдси и других очень уважаемых авторов. Далее, основываясь на существующих законах и принципах UI UX дизайна были проанализированы сайты популярных музеев мира таких как: MoMA, Metropolitan, Эрмитаж, Государственный исторический музей, и крупных площадок с большим количеством цифровых изображений: Google Arts & Culture, Pinterest, Shutterstock, Госкаталог, «Артхив»

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

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

TL;DR

Весь код для микросервисов и e2e теста тут

Рекомендую быстро пробежаться по коду перед прочтением статьи т к в самой статье я объясню только неочевидные моменты реализации e2e тестирования.

Всем привет!

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

Сегодня я хочу рассказать вам о волшебном алгоритме, который стоит за безопасным общением в интернете, и, в частности, в нашем любимом мессенджере - Telegram. Этот алгоритм называется алгоритмом Диффи-Хеллмана, и его история начинается в далеком 1976 году. На этом с историей закончим 🙂