Перед каждым сервисом, генерирующим хотя бы 1 Мбит/сек трафика в интернете возникает вопрос: «Как? по TCP или по UDP?» В прикладных областях, в том числе и платформах доставки уже сложились предпочтения и традиции принятия подобных решений.

По идее, если бы, к примеру, однажды один ленивый разработчик не попробовал развернуть свой ML на Python (потому что только его и знал), мир скорее всего никогда не проникся бы такой любовью к презренному «супер-джава-кодерами» языку. А сегодня слабости этого языка в прошлом контексте применения безоговорочно обеспечивают ему первенство в развертывании и запуске многочисленных майнерских А/Б.

Сравнивать можно многое: ARM с Intel, iOS и Android, а Mortal Kombat с Injustice. И нарваться на космический холивар, поэтому вернемся к теме доставки огромных объемов разноформатного контента.

Десять лет назад все были абсолютно уверены, UDP — это что-то про негарантированную доставку. Если нужен надежный протокол — это TCP. И вопреки традициям в этой статье мы будем сравнивать такие, кажущиеся несравнимыми вещи, как TCP и UDP.


Осторожно, под катом 99 иллюстраций и схем и все важные.

Дорогие пользователи R! Позвольте поделиться с вами своим справочником для языка, выполненном в канонах windows help. Основной целью его создания была нехватка удобного (по крайней мере для моей жены) reference manual'а. «Удобного» сугубо лично, так как очень хотелось уже по первым трем буквам заголовка находить нужную страницу справочника вместо того, чтобы воевать с Гуглом, который часто не обращает внимание на однобуквенное слово R. Также было неудобно как работать с pdf-мануалом, так и с деревом ссылок справочника. Например, было лень лезть по этому дереву на манер LandingPage->Packages->base package->source. Ну и зачем держать в секрете то, что оболочка моего мануала далеко не нова, изначально делалась под PHP+MySQL и упростила работу многим людям.

Основные преимущества справочника http://r.pohape.ru под катом.

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

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

Эта жизнь для меня осталась в прошлом. Теперь я строю Madrobots. К счастью (или к сожалению, это как посмотреть), приходится не только фантазировать, но и реализовывать свои идеи на практике.

Недавно я рассказывал, что мы открываем новую розничную точку продаж в молле «Мега Белая Дача». 16 декабря мы выложили пост о драматическом процессе открывания магазина и какие сложности (в первую очередь технические) нас ждали на этом пути.
С самого начала было понятно, что мы идем на рискованный эксперимент. И теперь я должен признать: эксперимент провалился. Мы открылись в конце августа. В течение следующего месяца я убедился, что «островок» нерентабелен и его надо закрывать.

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

Министр труда Российской Федерации утвердил профессиональный стандарт Менеджера продуктов в области информационных технологий, который в 2013-м году разработала рабочая группа по созданию профстандарта, сообщил Денис Бесков на сайте Школы управления продуктами.

Стандарт может стать основой для разработки:

• Должностных инструкций;
• Текстов вакансий;
• Корпоративных профилей компетенций;
• Планов профессионального развития;
• Сертификационных программ и тестов;
• Коммерческих учебных программ;
• Федеральных образовательных программ.

С текстом стандарта можно ознакомиться по ссылке (*.pdf).

Тем, кто работает с телефонией, приложениями связанных со звонками и т.п. время от времени приходится сталкиваться с вопросами: «а можно определять с какого региона этот звонок?» и «а этот номер какого мобильного оператора?»

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

Но ведь можно автоматизировать этот поиск? Конечно. И многие аккуратно парсят этот CSV и складывают к себе в базу данных. А затем используют. Я тоже так делаю.

Но недавно с моим коллегой мы решили немного это упаковать и сделать npm для быстрого подключения ресурса нумерации к проекту на node.js.

Ссылка на гитхаб, ссылка на npm.

Далее немного деталей.

Друзья, под закат уходящего 2014 года и начала 2015 есть отличная новость для всех кто любит работать с открытыми данными, участвовать в конкурсах для разработчиков.

А также, я уверен, что есть и те кто любит историю и исторические данные.

С 23 декабря Минфин России с нашей помощью Информационной культуры открывает конкурс приложений BudgetApps http://budgetapps.ru/contest на открытых данных которые Минфин России публиковал последние несколько лет.



Данные самые разные. Это данные о бюджетах, данные об аудиторских организациях, государственном долге, государственных резервах и многое другое.

Ну и, так оказалось, что меня зовут Иван Бегтин и я член жюри этого конкурса.

Все они есть по ссылке на сайте Минфина — http://minfin.ru/ru/opendata/
И много бюджетных данных есть на Едином портале бюджетной системы — http://budget.gov.ru/data/opendata там есть структура бюджета в CSV формате, сами данные, справочники и многое и многое другое. А также данные по всем официальным учреждениям вот тут http://bus.gov.ru/public/opendata.html. На этот ресурс обратите особое внимание. Там опубликованы индикаторы, бюджеты, уставы и многое другое по каждой государственной организации и муниципальном учреждении в России. Если Вы задумаете любой региональный проект, то эти данные будут просто бесценны.

