Сейчас все больше говорят о статическом анализе для поиска уязвимостей как необходимом этапе разработки. Однако многие говорят и о проблемах статического анализа. Об этом много говорили на прошлом Positive Hack Days, и по итогам этих дискуссий мы уже писали о том, как устроен статический анализатор. Если вы пробовали какой-нибудь серьезный инструмент, вас могли отпугнуть длинные отчеты с запутанными рекомендациями, сложности настройки инструмента и ложные срабатывания. Так все-таки нужен ли статический анализ?

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

Если вы интересуетесь программированием, то возможно слышали фразу:

«Каждый должен учиться программированию, потому что оно учит думать.»

— Стив Джобс

Наверное вы тоже задавались вопросом, что значит думать как программист?

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

Данный пост ставит целью научить вас этому.

Прочтя его, вы более точно поймете, что нужно делать, чтоб находить лучшие решения.

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

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

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

Да, я тоже бываю дебилом. Но такого я от себя не ожидал. Вроде бы «не первый год замужем». Вроде бы читал кучу умных статей об отказоустойчивости, избыточности и т.п., что-то разумное когда-то написал даже сам тут. Свыше 10 лет являюсь CEO хостинг-провайдера работающего под брэндом ua-hosting.company и предоставляющего услуги хостинга и аренды серверов в Нидерландах, США, а буквально неделю назад и в Великобритании (не спрашивайте, почему название ua, ответ можете найти в нашей автобиографической статье), предоставляем клиентам решения различной степени сложности, иногда такой, что даже сами затрудняемся разобраться в том, что сотворили.

Но блин… Сегодня я превзошёл сам себя. Мы сами себе полностью снесли сайт и биллинг, со всеми транзакциями, данными клиентов об услугах и прочим и в этом виноват был я, я сам сказал «удаляй». Некоторые из Вас уже заметили это. Это случилось сегодня, в пятницу в 11:20 по восточному североамериканскому времени (EST). Причём наш сайт и биллинг размещены были не на одном сервере, и даже не в облаке, мы ушли из облака дата-центра 2 месяца назад в пользу нашего собственного решения. Всё это размещалось на отказоустойчивом гео-кластере из двух виртуальных серверов — нашего нового продукта, VPS (KVM) c выделенными накопителями, НЕЗАВИСИМЫХ VPS, которые располагались на двух континентах — в Европе и в США. Один в Амстердаме, а другой в Манассасе, под Вашингтоном, тем, что D.C. В двух надёжнейших дата-центрах. Контент на которых постоянно и в реальном времени дублировался, а отказоустойчивость основана на обычном кластере DNS, запросы могли приходить на любой из серверов, любой выполнял роль MASTER, и в случае недоступности брал на себя задачи второго.

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

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

Я занимаюсь программированием уже 15 лет. Но в последнее время при разработке не принято думать об эффективности, простоте и совершенстве: вплоть до того, что мне становится грустно за свою карьеру и за IT-отрасль в целом.

Для примера, современные автомобили работают, скажем, на 98% от того, что физически позволяет нынешняя конструкция двигателя. Современная архитектура использует точно рассчитанное количество материала, чтобы выполнять свою функцию и оставаться в безопасности в данных условиях. Все самолёты сошлись к оптимальному размеру/форме/нагрузке и в основном выглядят одинаково.

Только в программном обеспечении считается нормальным, если программа работает на уровне 1% или даже 0,01% от возможной производительности. Ни у кого вроде нет возражений.

31 августа Яндекс заменил ставший привычным тИЦ (тематический индекс цитирования) на непонятный ИКС — индекс качества сайта.

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

Что нам остается делать? Правильно, провести исследование и докопаться до истины!

Исследование проводилось на основе данных о 705 крупнейших форумах Рунета, Уанета и Байнета. Сведения о форумах были получены из рейтинга форумов ForumRate.ru.

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

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

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

Перевод статьи: Experimenters Rules of Thumb

Владельцы веб-порталов, от самых маленьких, до таких крупных, как Amazon, Facebook, Google, LinkedIn, Microsoft и Yahoo, пытаются улучшить свой сайты, оптимизируя различные метрики, начиная с количества повторных использований до проведенного у них времени и выручки. Нас привлекали к проведению тысячи экспериментов на Amazon, Booking.com, LinkedIn и Microsoft, и хотим поделиться семью эмпирическими правилами, которые мы вывели из этих экспериментов и их результатов. Мы верим, что эти правила широко применимы как при оптимизации веба, так и в ходе анализа за пределами контрольных экспериментов. Хотя бывают исключения.

