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

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

Charles proxy – это инструмент мониторинга HTTP и HTTPS трафика. Он выступает в роли прокси-сервера (промежуточного звена) между тестируемым приложением и сервером на бэкенде, позволяя не только видеть, но также перехватывать и редактировать запросы.

Для просмотра запросов/ответов при тестировании WEB приложений достаточно взаимодействия с Postman через API, либо просмотра в DevTools. Но для отслеживания трафика при тестировании мобильного приложения могут возникнуть сложности.
Взаимодействие происходит по локальной сети, к которой подключены ПК и мобильное устройство.

Установка

Для начала необходимо скачать Charles на ПК по ссылке https://www.charlesproxy.com/download/ . Далее установить и открыть программу.

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

Задумывались ли вы, почему мы используем отдельную базу данных для каждого сервиса, но при этом один общий брокер для нескольких сервисов? Ведь вполне возможно использовать базу данных в роли брокера сообщений. Однако, если мы попробуем заменить RabbitMQ на Redis, то натолкнемся на проблему общего использования базы данных. Это станет проблемой, потому что общее использование базы данных является антипаттерном.

Как вы думаете, когда и чем впервые оплатил человек?

Вряд ли это была знакомая всем карта с чипом и магнитной полосой во времена до нашей эры…

Конечно, альтернатива наличке появилась еще за пару тысяч лет до этого…

О том, как бартер превратился в оплату телефоном, вы узнаете из этой статьи.

Примерно 80% из нас, кто заканчивает университет с какой-либо IT-специальностью, в итоге не становится программистом. Многие устраиваются в техническую поддержку, системными администраторами, мастерами по наладке компьютерных устройств, консультантами-продавцами цифровой техники, менеджерами в it-сферу и так далее.

Эта статья как раз для таких 80%, кто только закончил университет с какой-либо IT-специальностью и уже начал мониторить вакансии, например, на должность системного администратора или его помощника, либо выездного инженера в аутсорсинговую фирму, либо в техническую поддержку 1-й/2-й линии.

А также для самостоятельного изучения или для обучения новых сотрудников.

За время своей трудовой деятельности в сфере IT я столкнулся с такой проблемой, что в университетах не дают самую основную базу касательно сетей. С этим я столкнулся сначала сам, когда, после окончания университета, ходил по собеседованиям в 2016 году и не мог ответить на простые (как мне сейчас кажется) вопросы. Тогда мне конечно показалось, что это я прохалтурил и не доучил в университете. Но как оказалось дело в образовательной программе. Так как сейчас, я также сталкиваюсь с данным пробелом знаний, когда обучаю новых сотрудников.

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

Именно поэтому я решил собрать основные темы в одну статью и объяснить их как можно проще «на пальцах».

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

Управлять программистами в ИТ-компании – дело особое. Не сказать, что сильно сложное. Совру, если назову простым. Особое.

Книжек, статей, курсов создано великое множество. Что-то помогает, у кого-то получилось. Собственно, промахнуться с оценкой сложно – отрасль ведь не просто существует, но и весьма активно развивается. Даже в нашей деревне. Значит, как-то, кое-как, с горем пополам, но управление программистами не только возможно, но и получается.

Однако, кризисы случаются. Бывает, что затяжные – например, какая-нибудь серьёзная деревенская компания не может ни найти, ни воспитать приличного руководителя программистов. Благо, сейчас это не великая проблема – бизнес вполне себе растёт лишь потому, что растёт рынок, и заполнить его некому. Поэтому за начальника сойдёт и табуретка. Но – лишь до поры, до времени.

Регулярно ИТ-бизнес думает-думает, решает-решает, плюнет, да и снова попробует старый добрый метод: нанять успешного руководителя из другой сферы. Производство, строительство, торговля – ну суть. Оттуда много кандидатов, у них подтверждённый опыт, зачастую – MBA, и они такие прям чёткие всегда! Знают, чего хотят, на что способны, чего им нужно.

Мне этих руководителей всегда искренне жаль – я знаю, что их ждёт, каков будет их путь, почему они в итоге уволятся. Я не семи пядей во лбу, просто в течение многих лет наблюдал их в обеих сферах – ИТ и той, из которой они пришли, где добились успеха. Могу плюс/минус сопоставить контексты, работающий инструментарий, важные и второстепенные личностные качества.