Это не значит, что нельзя использовать какие-либо другие данные, безусловно можно и нужно, однако поскольку это конкурс Минфина России, то конечно ожидается что другие данные будут использоваться вместе с этими.

Я лично считаю, что не стоит ограничиваться только теми данными которые уже переведены в машиночитаемый вид. Есть также данные которые можно превратить в открытые данные самостоятельно.
Многие умеют писать парсеры, но для тех кто этого не делал раньше, хорошее подпорье может быть ScraperWiki (https://scraperwiki.com/) чтобы собрать информацию со страниц, а также разные библиотеки для разбора Excel файлов, извлечение таблиц из PDF документов — с помощью pdftables.com или сервисов Abbyy или их Abbyy Finereader.

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

Исторические бюджеты

Раз в неделю Яндекс отключает один из своих дата-центров. Мы называем это учениями. Что это такое? Как возникло? Зачем мы это делаем? А не диверсия ли это? Насколько это опасно? На эти вопросы мне регулярно приходится отвечать как внутри, так и снаружи компании. Сегодня я решила прояснить все эти вопросы разом.



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

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

Август — очень популярный месяц для астрономических наблюдений — небо постепенно становится более темным, ночи удлиняются, но ещё не вступает в свои права облачная и дождливая осень, и температура все ещё комфортна для нахождения под открытым небом. Какие астрономические события ждут нас во второй половине года?

Итак, случилось то, чего все так долго ждали — теперь и разработчики будут иметь свой собственный налог на воздух.

По новой инициативе нашего Минкомсвязи ожидается создание специального фонда, куда будут перечисляться до 10% от объема продаж в России лицензий на ПО как российских, так и зарубежных разработчиков. Потратить деньги планируется на повышение зарплат разработчикам, работающим в компаниях, занимающихся созданием продуктов по заказу государства (догнать и перегнать, ага). Но чтобы компания могла получить эти денежные субсидии, нужно всего лишь отдать государству блокирующий пакет акций (25% + 1 акция).

Учил студентов предмету «Тестирование и отладка программного обеспечения» в ИжГТУ. Структуру курса обучения построил на основе классификации видов тестирования.

Всем привет! Меня зовут Артур, я аналитик в отделе анализа данных департамента рекламных технологий Mail.Ru Group. И я попробую рассказать о том, как мы используем кластеризацию в своей работе.

Чего в этой статье не будет: я не буду рассказывать об алгоритмах кластеризации, об анализе качества или сравнении библиотек. Что будет в этой статье: я покажу на примере конкретной задачи, что такое кластеризация (с картинками), как ее делать если данных действительно много (ДЕЙСТВИТЕЛЬНО много) и что получается в результате.

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

В этом году, согласно федеральному закону Российской Федерации от 21 июля 2014 г. N 248-ФЗ, в закон об истечении времени под номером N 107-ФЗ от 3-го июня 2011 года, были внесены некоторые изменения (о самих изменениях немного ниже), в связи с которыми 26 октября 2014 года осуществляется перевод часов и устанавливаются соответствующие часовые зоны и значения времени.

Следовательно, корпорация Microsoft не заставила себя ждать и 23-го сентября этого года выпустила очередной патч, предназначенный для учета текущих изменений в порядке исчисления времени, благодаря которому в операционные системы Windows будут внесены соответствующие правки. Этот патч (под номером KB2998527) можно проинсталлировать практически на все актуальные операционные системы Windows.

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

Начнем мы с

Перевод статьи «Dependency Management in a Large Agile Environment».

Краткий обзор

Департамент разработки Salesforce.com включает в себя более 30 Scrum-команд, совместно работающих над общим кодом в одной и той же ветке системы контроля версий. Статья описывает методы, используемые salesforce.com для масштабирования Scrum-подхода и для управления межкомандными взаимосвязями.

1 Введение

В октябре 2006 года начался грандиозный переход отдела разработки (R&D) salesforce.com от модели водопада к гибким методологиям, основанных на Scrum. На тот момент прошло 10 месяцев с предыдущего мажорного релиза, а дата выпуска нового переносилась уже пять раз. Многих расстраивало, что продукт выпускается редко и с серьёзными опозданиями. Мы не стали дожидаться завершения релиза, реорганизовали существующие команды в Scrum-команды и с помощью процессов Scrum выпустили релиз в феврале 2007 года. С тех пор, используя наш новый гибкий подход, мы выпустили уже пять мажорных релизов (длительностью в 3-4 месяца) нашего набора SaaS приложений и платформы Force.com. Каждый из них состоялся точно в запланированный день.

Во время реорганизации мы следовали рекомендациям Scrum для отдельных команд, но не обращали особого внимания на взаимодействие между командами. Формируя команды, мы стремились минимизировать зависимости между ними, однако код не изменился в одночасье, так что сохранилось немало взаимосвязей. Довольно скоро мы внедрили Scrum-of-Scrum meetings. Эти встречи помогали обсуждать проблемы и состояние дел, но одних только собраний было недостаточно. Работая над последними пятью релизами, мы опробовали и отшлифовали дополнительные подходы, улучшающие взаимодействие команд. Далее в статье мы расскажем о некоторых трудностях с управлением зависимостями и о том, как мы преодолели эти проблемы.

Сразу оговорюсь, это моя личная история IT, история о том, как через 25 лет нашел то, что считал безнадежно потерянным.

Мое знакомство с компьютерами началось в прошлом тысячелетии. Думаю, как и у многих. Первый компьютер – Правец 8д, на Хабре о нем есть статья. В комплекте с ним шел телевизор «Садко» с впаянным в него кустарно сделанным блоком для подключения компьютера…

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

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

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

Разработка программного обеспечения невозможна без контроля качества, а в этом ключевую роль играет процесс тестирования. Надо заметить, что тестирование ‒ это не единственная и тем более не достаточная мера для создания качественного ПО, но совершенно необходимая.



Что такое тестирование? Упрощенно, это процесс проверки того, что программа соответствует всем поставленным требованиям. Еще более упрощенно ‒ тестирование есть поиск ошибок. При этом обычно программа рассматривается как “черный ящик”, и проверка производится многократным запуском с разными исходными данными и в разных условиях.
Мы убеждены, что полноценное тестирование программного продукта в компании может выполнять только обособленное подразделение ‒ собственно, отдел тестирования. Перекладывание функций тестировщиков на разработчиков, бизнес-аналитиков или даже менеджеров ‒ путь неэффективный. В этой статье мы расскажем, как можно построить отдел тестирования.

После прочтения книги Test Driven Development for Embedded C я начал знакомство с миром юнит-тестирования с фреймворка cppUtest. Не в последнюю очередь потому, что в нем свеженаписанный тест регистрируется и запускается самостоятельно. За это приходится платить — использованием C++, динамическим выделением памяти где-то в глубинах фреймворка. Может быть, можно как-то попроще?
Совсем недавно я узнал о минималистичном фреймворке minUnit, который умещается всего в 4 строчки.

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

Пару недель назад у меня и коллег случился маленький праздник: 1000 дней непрерывной работы ЦОДа без простоя сервиса. В смысле — без влияния на оборудование заказчиков, но со штатными и не очень работами по системам.

Ниже я расскажу о том, как я и мои коллеги обслуживают ЦОД повышенной ответственности, и какие бывают подводные камни.

У нас в отделе четыре Scrum-команды. Спринты, таймбоксинг, митинги, демо, Product Owner, заказчик и т.д. С годами сформулировался список основных ценностей:

• командный дух и атмосфера в командах — удобство процессов важнее сложившихся годами правил и привычек;
• автоматизация рутины важнее задавливания массой;
• быстрое принятие решений важнее консилиумов, коллегий, долгих совещаний;
• доверие к людям, возможность учиться (и ошибаться!) важнее централизации управления;
• открытость для всех (от высшего руководства до конкретного участника проекта) и вовлеченность важнее сиюминутной экономии времени и видимости согласия;
• демократия в обсуждении вопросов, но диктатура в претворении решений в жизнь;
• необходимый минимум правил, но требовательность при их исполнении;
• когда все думают одинаково — никто не думает;
• «мужик сказал — мужик сделал», все несут ответственность за свои решения.

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

Никто не забудет работу Стива Балмера в Microsoft: он покинул совет директоров компании, чтобы направить свою энергию на владение баскетбольным клубом L.A. Clippers. Давайте изучим опыт колоритного экс-CEO и попробуем извлечь из этого несколько важных уроков.

Переведено в Alconost



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

Мы частенько смотрим на успешных CEO вроде Стива Джобса или Джека Уэлча, считаем их гениями и подражаем им во всем. Так мы переняли у Уэлча метод принудительного ранжирования, оказавшийся одной из главных причин, по которым Microsoft стал утрачивать свои позиции (прим. переводчика: речь о прак­ти­ке деления всех сотрудников на пять категорий от высшей до низшей, когда 10% или 5% слу­жа­щих обя­за­тель­но по­па­да­ют в ка­те­го­рию с самым низ­ким рейтингом. В Microsoft рей­тинг слу­жил ос­но­ва­ни­ем для про­дви­же­ния по служ­бе и пре­ми­ро­ва­ния. Со­труд­ни­ков низ­ше­го ранга, как пра­ви­ло, со временем уволь­ня­ли, или же они ухо­ди­ли сами).

Учиться на чужих ошибках часто важнее, чем на чужом успехе, ведь это избавляет вас от повторения чужого болезненного опыта. Что ж, давайте поговорим о вещах, которые я понял благодаря Балмеру и которые оживят мои советы будущим топ-менеджерам.