Чтобы сделать эти правила более весомыми, мы приведём реальные примеры из нашей работы, причем большинство из них будут опубликованы впервые. Некоторые правила озвучивались и ранее (например, «Скорость имеет значение»), но мы дополнили их допущениями, которые можно использовать при проектировании экспериментов, и делимся дополнительными примерами, которые улучшили наше понимание того, где скорость особенно важна, а в каких областях веб-страниц она не критична.

Эта статья преследует две цели.

Первая: научить экспериментаторов правилам хорошего тона, которые помогут оптимизировать сайты.

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

Про обновление систем «на лету» без их остановки (zero-downtime deployment) написано немало статей и многие аспекты этого подхода является достаточно очевидными. На мой взгляд, наиболее сложная часть деплоймента в этом случае — обновление хранилищ данных, в случае если их контракт (схема) изменился. Именно этот аспект я бы и хотел рассмотреть в этой статье.

Виктор Гюго; фотографию сделал Этьен Карьят в 1876

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

Но вместо работы над книгой, весь год Гюго занимался другими проектами, развлекал гостей, и откладывал работу с текстом. Его издатель всё больше раздражался из-за продолжавшейся прокрастинации автора, и среагировал, установив пугающий крайний срок для сдачи книги. Он потребовал, чтобы Гюго закончил книгу к февралю 1831 – то есть, менее, чем за шесть месяцев.

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

Ad Exchange в рамках Real-Time Bidding (RTB) — одно из AdTech-решений, видоизменяющих рынок онлайн-рекламы. Его основная функция — стыковка большого количества SSP и DSP, которые не имеют прямой интеграции между собой, а также перепродажа разнообразного рекламного трафика между ними.

Благодаря заказу для рынка США мы с головой погрузились в специфику построения платформы Ad Exchange. И в этой статье представляем некоторые идеи и результаты.

Привет Хабр!

Недавно мне попалась на глаза статья про Service Now. В ней описывалось про то, какой же хороший у них продукт. Даже показали менеджера среднего звена с микрофоном, которая без цифр что-то говорила (из статьи — "сократило время административного труда, и врачи смогли сфокусироваться на своём основном предназначении").

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

После статьи я попытался осознать — а как можно по подобным рекламным презентациям оценить, продукт действительно пользователям, или же он только помог менеджерам среднего звена получить очередной бонус?

Продолжаю знакомить читателей Хабра с главами из своей книжки «Теория счастья» с подзаголовком «Математические основы законов подлости». Это ещё не изданная научно-популярная книжка, очень неформально рассказывающая о том, как математика позволяет с новой степенью осознанности взглянуть на мир и жизнь людей. Она для тех кому интересна наука и для тех, кому интересна жизнь. А поскольку жизнь наша сложна и, по большому счёту, непредсказуема, упор в книжке делается, в основном, на теорию вероятностей и математическую статистику. Здесь не доказываются теоремы и не даются основы науки, это ни в коем случае не учебник, а то, что называется recreational science. Но именно такой почти игровой подход позволяет развить интуицию, скрасить яркими примерами лекции для студентов и, наконец, объяснить нематематикам и нашим детям, что же такого интересного мы нашли в своей сухой науке.





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

Развиваться, узнавать о технологиях и быть в курсе последних подходов – для ITшника особенно важно. Читать книгу не всегда удобно, смотреть видео-обзоры любят не все и времени много занимает.

Держите 50 IT-подкастов о технологических новинках в сфере ИБ, облачных технологий, IoT, тестирования и управления проектами. Все подкасты на английском языке, для прослушивания нужно знать его на уровне upper intermediate и выше.

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

7 апреля мы впервые собрали PHP-сообщество в офисе Badoo. Спасибо всем, кто пришел пообщаться, и тем, кто был с нами онлайн!

Похоже, пэхэпэшники изголодались по митапам. Встреча получилась ну очень душевной — разговоры за жизнь и PHP из afterpaty переместились в afterchat, который до сих пор активен (несмотря ни на что).

Но вернемся к нашим докладам. Под катом — записи выступлений, слайды, комментарии гостей и фотоотчет.