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



Конечно, это был не совсем я, но близко. Дело в том, что давным-давно мне предложили помочь Вымпелкому с блогом. На немного необычных условиях. Первым стало отсутствие всякой официальщины – отсюда и совершенно отрывные посты (за часть из которых в корпоративном сегменте смело оторвали бы руки и не только), и самые актуальные темы (Базовая станция вредная? Ещё как!), и вообще много всего.

Но начну с самого начала. Итак, Хабр тогда был торт — большой и зверски агрессивный, хабов не было, а корпоративные блоги были чем-то вроде раздела «тупиковый отстой». За любую ссылку или рекламу тогда почти банили. Или забивали до -50 за час, например. С корпоративным рылом в такой калашный ряд было никак нельзя.

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

Технари, кстати, оказались совершенно офигенные. Только плевать они хотели на Хабр, по большому счёту. Как и везде.

Вводная

Сразу оговорюсь кому может быть интересна данная публикация. Это начинающие Django + JQuery программисты, интересующиеся векторной графикой в браузере с использованием canvas. Или просто люди, получившие подобное задание.
Итак, находясь в постоянном сканировании рынка труда своего региона, наткнулся на весьма интересную вакансию web-разработчика в достаточно известной местной компании. В описании вакансии было сказано, что нужен python+django разработчик. После отправки резюме получил тестовое задание которое гласило:

От переводчика: некоторые скорее всего уже читали этот титанический труд от Мартина Фаулера и его коллеги Джеймса Льюиса, но я все же решил сделать перевод этой статьи. Тренд микросервисов набирает обороты в мире enterprise разработки, и эта статья является ценнейшим источником знаний, по сути выжимкой существующего опыта работы с ними.

Термин «Microservice Architecture» получил распространение в последние несколько лет как описание способа дизайна приложений в виде набора независимо развертываемых сервисов. В то время как нет точного описания этого архитектурного стиля, существует некий общий набор характеристик: организация сервисов вокруг бизнес-потребностей, автоматическое развертывание, перенос логики от шины сообщений к приемникам (endpoints) и децентрализованный контроль над языками и данными.

За те 6 лет, что я занимаюсь образовательными проектами по управлению людьми, довелось сделать интервью с десятками менеджеров и директоров. У нас были ТОР-менеджеры Лаборатории Касперского, Oracle, EPAM, Global Logic и других компаний — самые разные люди. И я понял, что до сих пор не сделал интервью с тем, с кем давно нужно было сделать — с моим коллегой SlavaPankratov.

А тут как раз и повод подоспел — три года с выхода “Черной книги менеджера” (18+, требуется регистрация), вероятно самой популярной и скандальной книги по менеджменту. Ровно три года назад Слава ее как раз и написал.

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

/ фото Brian Cantoni CC

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

Знакомиться со Adobe Flex мне пришлось в почти боевых условиях. Неожиданно понадобилось писать что-то работающее, пользуясь лишь примерами из Интернета и помощью старших товарищей. Поблизости не было ни одной книги по Flex, да и времени на чтение тоже, что сильно сказалось на теоретической базе. Многое делалось на ощупь простым русским методом проб и ошибок. Чтож, попробовать пришлось порядочно. Сейчас, глядя назад, я понял, что многие грабли можно было избежать, если бы имелась под рукой простая вводная статья объясняющая что к чему. Под катом собраны 3 вопроса, из-за недопонимания которых у меня чаще всего возникали проблемы. Надеюсь, ответы на них помогут начинающим быстрее разобраться в тонкостях построения компонентов этого фреймворка.

В этой статье мы продолжаем наше знакомство со структурой и основными функциональными элементами пакетной сети оператора мобильной связи, которые мы начали в предыдущих двух статьях — GPRS изнутри. Часть 1 и GPRS изнутри. Часть 2. В нашей сегодняшней заметке речь пойдет об основных интерфейсах сетевых элементов PS Core Network, а также стеках проколов, используемых на этих интерфейсах.

