Привет, Хабр!

В этой статье я расскажу о своем опыте изучения английского языка и поделюсь вещами которые работали и не работали для меня. Процесс изучения языка очень индивидуален, и никогда нельзя утверждать что верный какой-то один метод / схема (хотя некоторые статьи на Хабре прямо говорят: вот этот метод правильный, а вот этот нет).

Начнем с бекграунда и причин.

Я – инженер машиностроитель (мой профиль – торцевые уплотнения вращающихся валов). Я начал работать в своей отрасли сразу после бакалавра, параллельно заканчивая магистратуру, и как только я начал работать, я стал стараться впитать как можно больше теоретических знаний по моей специальности из академических источников. Достаточно бысто я понял, что последняя серьезная книга по моей специальности на русском языке была написана в 1978 году. И спустя больше чем 40 лет технологии сильно поменялись, а вот их описание на русском языке отсутствовает. Зато я нашел на reddit людей работающих в штатах в моей же отрасли. Они мне насоветовали кучу классной литературы. Разумееется, она вся на английском, и русского перевода не имеет.

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

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

Постоянно откладываешь дела на потом и не видишь в этом проблемы? Мне это знакомо. Расскажу как не повторить моих ошибок и почему пора это прекращать. Не откладывай эту статью на потом!

Как выглядит идеальная работа программиста? Что делает делает хорошую работу хорошей? Хотя бы не плохой?

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

А сталкивались ли вы с такой ситуацией?

Впервые известие о том, что фирма PADAUK Tech продаёт микроконтроллеры по три цента появилось в 2018 году. Эта новость вызвала интерес и обсуждение на форумах, а затем благополучно была забыта (по крайней мере в русскоязычном комьюнити).

В статье расскажу о своём опыте освоения микроконтроллеров PADAUK. Кратко рассмотрим особенности архитектуры, средствах разработки и отладки, посмотрим что нужно учесть перед тем как использовать эти микросхемы в своих проектах. Протестируем микроконтроллер PFC161 на отладочной плате.

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

Я так давно пользуюсь услугами Github, что уже начал забывать как это страшно потерять код который целый день сочинял и отлаживал. Раньше для сохранения кода я использовал дискетки, потом cd-rom и переносной жесткий диск, потом пришли флешки... Все это для того что бы перенести код с рабочего компьютера на домашний и не потерять. И все эти устройства постоянно ломались терялись, у них заканчивался срок службы и т.п.

Потом я завел свои "облака" и хранил код на своем железе и рабочих компьютерах. И наконец появился Github. По началу что-то ещё дублировалось на своих серверах и внешних дисках, но к сегодняшнему дню я на столько привык к сервису Github, все на столько удобно и надёжно, что страх о том что "дискетка" может сломаться постепенно улетучился.

И тут на тебе! Оказывается в любой момент, по не зависимой от меня причине, меня могут отключить от этого технологического чуда! :-)

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

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

• Защита от измененных версий.
• Photon Plugin.
• Серверная валидация инаппов.
• Защита от взлома оперативной памяти.
• Собственная аналитика.

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

Как реализовать рабочую IoT систему на API Telegram, создавать устройства, предусмотрев масштабируемость и развитие проекта.

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

Событийные звуки, через код, программиста просят проигрывать с учётом изменения pitch в небольших пределах. Особо никто не парится. Всех устраивает встроенные возможности настройки компонентов и Inspector-ом все довольны.

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

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

Периодически я увлекаюсь [интересными проектами] и забываю «смотреть на приборы», игнорируя сигналы мясного костюма и мозга о том, что пора бы уже и отдохнуть. Замедлиться. Сделать паузу. Выдохнуть.

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

Это становится сигналом, который я не могу игнорировать. Свидетельство того, что батарейка моя на исходе, и надо что-то с этим делать, чтобы не свалиться в очередное выгорание.

Как мы столкнулись с неожиданным багом в .NET 5, расследовали возникшую проблему, и что же из этого вышло.

• Стандарт код-ревью
  
• Что проверять в коде
  
• Навигация по списку изменений (CL)
  
• Скорость код-ревью
  
• Как писать комментарии
  
• Как преодолевать сопротивление

Что это?

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

Всем привет, меня зовут Денис, я основатель сервиса Apphud – сервиса аналитики подписок iOS-приложений.

Как вы наверняка знаете, проверка состоит из двух этапов: ручная проверка (приложение просматривает человек) и автоматическая проверка ботом. Но, предполагаю, не каждое обновление проверяется человеком. Бывало, наши приложения проходили проверку менее, чем через 10 минут после отправки на ревью. С каждым годом доля автоматических проверок увеличивается и бот берет на себя все бóльшую роль при проверке приложений.

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