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

Когда вы начинаете карьеру где бы то ни было, вы, вероятно, надеетесь на многое, но не знаете, чего ожидать. Стоит ли не высовываться и делать, что сказано или нацелиться только на амбициозные проекты? Вот чему я научился за время работы как разработчик ПО.



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

Рассказывая людям на встречах и презентациях про технологию, относящуюся к области баз данных, я поражаюсь, какая огромная пропасть может быть между тем, чем человек занимается и в какой области он работает. Еще больше поражает, что такая пропасть может присутствовать и у технических специалистов. Я попробую пояснить – например, в карточке человека написано «Специалист по работе с базами данных», а на деле оказывается, что этот человек умеет настраивать бэкапы в RMAN-е, создавать индексы и перестартовывать инстансы. Все его знания в области баз данных умещаются в знание, как использовать эти три инструмента. Ах да, еще, конечно же, знание SGA. Поразительно, но возникает такое чувство, что человек определил себе рамки, в границах которых он что-то знает, а что происходит за этими рамками, ему кажется неинтересным и недостойным внимания.

В Штатах зарегистрировано около 6 миллионов мелких компаний, каждая в среднем продает на 1,6 миллиона долларов в год. Крупных компаний — всего 11 тысяч, а средний объем продаж каждой из них — 2,7 миллиарда долларов в год. Очевидно, что продавать крупным компаниям явно выгодней. Но как найти к ним подход?



Мы в Alconost продолжаем перевод статьи Тима Нгуена как раз об этом (начало читайте здесь). В свое время Нгуен начинал с истоков, будучи одним-единственным менеджером по продажам в стартапе. Он нанимал и руководил начальниками «продажного» отдела, а продажи контролировал с помощью одних лишь месячных отчетов. Теперь же, будучи гендиректором и сооснователем собственной компании, он делится накопленным опытом и рассказывает, как можно применить его в отношении вашего бизнеса.

Скорее всего, если вы зашли на Хабр и читаете эту статью, то хоть раз в жизни да слышали про MOOC-курсы.

Но если все же не слышали, то MOOC (по-русски принято произносить «мук») означает «Massive Open Online Course» — массовый открытый онлайн-курс. Это настоящий феномен в образовании XXI века. Газета «New York Times» назвала даже 2012 год «годом MOOC» в связи с появлением на рынке дистанционного образования 3-х «китов» — Coursera, Udacity и EdX. MOOC-ам посвящено множество статей, кто-то видит в них будущее образования, кто-то, наоборот, угрозу. Пытаются также предсказать «традиционную» и «дистанционную» составляющии обучения будущего.




Однако в этой статье я не буду обсуждать перспективы развития дистанционного образования, а расскажу про свой опыт знакомства с курсами на платформе Coursera. Эти курсы будут полезны студентам, изучающим прикладную математику и информатику, в особенности анализ данных. Многое из того, что мне дали эти курсы, как я потом понял — это знания, которыми должен обладать любой уважающий себя исследователь данных (так я предпочитаю переводить профессию Data Scientist).

После ответов на 14 вопросов об индексах, которые вы стеснялись задать, у меня возникло гораздо больше комментариев, уточнений и исправлений. Скомпилировать из всего этого статью выглядело затеей с минимумом пользы. И это заставило меня призадумался, а почему вообще мы должны «стесняться задавать» подобные вопросы? Стыдно не знать? А есть ли способ разобраться, не вгоняя себя в краску? Есть. Причем он избавит от многочисленных неточностей, которыми изобилуют многие «ответы». Вы будете чувствовать буквально каждый байт вашей базы кончиками своих пальцев.

Для этого, я предлагаю «поднять капот» у SQL Server и окунуться в сладостный мир шестнадцатеричных дампов. Может статься, что внутри все гораздо проще, чем вам казалось.

Индексы — это первое, что необходимо хорошо понимать в работе SQL Server, но странным образом базовые вопросы не слишком часто задаются на форумах и получают не так уж много ответов.
Роб Шелдон отвечает на эти, вызывающие смущение в профессиональных кругах, вопросы об индексах в SQL Server: одни из них мы просто стесняемся задать, а прежде чем задать другие сначала подумаем дважды.

Введение

Сегодня уже все, кто хоть немного интересуется дата майнингом, наверняка слышали про простую линейную регрессию. Про нее уже писали на хабре, а также подробно рассказывал Эндрю Нг в своем известном курсе машинного обучения. Линейная регрессия является одним из базовых и самых простых методов машинного обучения, однако очень редко упоминаются методы оценки качества построенной модели. В этой статье я постараюсь немного исправить это досадное упущение на примере разбора результатов функции summary.lm() в языке R. При этом я постараюсь предоставить необходимые формулы, таким образом все вычисления можно легко запрограммировать на любом другом языке. Эта статья предназначена для тех, кто слышал о том, что можно строить линейную регрессию, но не сталкивался со статистическими процедурами для оценки ее качества.

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

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

Год назад мне позвонил агент из Лондона — они искали Javascript программистов для Badoo. Смутно помня, что для работы в UK требуется сложная рабочая виза, я сообщил им сразу, что гражданство у меня только российское. Агент сообщил, что это не обязательно беда, и что у Badoo есть несколько квот для людей без права работать в Британии. Позже он правда перезвонил, извинился, и сказал что квоты закончились.

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

