Приветики. Надеюсь, все отошли от новогодних, и можно писать и читать дальше. Как хозяин умного дома, я состою в чатике по Home Assistant, там прекрасное ответчивое комьюнити,
но периодически задаётся вопрос по тому, как собственно выставить свой веб сервис в интернет. И оказывается, что в двух словах тут не ответишь, а вменяемой инструкции на которую можно дать ссылку - нет. Так что теперь она будет здесь.

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

Мы рассмотрим здесь несколько сценариев - статический белый айпи, динамический белый айпи, и серый. Для серого рассмотрим варианты с готовыми сервисами, с помощью Keenetic и с помощью ssh туннеля. Погнали!

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

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

Привет, Хабровчане!

Для тех, кто не в курсе, gRPC - это открытый фреймворк от Google, который был представлен миру в 2016 году. Основываясь на протоколе HTTP/2, gRPC использует Protocol Buffers в качестве языка описания интерфейса.

Основная идея gRPC заключается в создании универсального механизма для эффективного и быстрого обмена данными между различными сервисами и приложениями. В этом его главное отличие от традиционных REST API. gRPC работает на основе протоколов, которые определяют "контракты" между клиентом и сервером, позволяя им общаться независимо от ЯПа.

Всем привет! Я Ирина Матевосян, системный аналитик в направлении продуктового и системного анализа в отделе Tinkoff Mobile Core. Мы разрабатываем общие библиотеки, которые используют все мобильные приложения экосистемы Тинькофф. 

Расскажу о протоколе gRPC. На Хабре много статей о тонкостях реализации, рассчитанных на разработчиков, я же хочу познакомить с ним своих коллег. Разберем, как работает протокол и как написать контракт так, чтобы вас поняли, но не будем погружаться в тонкости программной реализации, а скорее расширим кругозор. Возможно, для кого-то gRPC станет крутым решением в работе.

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

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

Успехов тебе!

Всем привет! Меня зовут Илья Денисов, я занимаюсь backend разработкой уже более пяти лет и сейчас пишу на языке go. Сегодня я предлагаю вам поговорить о кэшировании. Постараюсь рассказать о базовых концепциях, а также затронуть ряд особенностей, неочевидных на первый взгляд.

Привет, меня зовут Денис, и я работаю руководителем отдела проектирования в компании SSP SOFT.

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

Начну с того, что я сам числюсь системным аналитиком всего два года. Я сразу попал в «ведущие системные аналитики», пропустил стадии junior, middle. Спустя год работы ведущим системным аналитиком, меня назначили руководителем отдела проектирования, доверили развитие аналитиков в компании. С этого момента я стал обращать внимание на то, как работают аналитики в разных проектах, чем они занимаются. В компании работает около 30 аналитиков, они заняты в проектах, связанных с разработкой программного обеспечения для бизнеса. Продукты и рабочие процессы в проектах сильно отличаются, это позволяет увидеть всё разнообразие типовых задач, которые выполняет аналитик в команде.

Хотя я не получал специализированного образования в области системного анализа, я знаком с понятиями «требование» и «техническое задание» с самого начала своей карьеры. За плечами 18 лет опыта в ИТ, разнообразные проекты и продукты, есть и успешные, которыми я очень горжусь.

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

Прежде чем перейти к проблематике, зафиксируем несколько вводных:

Привет! Меня зовут Александр,  мы с семьей живем в небольшом загородном доме, который обустраиваем своими руками. Сборку “умного дома” я начал около года назад в связи с необходимостью автоматизации отопления в холодное время года. Из коммуникаций к дому подведено только электричество, без возможности подведения газа, поэтому основным источником тепла зимой являются электроконвекторы и печь-камин. Первый холодный сезон показал ряд неудобств такой системы, ведь все работало только на ручном управлении. Регулировка термостатов в зависимости от температуры на улице, включение/выключение конвекторов при дополнительном печном отоплении, отсутствие контроля температуры воздуха в комнатах - все это побудило меня сделать обогрев дома автоматическим, независимо от присутствия человека. В качестве основы для “умного дома” я решил применить готовую систему Aqara, она показалась мне наиболее интересной. Выбор системы основывался на простоте подключения и управления устройствами, без добавления какого-либо кода вручную, так как я не являюсь IT-специалистом. Разумеется, на автоматизации отопления дело не остановилось, ведь “умный дом” - это настоящий конструктор. В дальнейшем, я организовал управление освещением, настроил охранную систему, установил датчики дыма и датчики протечки воды (которые уже несколько раз пригодились). Получившаяся система “умного дома” помогает нам просто и эффективно решить ряд задач по обустройству быта и создать комфортные условия для проживания.

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

В процессе работы над проектом потребовалось генерировать аннотации OpenAPI налету из реализованных в проекте http-хэндлеров. Ни одна из имеющихся реализаций не удовлетворяла требованиям по удобству использования и поддержки. Поэтому пришлось написать свою обертку над echo.Group, с помощью которой можем получить swagger аннотацию на основании тех путей и с теми параметрами вызова, которые реально зарегистрированы в сервере. О причинах и путях реализации в статье.

Или как понять, когда остановиться

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

— Скажи, а зачем нам вообще нужны аналитики?

— И действительно, зачем? – подумал тогда я и написал заявление

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

Итак, нам нужен системный аналитик, который формирует требования и разработчик, который эти требования реализует в коде.

Если спросить у любого разработчика, каким главным свойством должны обладать системные требования, он, скорее всего, скажет: «чтобы было понятно, что делать». И это проблема. 

Заключается эта проблема в том, что между сбором и систематизацией требований (прямая и понятная задача аналитика) и непосредственно кодированием (прямая и понятная задача разработчика) есть область проектирования решения; задачи из этой области могут и должны выполнять обе роли.

В Германии инженерам хорошо платят, в Португалии тепло, а в Финляндии много стартапов и низкая конкуренция. Но что IT-специалисту делать в Словакии? Стоит ли туда перебираться, и не получится ли, что переедешь в ту же Россию, только в Европе?

Поговорили об этом с Сергеем Федосеевым, который уже три года живет в Братиславе — учится и ведет там бизнес. Он рассказал, каково вообще живется в Словакии, как тут с работой и расходами и почему уехать сюда легче, чем в любую другую страну Европы.

Контекст и предыстория

Работа с геопространственными данными и отображение карт являются неотъемлемыми составляющими множества бизнес-приложений. Это могут быть городские и региональные информационные системы, приложения для нефтегазовой отрасли, системы управления транспортной инфраструктурой, а также службы доставки и многие другие. У нас в CUBA Platform для построения подобных приложений помимо базовых возможностей, предоставляемых из коробки, существует довольно обширный набор дополнений и компонентов. Одним из них является Charts and Maps, которое помимо отображения графиков позволяет интегрировать в визуальную часть приложения Google-карты. В прошлом году Google обновил условия использования своих картографических сервисов, что повлекло за собой рост стоимости, а также ввел условие обязательного наличия платежного профиля для использования API. Эти обстоятельства заставили большинство наших клиентов задуматься об альтернативных поставщиках карт, а нас подтолкнули к разработке нового компонента карт.

Рендерер Quake III

• Система шейдеров, построенная поверх фиксированного конвейера OpenGL 1.X. Это было большим достижением для 1999 года. Она обеспечивала большое пространство для инноваций в эру до повсеместно распространённых сегодня вершинных, геометрических и фрагментных шейдеров.
  
• Поддержка многоядерной архитектуры: клиент-серверная модель OpenGL блокирует некоторые методы и система потоков частично решает эту проблему.