Мало просто сменить свою сферу работы на IT, желательно еще и стать хорошим разработчиком. Бывший тимлид и консультант Александр Усков рассказывает, как понять, что перед вами плохой разработчик и что с ним вообще можно делать

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

Настоящее всё больше походит на то, что некогда представлялось фантастикой. Меня зовут Павел Дудукин, руководитель Data Science-направления в Центре развития финансовых технологий (ЦРФТ) Россельхозбанка, и в этой статье расскажу, как мы вышли в финал международного конкурса Autonomous Greenhouse Challenge и что нас ждет дальше. 

Объединённая команда Россельхозбанка (РСХБ) и Московского физико-технического института (МФТИ) приняла участие в хакатоне Autonomous Greenhouse Challenge в 2021 году. Там собрался народ, заинтересованный в автоматизации тепличного выращивания сельхозкультур. Наша команда заняла второе место, уступив лишь объединённой команде университетов из Китая. Мы опередили участников из Стэнфордского университета, MIT, международного концерна BASF, Технического университета Мюнхена и др.

Интересно, что смогла придумать наша команда? Тогда добро пожаловать в нашу теплицу.

Меня заинтересовал челлендж: в течение 26 недель откладывать N+100 руб, где N - сумма, вложенная на прошлой неделе. Я решил откладывать деньги по средам, составил такую табличку в Google Sheets

Привет, Хабр! Относительно недавно после пары лет перерыва в айти, потраченных на изучение японского языка, мне пришлось срочно обновлять свои знания на работе. Ну знаете, искать возможности исполнить все хотелки начальника, как и положено эникею. Меня ждало много увлекательных открытий, но при этом, как водится, и немало боли и борьбы с непонятками. Docker, контейнеры, реверс DNS и реверс прокси, получение TLS сертификатов. В какой-то момент я наконец дошёл до удобного решения, которым я теперь хочу поделиться.

В своё время домашний сервер очень облегчил бы мне понимание Docker’а, да и удобство работы с ним неслабо бы повысил. Поэтому возникла идея написать эту статью, после прочтения которой любой человек даже с поверхностными знаниями в информационных технологиях сможет поставить себе постоянно доступный домашний сервер на базе Docker Swarm с удобной веб-мордой, простым получением TLS-сертификатов и Heroku-подобным функционалом (для чего будем использовать PaaS CapRover). 

Статья, в общем-то, рассчитана на новичков, обладающих какими-то техническими знаниями — школьников старших классов, студентов и просто любителей — а потому вряд ли будет интересна серьёзным профессионалам.

Автор: Аналитический центр УЦСБ

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

Итак, введем понятие: риск – влияние неопределенности на достижение поставленных целей (ГОСТ Р ИСО 31000-2019).

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

Что же представляет собой управление рисками ИБ? В общем случае процесс включает в себя следующие этапы:

Хочу узнать мнение хабра о предложенном ниже варианте пути трансформации структуры ИТ в компании (абстрактной).  

Решил написать данный пост потому что:

• увидел аналогичную ситацию с неразберихой в ИТ в нескольких компаниях;

• сталкнулся с нежеланием руководства ИТ общаться с бизнесом для выяснения потребностей бизнеса (руководство ИТ хотело сначало что-то сделать, а потом показать бизнесу - в результате бизнес был недоволен что ему показывают не то что он хочет);

• увидел поддержку "низов", и руководителей среднего звена, в необходимости указанных трансформаций, но не желанием топ-менеджмента что-либо менять;

• узнать мнение Habra.

Привет!

Меня зовут Слава, я технический руководитель направления «Застройщики» в Циан. «Застройщики» — это большая команда, внутри которой работают 25 человек. Из них 18 — разработчики и тестировщики. С середины 2019 года мы участвовали в экспериментах по удаленной работе в Циан. У нас успешно получилось перейти на частичную удаленку к началу 2020-го, еще до начала коронавирусных ограничений. Хочу рассказать об опыте перехода Циан на удаленку, в первую очередь со стороны IT.

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

Однажды мы заметили, что поисковая выдача в мобильной версии Циан замедлилась: плохо работала на стороне браузера, грузилось много ресурсов, приложение долго открывалось. Естественно, это не радовало пользователей и сказывалось на метриках. В мае 2021-го Google анонсировал изменения: с августа он станет учитывать метрики Core Web Vitals в ранжировании поисковой выдачи. Мы стали искать, в чём может быть наша проблема. В этой статье расскажем, где же проблема крылась, и как мы её решили.

Ситуация получилась следующая.
Компания переделывала сайт и сказал, что необходимо сделать его максимально гибким, чтобы, во-первых, можно было дизайн обновлять просто, во-вторых, сделать ещё несколько подразделов на базе готового функционала (вроде как SaaS фишка для заказчиков).

Сегодня большинство компаний используют методологию Agile при разработке программного обеспечения. У Agile есть разные системы с похожими принципами и конечными результатами, но они различаются по структуре и подходу к управлению. Какой из них лучше всего подходит для вашего проекта? Это Скрам или Канбан? Или оба?

В преддверии старта курса Agile Project Manager поговорили об этом с экспертом Otus - Олегом Мельником.

Элемент iframe (сокращение от встроенного фрейма), вероятно, является одним из старейших тегов HTML и был представлен ещё в далеком 1997 году в HTML 4.01 Microsoft Internet Explorer.

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

Чтобы помочь вам сформировать собственное мнение и отточить свои навыки разработчика, мы расскажем обо всем, что вам нужно знать об этом противоречивом теге.

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

Я абсолютно уверен что скоро в telegram - перевод аудио-сообщений в текст будет функцией по-умолчанию, ну а пока хотел бы показать простенький пример как реализовать такой функционал в telegram-боте (которых уже сотни, но почему бы не посмотреть как это работает на примере).

Всем привет, меня зовут Иван, я – разработчик ПО в Orion Innovation. Сейчас много публикаций по фронтенд-разработке, в которых начинающему специалисту легко потеряться и упустить неочевидные вещи.

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

Компьютерный стол у меня появился на два года раньше компьютера, в 2004 году. Это был обычный стол, у которого даже были полки для монитора и клавиатуры. За ним я научился всему, а спустя 17 лет он всё так же стоит у моих родителей.

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

Поделюсь своей историей о том, какой путь прошёл и что нового узнал.

Дано