Если вы работаете в IT-компании, то, скорее всего, ваши процессы построены вокруг известного продукта Atlassian — Jira. На рынке есть множество таск-трекеров для решения тех же задач, в том числе open-source-решения (Trac, Redmine, Bugzilla), но, пожалуй, именно Jira имеет сегодня самое широкое распространение.

Меня зовут Дмитрий Семенихин, я тимлид в компании Badoo. В небольшом цикле статей я расскажу, как именно мы используем Jira, как настраивали её под свои процессы, что хорошего «прикрутили» сверху и как тем самым превратили issue-трекер в единый центр коммуникаций по задаче и упростили себе жизнь. В этой статье вы увидите наш флоу изнутри, узнаете, как можно «докрутить» свою Jira, и прочтёте о дополнительных возможностях инструмента, о которых могли не знать.

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

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

Надеюсь, что описанный ниже опыт станет для кого-то чужими граблями, а в комментариях я и сам почерпну что-то от более опытных коллег.

В последние несколько лет мои переживания по поводу российского рынка ИТ только усиливались. Все началось с кризиса рубля 2014 года (а может, и раньше), и с тех пор меня не покидает ощущение, что многие российские компании, особенно провинциальные, завязали себе глаза, заткнули ватой уши и все еще пытаются сделать вид, что ничего не происходит. Я много общался с разными компаниями, с HR, с разработчиками, и составил список неутешительных тезисов о том, что представляет собой как программистский рынок, так и культура разработки в целом, ведь это вещи взаимосвязанные. По моим субъективным оценкам, эти тезисы справедливы для ~60% российских компаний, хотя, казалось бы, те другие 40% компаний, которые мы знаем и любим, должны были заставить задуматься. Но я очень подозреваю, что это эти 60% просто надеются на русский “авось”, и подвергаются так называемой willful blindness, а иногда и намеренно мутят воду. Итак, по-честному, что же происходит?

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

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

В этой статье я расскажу, как реализовать кроссплатформенное приложение на .NET Core и Avalonia. Тема Телеграма очень популярна в последнее время — тем интереснее будет сделать клиентское приложение для него.

Статья затрагивает достаточно базовые концепции разработки на Avalonia. Тем не менее, мы не будем писать "Hello, World". Вместо этого предлагается рассмотреть реальное приложение. Изучим как общую архитектуру приложения, так и отдельные компоненты.

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

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

Чатботы и искусственный интеллект для понимания естественного языка (NLU – Natural Language Understanding) тема достаточно горячая, про нее не раз говорилось на Хабре. Тем не менее достаточно редко попадаются верхнеуровневые и структурированные обзоры этих технологий и рынка в целом. В своей статье мы попробуем немного разобраться, чем обусловлен спрос на эти технологии, как выглядит современная диалоговая платформа для NLU, какие компании и разработки присутствуют на этом рынке.

Эта статья о том, как написать универсальный JavaScript-компонент, который можно будет использовать

• как React-компонент;
• как Preact-компонент;
• как Angular-компонент;
• как Web Component;
• как jQuery функцию для рендеринга в DOMElement;
• как нативную функцию для рендеринга в DOMElement.

Зачем и кому это нужно

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

Введение

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

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

Терминология

К сожалению, в тестировании пока не выработали общую терминологию. Если спросить сотню разработчиков, в чём разница между интеграционным, сквозным и компонентным тестом, то получите сто разных ответов. Для этой статьи ограничимся такой пирамидой тестов:


Если не видели пирамиду тестов, настоятельно рекомендую ознакомиться с ней. Вот некоторые хорошие статьи для начала:

• «Забытый слой пирамиды автоматических тестов» (Майк Кон, 2009)
• «Пирамида тестов» (Мартин Фаулер, 2012)
• «Блог отдела тестирования Google» (Google, 2015)
• «Пирамида тестов на практике» (Хэм Фокке, 2018)

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



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

Не хотите читать? Посмотрите демо.

Символы нулевой ширины — это непечатаемые управляющие символы, которые не отображаются большинством приложений. Н​апример, в э​то пред​ложение я вст​авил де​сять про​​белов н​улевой ширины, вы эт​о замет​или? (Подсказка: вставьте предложение в Diff Checker, чтобы увидеть местоположение символов!). Эти символы можно использовать как уникальные «отпечатки» текста для идентификации пользователей.


Безусловно, он может здесь быть. И вы никогда не догадаетесь

Зачем?

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

Меня зовут Грифтер, рядом мой хороший друг Метакортекс, мы из группы DC801, которая базируется в Солт-Лейк-Сити, штат Юта. Мы хотим показать нечто, выглядящее довольно забавным и провести для Вас экскурсионный тур по тёмной стороне Интернет.



Мы оба исследователи, которым нравится бродить по тёмным переулкам, например, в Токио, я даже не знаю, где именно это происходило.

Большое спасибо за то, что пришли меня послушать! То, о чём я буду говорить, отличается от выступлений предыдущих спикеров. Сначала я хочу поблагодарить людей, которые помогали мне в подготовке этого выступления. Некоторые из них смогли тут присутствовать, некоторые нет. Это Алан Митчел, Рон МакГайер, Крис Тейлор и Кэти Херитадж и ещё несколько человек, которые захотели сохранить анонимность, поэтому их имена напечатаны на этой картинке чёрным цветом.



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



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



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

Я стал искать варианты адекватного ответа. Может быть, это?

При работе с Entity Framework, как и с любым другими ORM, часто возникают вопросы, связанные с его производительностью. Многие разработчики из-за незнания нюансов делают ошибки, приводящие к плохим результатам. Затем, во время анализа проблем и поиска решений, недостаточно разобравшись в вопросе, приходят к выводу, что улучшить ситуацию можно только переходом на другой ORM или отказом от него вообще. Хоть в некоторых ситуациях такое решение может оказаться разумным, зачастую не все так плохо — просто нужно знать нюансы. В этой статье я попытался собрать те подводные камни, с которыми мне чаще всего приходилось сталкиваться на практике.