В продолжение или в поддержку поста Видео. Пример разработки приложения с помощью TDD. За основу мы взяли задачу — написать крестики-нолики с использованием TDD.

Отличие данного примера:
* больше теории про TDD
* немного отошли от стандартного цикла тест-код-рефакторинг
* пришлось ускорить сессию парного программирования в 5 раз (иначе получится двух часовая запись)
* запись в стерео, поэтому будет разговор в разных ушах

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

Этот пост — ответ на публикацию EldarMurtazin ««Безлимитный» мобильный интернет или это фантастика сынок»

Ни одна революция, в том числе техническая, не происходит без предварительного создания должной инфраструктуры. Зачастую основную роль играет также снятие ограничений в той области, где снимаемые ограничения всеми воспринимаются как де-факто. Примеры — финансирование гиковских исследований в Пало-Альто дало миру мышку, графический оконный интерфейс, Ethernet. Тогда это не было востребовано 99.(9)% пользователей ПК, да неперсональных компьютеров тоже. Хорошие дороги? В Германии их построили для танков, в те времена, когда о массовой автомобилизации никто не думал и 95% населения никогда бы не поддержали подобные траты. Но то – военные расходы, весьма спорная штука.

О чем же этот пост? Об инфраструктуре и людях.

Инфраструктура

Вот прогноз от Cisco по росту мобильного трафика на ближайшую пятилетку.

Дочитал на днях сабжевую книжку. Вышла она еще в 2008 году (а предыдущее издание и того раньше), но мне она попалась только недавно. По идее, читать ее надо было бы после книги Фаулера «Рефакторинг. Улучшение существующего кода», на которую Кириевски постоянно ссылается, но до Фаулера я пока не добрался, хотя это и не особо затруднило чтение. Вторая книга, которую лучше всего прочитать заранее, это «Приемы объектно-ориентированного проектирования. Паттерны проектирования» банды четырех.

Суть книги «Рефакторинг с использованием шаблонов» состоит в том, что в книге автор собрал 27 довольно сложных рефакторингов, большинство которых предназначены для того, чтобы как можно более безболезненно ввести в архитектуру программы паттерны, описываемые в книге банды четырех. Как пишет в начале Кириевски, часто он начинает программировать без использования паттернов до тех пор пока этот участок кода не надо расширять, тогда он принимается за рефакторинг. Правда, в книге есть еще один рефакторинг, который наоборот избавляет код от использования синглтонов (автор называет болезнь, когда используют синглтоны по любому поводу, синглтонизмом и предлагает открыть общество анонимных синглтоников).

После публикации своего первого поста «Почему я люблю Microsoft. Заметки Зомби» я получил достаточно много писем с похожей просьбой — написать подробнее об используемых продуктах.
Просили — получите. При написании статья я поставил себе цель — описать основной маршрут. Расписывать тонкости установки и настройки нет смысла — их достаточно в Интернет. Я старался, чтобы прочитав этот пост администратор знал названия продуктов и технологий, для чего они нужны и потом уже мог ловко нагуглить всё остальное. Для того, чтобы облегчить поиск ключевые названия будут на английском. Если какая-то аббревиатура незнакома — это повод про неё почитать. И, да, я буду описывать решения от Microsoft, так как что-то смыслю только в них. Хочу сразу предупредить что топик очень конспективный.

Ну вот скоро и закончится зима… Настанут теплые весенние денечки, захочется сразу же выбраться на природу, а лучше куда-нибудь съездить отдохнуть… в теплые края… стоп, а что же взять с собой в дорогу — свой верный ноут? Но Я ведь еду отдыхать от работы… а возьму ка я свой надежный коммуникатор…
Думаю, многим знакома такая ситуация, когда уезжая заграницу, брать ноутбук как-то не хочется, а связь с внешним миром/корпоративным офисом поддерживать хочется. Поэтому одним из выходов из этой ситуации является взять коммуникатор, а в качестве выхода в сеть воспользоваться одной из технологий пакетной передачи данных — GPRS/EDGE.