Много раз пытался объяснить, помочь – и начинающим руководителям-варягам, и тем, кто их тащит в ИТ. Никто, разумеется, не слушал. Ну да я уже привык, поэтому сижу себе помалкиваю.

Однако, тут такая история вышла: в ИТ-компанию собралась устроиться некто Ира, хорошая знакомая моего хорошего знакомого. Он, как мог, пытался её отговорить, но не преуспел, т.к. сам работает программистом, и руководителем никогда не был.

Попросил меня. Я предложил формат статьи – и моё мнение услышит, и ваше. В конце концов, вполне возможно, я не прав, как это обычно случается (если верить вашим комментариям).

Итак, погнали. Буду писать, как бы лично обращаясь к Ирине.

Я сколько лет на заводе козловой кран вожу, ни разу не выгорел! А эти, прям неженки! 

Знакомо?

Выгорание айтишников – это уже притча во языцах. Если в своей среде IT-специалисты еще находят понимание, то во вне они сталкиваются с диким отрицанием.

Ишь какие, депрессия у него! Работать не может! Дури вам в голову напихали, вот и оправдываете свою лень!

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

Осенью я был на митапе, посвящённом scrum'у. И услышал там интересный тезис: в слаженной скрам-команде роль тимлида/техлида минимальна, потому что все участники команды в той или иной степени являются носителями знаний и прекрасно самоорганизовываются благодаря скраму.

Сегодня одним из самых популярных в использовании инструментов в стеке техкомпаний является Kubernetes. С момента своего выхода K8s получил массовое распространение, расширив свою экосистему и увеличив количество пользователей. В 2021 году CNCF (Cloud Native Computing Foundation) провел опрос, который показал, что 96% организаций (которые приняли в нём участие) используют или уже пробуют Kubernetes в своем технологическом стеке.

Всем привет! Меня зовут Дмитрий Шкилёв, я тимлид команды Teachers Platform. Мы занимаемся личным кабинетом преподавателя и внутренними ресурсами, которые необходимы для обеспечения работы преподавателей. 

Сегодня хотелось бы поговорить про такую не очень популярную историю, как измерение показателей команды разработки. За рамками статьи хочу оставить, почему необходимо измерять что-либо в работе команды — это тема для отдельного рассказа. Также тут вы не найдёте готовых рецептов для построения бордов в Grafana, но зато получите всё необходимое, чтобы начать их делать самостоятельно. Цель статьи — поделиться, как с минимумом инструментов измерять интересующие тимлида показатели.

Под катом несколько кейсов. Они актуальны для конкретной команды с ее укладом, поэтому прежде всего погружу вас в наши процессы. Но при этом прошу помнить, что статья — не агитация за определённый процесс работы, а описание способа построения дашбордов на примере отдельно взятой команды. Вы вправе сами решить, делать ли вам Code Review, логировать ли время, оценивать с помощью идеальных часов или стори поинтов, использовать ли сабтаски или связанные таски, как связывать баги с задачами и каким образом разделять задачи по эпикам. И я надеюсь, что после прочтения статьи вы сможете создать актуальный для вас борд.

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

Что мешает сократить time2market? Поделюсь личным опытом в этой статье.

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

Но без делегирования полномочий не решается проблема загруженности ТОП менеджмента. Происходит интересная ситуация, когда есть человек “отвечающий” за проект, но все решения принимает ТОП менеджмент. Проблема становиться менее видимой, потому что “виноват” во всех принятых решениях ПМ. ПМ, как правило, ответственный человек, то он упорно ищет причины неудач в себе. В компании могут звучат красивые слова про то, что каждый может повлиять на ситуацию, у нас Lean, Agile и вот это все. Но это только мешает увидеть несоответствие обязанностей и полномочий.

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

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

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

Дано:
1. 2 команды, по 10 чел. каждая
2. найм - 2 человека в квартал.
3. средняя ЗП сотрудника - 3500 евро/мес., 20 евро/час
4. средняя ЗП руководителя - 4500 евро/мес, 25 евро/час
5. бизнес-процессы требуют доработок

Найти:
Сколько потеряет бизнес за квартал/год?

Привет, Хабр! В этой статье я написал про ошибки и приколы, с которыми я столкнулся за пару дней использования ChatGPT. Сразу оговорюсь — таких жёстких примеров, как на картинке, у меня не было. Но были даже более интересные!