• К поиску работы стоит подходить как к игре. Есть правила игры, есть победившие и проигравшие, и всегда можно сыграть другую игру. Не стоит воспринимать весь процесс слишком всерьез.
• Правила поведения в интервью, технические задания и вопросы с большей вероятностью не будут иметь отношения к реальным проектам. Точно также финальное впечатления от тебя командой может не иметь отношения к тому, что ты на самом деле можешь.
• Стоит предельно четко выяснить для себя на какие позиции вам охота попасть. Это сэкономит кучу времени — можно быстро отсеивать все ненужное. Я начинал поиск как фронтенд девелопер, потом очертил круг как фулл-стек девелопер с перспективой выхода на project manager.
• Скайп интервью — ок. Техническое задание на выходные — ок. Слетать в Лондон на первое интервью или первое техническое задание — не ок. Лететь имеет смысл только когда уже все друг другу нравятся, и у обоих сторон есть положительное представление о том, как все может сложиться. Или просто если хочется посмотреть город.

Борис Бабаян о прошлом, настоящем и будущем вычислительной техники

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

Мне удалось побеседовать на эту тему с Борисом Арташесовичем Бабаяном, директором по архитектуре компании «Интел».

Борис Бабаян известен как главный архитектор компьютерных вычислительных систем «Эльбрус-1», «Эльбрус-2» и «Эльбрус-3». Некоторые из его идей использованы в архитектуре Transmeta. В настоящее время Борис возглавляет разработку новой микропроцессорной архитектуры в компании «Интел».

Чтобы совсем покончить с формальностями, перечислю звания, степени и должности Бориса: член-корреспондент РАН, доктор технических наук, профессор, заведующий кафедрой «Микропроцессорные технологии» МФТИ, Intel Fellow, лауреат Государственной и Ленинской премий.

Дальнейшее повествование построено от лица Бабаяна. Мои скупые комментарии оформлены в виде врезок либо ссылок на интернет-страницы.

На нескольких ресурсах в тырнете прочитал что открылся музей техники Apple. Решил сходить. Под катом много фоток снятых на телефон. Очень рекомендую, довольно интересно посмотреть на «эволюцию компьютеров», и еще кажется странным, что в то время (а там много компов 1992-1995 гг.) были такие возможности. Все экспонаты можно трогать руками, большинство работает.



Пестовский переулок, дом 16, строение 1, второй этаж (ст. м. «Таганская», «Марксистская»).
 Работает каждую субботу и воскресенье с 12 до 18 часов. Вход бесплатный.

Профессионалы журналисты:
www.bg.ru/places/10131
www.appleinsider.ru/istoriya-apple/v-moskve-otkrylsya-muzej-apple.html

Музей:
ФБ и ВК

Больше фото на гугл+ plus.google.com/photos/113349912825051902718/albums/5713474632724480833

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

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

Некоторое время назад мне довелось просматривать результаты анкетирования производственного персонала крупного интегратора, где был блок вопросов, касающихся профессионального роста, обучения и сертификации. Если кратко, то основные причины сертифицироваться сотрудники видели в следующем:
1. «Предложенную сертификацию считаю для себя полезной, ввиду того, что компания все оплачивает, решил пройти/заставили»;
2. Надеюсь на повышение ЗП;
3. Надеюсь на карьерный рост;
4. Сертификация — подтверждение моих навыков.

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

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

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

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

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

Очень часто за основу архитектуры приложения берётся дерево. Простой пример: есть страны, в странах — области, в областях — города, в городах — организации, в организациях — работники, товары или что-либо ещё. Использование дерева вполне логично и оправдано. Иерархичность такой системы показывает некая абстрактная таблица. Назовём её object:

CREATE TABLE object (
  id NUMBER(11),
  parent_id NUMBER(11),
  type VARCHAR2(16) NOT NULL,
  name VARCHAR2(255) NOT NULL,
  CONSTRAINT pk_object PRIMARY KEY (id),
  CONSTRAINT fk_object_parent FOREIGN KEY (parent_id) REFERENCES object (id) ON DELETE CASCADE ENABLE
);

Наполним её какими-нибудь данными:

id  |  parent_id  |  type     |  name
------------------------------------------------------
1   |  NULL       |  country  |  Россия
2   |  1          |  region   |  Московская область
3   |  1          |  region   |  Новосибирская область
4   |  2          |  city     |  Москва
5   |  3          |  city     |  Новосибирск

При этом мы можем легко одним запросом получать нужные нам связи:

-- Выбрать все города России
SELECT *
  FROM object
    WHERE type = 'city'
    START WITH id = 1 CONNECT BY PRIOR id = parent_id;

-- Выбрать страну, в которой находится Новосибирск
SELECT *
  FROM object
    WHERE type = 'country'
    START WITH id = 5 CONNECT BY PRIOR parent_id = id;

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

В данном топике хотелось бы поговорить о повышении производительности при работе с таблицами.

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

Как правило, это происходит из-за плохо спроектированной схемы – изначально не рассчитанной на оперирование большими объемами данных.

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

О переводе

Это перевод 22-ой главы книги «The Passionate Programmer: Creating a Remarkable Career in Software Development». Её автор — Chad Fowler — талантливый Ruby-разработчик, известный докладчик на конференциях, посвящённых Ruby и IT в целом. Бывший саксофонист, а сейчас — CTO 6Wunderkinder.

22. Помни, на кого работаешь

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

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

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

Жизнь — игра, в которую играют буквально все. Эта статья — ваше руководство.

Основы

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

Использование хранимых функций СУБД для реализации бизнес-логики или её части, всегда было камнем преткновения. С одной стороны баррикад DBA и программисты БД, с другой — разработчики backend.
Рискну навлечь на себя гнев из обоих лагерей, но всё же просуммирую плюсы и минусы и изложу свои соображения о том, когда стоит писать код в хранимых функциях, а когда следует выносить наружу.