В комментариях к постам про сеть WiMAX (1, 2) и про GPRS был выражен интерес к сетям сотовой связи, поэтому решил реализовать свою давнюю задумку и описать хабрасообществу как же устроены современные сети сотовой связи.



На приведённой картинке изображена общая структура сетей сотовой связи. Изначально сеть разделяется на 2 больших подсети — сеть радиодоступа (RAN — Radio Access Network) и сеть коммутации или опорную сеть (CN — Core Network).

Хочу подчеркнуть, что буду описывать именно существующие сети сотовой связи для СНГ, потому что в Европе, Америке и Азии сети более развиты и их структура несколько отличается от наших сетей, про это напишу как-нибудь позже, если будет интерес.

Сперва, хотелось бы рассказать в общих словах про сеть, а потом более подробно расскажу про функции каждого из элементов сети.

Этим циклом статей я хотел бы рассказать хабраобществу о технологиях пакетной передачи данных в сетях мобильных операторов. Мы рассмотрим принципиальные схемы Packet Switched (PS) Core Network, заглянем в стек протоколов используемых для коммуникации между различными сетевыми элементами, а также более подробно рассмотрим функции основных элементов, которые позволяют нам использовать пакетную передачу в мобильных сетях. Конкретно в этой статье речь пойдет о самых распространенных на данный момент технологиях GPRS/EDGE.

Некоторое время назад по телевидению прошел ряд рекламных роликов с замечательным персонажем:


Персонаж окончательно и бесповоротно влюбил в себя мою жену и для меня окончательно решился вопрос — что дарить ей на день рождения.

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

Помня завет, почерпнутый в детстве в какой-то умной книжке — «настоящий мужчина должен уметь всё», я отложил в сторону клавиатуру и взял в руки иголку с ниткой.

Продолжение истории под катом, осторожно, фотки.

В нескольких топиках меня просили рассказать про нашу команду. А именно – как так получилось, что мы сразу знали, как и что делать в бизнесе, и, казалось, не ошибались. Так вот, мы ни разу не суперлюди. Мы часто ошибаемся, часто ходим по граблям и часто спорим внутри команды.

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

Недавно нашей сети исполнилось 5 лет. Первые два года были просто взрывом: мы стартовали без кредитных средств с одного маленького магазина и как-то вдруг стали российской розничной сетью.

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

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

Итак, давайте вкратце рассмотрим, в каком именно месте находится пересечение контрактов и юнит тестов, и постараемся ответить на вопрос: являются ли постусловия избыточными при наличии юнит тестов?

Всем, доброго времени суток!
Этот топик о том как мы тестируем веб-интерфейс нашего продукта Plus1 WapStart. Мы используем Page Object, т.к. этот паттерн имеет много общего с реальными задачами и позволяет писать автотесты простыми для чтения и понимания.

Что такое Page Object

Page Object — это паттерн для реализации умных автоматических проверок. Gem page-object является имплементацией этого паттерна, который помогает в создании гибких страниц с объектами для тестирования браузерных приложений. Суть в том, чтобы создавать уровни абстракции для отделения тестов от предметов тестирования, и обеспечить простой интерфейс для элементов на странице. Gem работает с watir-webdriver и selenium-webdriver.

Это пятый вебинар из цикла бесплатных вебинаров по автоматизации тестирования.
Видеозапись (продолжительность 1 час 5 мин.):

Темы и детали видеозаписи под катом

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

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

Итак, добро пожаловать в Functional thinking. Эта серия исследует предмет функционального программирования, но не несет исключительной направленности описать функциональные языки. Как я покажу дальше, написание кода в функциональном стиле касается дизайна, компромиссов, разных повторно используемых кусков кода и служит основой для иных догадок. Насколько это окажется возможным, я попытаюсь показать концепции функционального программирования в Java (или близких к Java языках) и перейду к другим языкам, чтобы осветить возможности, отсутствующие на данный момент в Java. Я не полезу сразу в дебри, рассказывая о довольно необычных вещах, таких как монады (monads). Напротив, я постепенно проведу Вас через новый путь мышления.

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