Перед тем, как рассказать о нашем проекте, я хочу рассказать Вам, кто такой я, Грант Джордан, и кто такой Кайл Вогт (Kyle Vogt), который работает на Justin.tv. Мы студенты Массачусетского Технологического института, у которых много свободного времени. И у нас есть множество интересных проектов, как например, устройство для взлома сейфов, которое позволяет открывать сейфы с наивысшей степенью защиты. Однако понять, почему мы занялись именно спамом, поможет ответ на вопрос: кем мы не являемся?

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

Каждый раз, открывая Вашу почту, Вы находите там спам. Это советы, как увеличить размер пениса, или письма от «плохих» девочек из России, или уведомление, в котором бывший принц Нигерии сообщает, что сделал Вас наследником своих миллионов. Однако один вид спама привлекал внимание больше других – это был спам о фондовом рынке. Это были странные «подсказки», призывающие купить определённые акции, курс которых вот-вот подскочит «выше крыши». Как и большинство людей, я удалял этот спам, но однажды Кайл родил одну из самых глупых идей, которые я когда-либо встречал: «Должен же быть способ, который поможет нам отобрать часть денег этих самых спамеров»!

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

Одна из распространённых ошибок — попытка работодателя отфильтровать кандидатов по профилям GitHub. Многие по-прежнему думают, что можно оценить способности разработчика, взглянув на его вклад в проекты с открытым исходным кодом. Например, в последнем списке вакансий на Hacker News куча объявлений с просьбой указать профиль GitHub в своём заявлении о приёме на работу.

Есть несколько правильных статей, почему нельзя требовать от кандидатов профили GitHub. Особенно рекомендую «Этика неоплачиваемого труда и сообщество Open Source» и «Почему GitHub — не резюме». Обе статьи отлично объясняют причины, почему при найме не следует спрашивать о вкладе в свободные проекты. Но я не о том, что это неэтично или что GitHub не слишком подходит для демонстрации проектов.

Я о том, почему эти профили просто малополезны.

Разреженность данных

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

По встроенным механизмам безопасности ASP .NET Core написано мало статей. Даже официальная документация имеет пробелы. В этой статье мы пройдём по всем основным компонентам, имеющим отношение к безопасности, и разберём, как это работает внутри.

Если вы используете старый добрый ASP .NET, то для вас будет полезна информация по внутреннему устройству компонентов безопасности и лучшим практикам их использования. Здесь вы найдёте ответы на следующие вопросы: как реализованы современные анти-XSS механизмы и как их правильно использовать в ASP .NET Core? Как правильно работать с cookies и какие подводные камни там могут встретиться? Как был переписан механизм защиты от CSRF? Как правильно работать с криптографическими алгоритмами? Кроме того, рассказывается про опыт участия в Bug Bounty по поиску уязвимостей в ASP .NET Core.

Перед чтением рекомендуется освежить в памяти атаки из списка OWASP Top 10.

Прототипом статьи является доклад Михаила Щербакова на конференции DotNext 2017 Moscow. Михаил — Microsoft .NET MVP, участник .NET Core Bug Bounty Program, соорганизатор сообщества .NET программистов (Московское комьюнити называется MskDotNet, питерское — SpbDotNet). По работе последние 5 лет занимается безопасностью. Работал в Positive Technologies, в Cezurity, сейчас как консультант работает напрямую с заказчиками, по большей части в этой же сфере. Профессиональные интересы: статический и динамический анализ кода, информационная безопасность, автоматизация отладки кода, исследование внутреннего устройства .NET CLR.

В этом тексте огромное количество картинок со слайдов. Осторожно, трафик!

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

На днях в обычном офисном разговоре я сказал: «То, что у нас тут склад костылей — это нормально, во всех ИТ-проектах так. Наверное, из всего софта, который сделало человечество, только в программах посадки на Луну было все красиво». Сказав это, я полез в интернет, найти дополнительные факты к краткому научно-популярному рассказу для коллег о компьютерах и программах лунного модуля. Но одной из первых попалась ссылка, из которой выяснилось, что костыли, и, страшно сказать, баги были и в отшлифованном программном обеспечении, которое позволило человеку высадиться на Луну. А «Аполлоны» -11 и -12 смогли сесть, оказывается, только по счастливой случайности.

Репозиторий является посредником между слоем доступа к данным и доменным слоем,
работая как in-memory коллекция доменных обектов. Клиенты создают декларативные
описания запросов и передают их в репозиторий для выполнения.
  — свободный перевод Мартина Фаулера

EntityFraemwork предоставляет нам готовую реализацию паттернов Repository: DbSet<T> и UnitOfWork: DbContext. Но мне часто приходится видеть, как коллеги используют в своих проектах собственную реализацию репозиториев поверх существующих в EntityFraemwork.

Чаще всего используется один из двух подходов:

1. Generic Repository как попытка абстрагироваться от конкретного ORM.
2. Repository как набор запросов к выбранной таблице БД (паттерн DAO).

И каждый из этих подходов содержит недостатки.

Здравствуй уважаемый %habrauser%. В данной статье я поделюсь с вами историей о том как я взломал приложение. Взломать сам EXE-шник приложения не получилось, но желаемый результат был получен другим способом. Чтобы сохранить конфиденциальность буду опускать некоторые моменты, сильно обрезать скрины. И так

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

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

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

Внимание: не пытайтесь повторять действия, описанные в публикации и им подобные. Помните о ст. 272 УК РФ «Неправомерный доступ к компьютерной информации».