Пользователь
Cloak — это подключаемый транспорт, который расширяет возможности традиционных прокси-инструментов, таких как OpenVPN, Shadowsocks и Tor для обхода сложной цензуры и дискриминации данных.
Руководство будет включать:
1. Предисловие
2. Описание работы Cloak
3. Настройку сервера Cloak
4. Настройку клиента Cloak на OpenWRT
5. Настройку клиента OpenVPN
Возможно, вы ловили себя на мысли, что было бы неплохо провести для коллег-новичков в Linux небольшой курс с практическими задачками. Такой курс, чтобы после его прохождения, они могли использовать ОС на уровне продвинутого пользователя, активно пользоваться терминалом, писать bash-скрипты, шарить за wildcard и SSH-туннели и прочую магию Linux. При этом было бы здорово, чтобы оценка за выполнение практической работы выставлялась в LMS автоматически, а вы бы только отслеживали прогресс коллег в электронном журнале и помогали с затыками. Если вы узнали себя в описании - эта статья для вас. Материалы этого курса также могут быть полезными для преподавателей учебных заведений, желающих добавить практики в свои курсы по Linux.
В программировании нет вообще никаких непреложных истин. Даже самые очевидные правила могут иметь контекст, в которых их применять нельзя. К сожалению в 99% организаций есть прям заповеди, обязательные к исполнению. И есть правила, которые считаются правилами хорошего тона (как не сморкаться в занавеску). Однако всегда бывают ситуации, когда лучше все-таки сморкаться.
Вот примеры.
1) Например, DRY — don’t repeat yourself. Хорошее полезное правило, но его можно довести до маразма. Из того что я встречал на практике: есть два разных по бизнес-смыслу раздела, которые начинались с простого CRUD, и многие части (и фронта и бека) выглядели во многом абсолютно одинаково. Если их объединить с помощью общей высосанной из пальца абстракции и тем самым избавиться от небольшого дублирования кода, то потом (очень скоро) можно будет сойти с ума, потому что эти две вещи скоро разъедутся, обрастая кастомными фичами, и абстракция будет только вредить. Нельзя абстрагировать неабстрагуемое, даже если DRY нарушен.
«[Немного] дублирования обходится гораздо дешевле, чем неправильная абстракция» — Сэнди Мец
Т.е. DRY — хороший принцип, но бывают исключения.
На кластерах клиентов, которые мы обслуживаем, есть как «одноголовые» инсталляции Redis (обычно для кэшей, которые не страшно потерять), так и более отказоустойчивые решения — Redis Sentinel или Redis Cluster. По нашему опыту, во всех трех вариантах можно безболезненно переключиться с Redis на KeyDB и получить прирост производительности. Точнее, избавиться от бутылочного горлышка Redis в одно ядро. Хотя в новых версиях Redis(r) появилась обработка I/O в отдельных тредах, иногда этого бывает недостаточно.
В то же время, если мы хотим использовать отказоустойчивые решениями вроде Sentinel и Cluster, нам понадобится поддержка этих технологий на уровне библиотеки, которую приложение использует для подключения в Redis. Причем лишь немногие библиотеки умеют читать из реплик Redis — в обоих вариантах (Sentinel и Cluster) чтение, как правило, происходит с мастеров. И запись, естественно, тоже происходит в мастеры.
В итоге у нас есть несколько реплик довольно дорогого in-memory-хранилища, а в рабочем процессе используется только часть из них. Остальные — на подхвате. Хотя в большинстве кейсов операции с in-memory NoSQL DB — это именно операции чтения.
Однако если посмотреть в сторону KeyDB, то можно увидеть, что там есть киллер-фича — и даже две: я говорю о режимах Active Replica и Multi-Master. Использование этих режимов позволяет получить распределенный отказоустойчивый KeyDB, совместимый с Redis, писать в любую ноду, читать из любой ноды. И все это с точки зрения приложения выглядит как один экземпляр Redis без всяких Sentinel — то есть в коде приложения ничего менять не придется.
Звучит как фантастика?
Так ли на самом деле работает процесс загрузки классов, как его описывает Wikipedia и Baeldung? ClassNotFoundException — это откуда и чье? Какие виды загрузчиков классов актуальны в Java 20?
Объясняем подпроцесс загрузки, из системы Java ClassLoader, на приятных Excalidraw диаграммах, со ссылками на оригинальные источники.
Все мы пользуемся разными сервисами — какими именно, зависит от специальности и текущей необходимости. GitHub, ChatGPT, Tableau и другие давно и прочно вошли в нашу жизнь. Но есть и аналоги этих востребованных сервисов, причём аналоги с открытым исходным кодом. Эта статья посвящена таким альтернативным сервисам и ПО. Вероятно, многие из них могут оказаться полезны для читателей. Если же у вас есть собственный вариант, расскажите о нём в комментариях.
На конференциях эта тема (монолит vs микросервисы) обсуждается с завидной регулярностью, но обычно в техническом ключе. Кто-то любит консистентность монолита, кто-то гибкость микросервисов, какие-то инструменты удобнее, какие-то нет.
Очень мало обсуждается вопрос команд и их взаимодействия, а ведь это самое главное при выборе. Я написал небольшую заметку в одном телеграм-канале, и в результате последующих обсуждений незаметно выросла целая статья на Хабр.
Поехали.
Итак, главное — это организационная структура компании и процессы взаимодействия команд. Да-да, как всегда, не технологии, а люди. Сейчас я работаю в Каруне, до этого работал в компаниях поменьше, видел, как набивались шишки, поэтому могу сравнить.
Когда команда одна, не очень большая (two pizza team), то никто никому не мешает. Код ревью, рефакторинг, деплой проходят быстро и весело. Бизнес сфокусирован на цели и работает как единое целое. Целью, кстати, зачастую является проверка гипотезы, нужен ли вообще этот проект кому-то или нет.
Привет, Хабр!
Я решил посвятить свою первую статью SQL. Вопросы, рассмотренные ниже мне задавали на собеседованиях на позицию python-разработчика. Естественно отвечать правильно получалось не всегда, а если точнее то чаще не правильно, однако проведя N часов в рефлексии я составил перечень ответов, которыми пользуюсь до сих пор.
Данная информация предполагает знание основ языка запросов и я надеюсь, она окажется полезной для разработчиков, которые сейчас активно ищут работу а также, что ты прочитаешь этот текст до конца и добавишь свой вопрос к перечню (ну или поправишь неточности в существующих)
Почему вы выбрали фреймворк Scrum, а не метод управления проектами Kanban? Не можете ответить? Значит — лично вы Scrum и не выбирали. Кто-то сделал это за вас.
Даже в тех редких случаях, когда люди способны ответить на вышеприведённый вопрос, их мотивы раскрывают глубокие заблуждения относительно Kanban. Выражаются эти заблуждения в упоминании следующих причин выбора Scrum:
Меня зовут Андрей Булов. Я простой питерский технарь, архитектор, разработчик, DevOps технический менеджер. Сейчас работаю в Quantori.
Я не буду описывать самоорганизующиеся команды, а расскажу про алгоритм их создания. Это мой личный опыт — я так работаю с командами (их было 30+). Он перекликается с Management 3.0, моделью Херши-Бланшар, LeSS, Sсrum и даже SAFe, а также со многими другими софтовыми областями. И в нем есть конкретика на уровне действий.
Для ленивых: я исследую окружение, проектирую дизайн культуры, объясняю правила и делегирую задачи команде. Я не поддерживаю внедрение самоорганизации через фреймворк. Видео моего выступления об этом на конференции TeamLead Conf 2021 можно посмотреть здесь.
Любой программный продукт, будь то веб-сайт или мобильное приложение, основан на коде. Чем согласованнее и целостнее эта база, тем удобнее с ней будет работать, например, при необходимости доработки проекта, передачи на сопровождение другой команде.
Основными критериями качественного кода являются следующие: простота восприятия, гибкость для модификаций, возможность обновления, понятность, тестируемость. Однако зачастую работа над проектом ведется в спешке, под давлением и код пишется людьми с разным уровнем квалификации (с разным мышлением). И даже опытные разработчики не всегда пишут код самого высокого качества. Поэтому для повышения качества кода проводится процедура code review.
Наша команда как и многие другие работала с облачными продуктами Atlassian: Jira и Confluence. Осенью прошлого года, Atlassian отправила нам письмо счастья.
Собеседования могут отличаться в технической части, но в беседе с HR все обычно одинаково: вам задают какие-то общие вопросы, а вы можете задать свои. И эта беседа очень важна — с ее помощью и вы, и компания можете составить друг о друге первое впечатление и понять, сработаетесь ли вы вообще.
Мы поговорили с Лерой Зеленой, которая прошла через множество собеседований. Она поделится своим опытом, в том числе неудачным, и расскажет, какие вопросы стоит задать и как оценивать вопросы, которые задает HR. Передаем ей слово.
Для начало придется забыть слово заставить. Задача помочь сотрудникам полюбить зарабатывать вам деньги.
Меня зовут Слава. Я создал и развалил сеть ночных клубов, прошел 300 собеседований на маркетолога, проработал как подрядчик и сотрудник в более 50 компаниях. Сейчас занимаюсь системным маркетингом.
Там, где я работал, были разные системы управления, но всегда работал один и тот же принцип.
Мы в Quadcode мечтали сюда попасть целых 8 лет, но все не находилось времени, а 3 года назад компания наняла бренд-менеджера (меня), чтобы сдвинуть желание иметь свой блог с мертвой точки. Так мы и начали свою блогерскую карьеру на Хабре на русском языке. Это наша финальная статья, где мы не только подводим итоги нашего Хабр-путешествия, но и рассказываем про то, как начать вести собственный корпоративный блог и что вас ждет на этом пути. В статье будет много рефлексии, поэтому, если ваше настроение располагает, – добро пожаловать под кат!
