Как же все-таки работает HTTPS? Это вопрос, над которым я бился несколько дней в своем рабочем проекте.

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

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

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

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

Если когда-нибудь вы задумывались над тем, что значат слова «the processor supports precise aborts» в даташите, прошу под кат.

Один из наиболее универсальных советов, которые мы даем в Y Combinator, это браться за сложную работу. Многие начинающие основатели верят, что стартапы или «взлетают» или нет. Вы создаете что-то, делаете это доступным, и, если вы придумали самую лучшую мышеловку, люди, как и было обещано, сами придут к вам. Или не придут, в таком случае у вас нет рынка. [1]

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

Привлечение клиентов

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

Когда говорят про разработку игр, обычно речь идет о шейдерах, графике, AI и т.д. Крайне редко затрагивается серверная часть игровых проектов, а ещё реже — базы данных. Исправим это досадное недоразумение: сегодня я расскажу о нашем опыте работы с базами данных, который мы приобрели в ходе разработки Аллодов Онлайн и нашего нового проекта Skyforge. Обе эти игры — клиентские MMORPG. В первой зарегистрировано несколько миллионов игроков. Вторая разрабатывается студией в строжайшей секретности в недрах Allods Team.

Меня зовут Андрей Фролов. Я ведущий программист Allods Team и работаю в команде сервера. Мой опыт разработки — почти 10 лет, но в игры я попал только в октябре 2009. В коллективе я уже больше трёх лет, с марта 2010. Начинал работу на Аллодах Онлайн, а сейчас на Skyforge. Занимаюсь всем, что так или иначе связано с сервером Skyforge и базами данных. В этой статье я расскажу о базах данных в онлайн-играх на примере Аллодов и Skyforge.

31 июля в Санкт-Петербурге мы, портал Айти-Событие.рф, совместно с компанией EMC Corporation проводим Первую IT-мастерскую на базе Факультета переподготовки специалистов СПБГПУ (ФПС СПБГПУ).

Уже давным-давно, казалось-бы, в прошлую пятницу, но на самом деле 6 июля 2013 года в 13:00 по Москве (10:00 по Гринвичу) состоялась вторая online конференция ruHaxe.
(отчёт о первой конференции)

Группа сообщников, при содействии интернета, ютуба, скайпа и просто здравого смысла пообщались в онлайне и послушали интересные доклады интересных людей про haxe, maven, GUI, Unity3d, ну и т.д. и т.п.

Всем привет!
Сайты Alawar — это сайты для русского, американского, европейских и других рынков, отдельные сайты для mobile-устройств, сайты партнерских программ и др. Все они развернуты на одном инстансе Yii, о чем мы уже писали в нашем блоге на хабре.
Сегодня я расскажу, как мы организовали хранение, структуру и управление конфигами наших сайтов, какие при этом получили преимущества. А также поведаю, как осуществляется деплой нашего проекта в различных окружениях.

Лирика

В ответ на пост «Написание диссертации, связанной с it: ожидания и российская действительность».
Заранее прошу прощения, но для размещения этого поста в хабе «Учебный процесс в ИТ» у меня, как выяснилось, не хватает кармы. Условно будем считать диссертацию большим проектом, а мой пост неким алгоритмом ее написания.

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

По наблюдениям, на сегодняшний момент я вижу только 2 объяснения поступления в аспирантуру лицами мужского пола: 1. Что-то во время учебы накопал интересное -> участник студконференций -> диплом с отличием (или рядом) -> аспирантура. 2. Просто учился нормально -> нежелание после универа идти в ВС РФ -> аспирантура (из 10 успешно защищаются 1-2, остальные болеют). Бывает и 3 категория…залетная.

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

Как я докатился до этого

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

По личным причинам после окончания ВУЗа остался в том же городе, тут же в России на пару-тройку лет (хотя настроение «поравалительное»). Изначально аспирантура не планировалась, но за пару месяцев до диплома я понял, что этого времени достаточно для чего-то более существенного, чем 3 года просто работы системным администратором. Решил пустить усилия в русло науки.

Разрабатывая мобильное приложение, я обнаружил пару вещей, знания о которых мне бы пригодились, когда я начинал. Поэтому я решил написать статью в формате небольших советов. Эти советы больше нацелены на разработку мобильных приложений под PhoneGap, Windows 8 и Firefox OS. Но разработчикам мобильных веб-сайтов тоже могут пригодиться. В конце статьи дам ссылки на то, что в конце концов получилось

На этой неделе мы выкладывали первую часть расшифрованного подкаста. Сейчас подготовили вторую часть.

О чем мы говорим во второй части подкаста:

• Горизонтальное масштабирование проекта

— когда стоит использовать облачные сервисы, а когда физический хостинг;
— «красивость решения» против «грязного, но производительного» кода. ORM и всякие подобные штуки;
— мультиязычность и мультизонность проекта, проблемы и решения.

• Асинхронные задачи. Очереди.

— асинхронные задачи в распределенных системах;
— когда они приходят на помощь, какие технологии существуют и активно развиваются сейчас;
— какие подходы организации асинхронных задач используются в Badoo;
— c какими проблемами приходилось и приходится сталкиваться при работе с очередями;
— полезные книги и интересные конференции;
— интересные кейсы с собеседований.

Шесть месяцев назад ребром встал вопрос о тексте для моего дипломного перевода. Результатом помощи коллективного разума стало решение переводить главу Scalable Web Architecture and Distributed Systems за авторством Kate Matsudaira. Нужно отметить, что это мой первый перевод такого объема и сложности. Текст, был мною относительно успешно переведен, хотя по качеству перевода я поставил бы себе 6-7 из 10. Дабы мои усилия не пропали втуне, публикую результат своих трудов.

По просьбам читателей Хабра, теперь полная версия в виде топика.

Масштабируемая веб-архитектура и распределенные системы

Кейт Матсудейра

Перевод: jedi-to-be.
Коррекция: Anastasiaf15, sunshine_lass, Amaliya, fireball, Goudron.

Бенчмарк Valley

Это вторая и заключительная часть статьи, посвященной процедурным методам производства контента для 3D приложений. Первую часть Вы можете найти здесь.

В этой части, так же как и в предыдущей, приводятся ссылки на скачивание созданных нами исходных материалов, которые можно свободно использовать (с изменениями или без) в своих проектах, но только не продавать/распространять в чистом виде и/или в составе каких-либо библиотек.

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

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

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

1. Звонки из любой точки мира по местным тарифам
2. Прием звонков на свой личный номер
3. Голосовые сообщения если я не доступен
4. Голосовая почта
5. Прием и передача смс
6. Безопасность соединения

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

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

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

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

Я буду приводить влияние разных факторов в порядке их важности и силы влияния. Чем выше — тем сложнее это изменить и тем больший эффект это оказывает.

Некоторое время назад зам.главы московского офиса разработки Badoo Алексей Рыбак и ведущие IT-Компот записали выпуск подкаста «Архитектура высоконагруженных приложений. Масштабирование распределенных систем".

Сейчас мы сделали расшифровку подкаста, привели ее в удобный для чтения вид и разбили на 2 части.

О чем говорили в первой части:

• Общая информация о проекте Badoo: стек технологий, характер и объем нагрузки, посещаемость.
• Горизонтальное масштабирование проекта:

— веб-сервера, кеширование, мониторинг etc;
— подводные камни при масштабировании проекта;
— масштабирование баз данных, как правильно делать шардинг.

И снова здравствуйте! После перерыва в месяц продолжаем экскурсию по форматам изображений и алгоритмам сжатия. Где мы остановились? Ах, да, восьмидесятые годы.

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

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

Документация по Ангуляру отлично подходит для начала работы и ковыряния в API. Однако, она не объясняет как организовать и управлять приложением, когда оно разрастется до десятков или сотен тысяч строк кода. Я собрал здесь некоторые из моих наблюдений и передового опыта по управлению расползающимися приложениями. Сначала взглянем на организацию, затем перейдем к некоторым советам по улучшению производительности и закончим краткой сводкой по инструментам, серверам и процессу сборки. Этот пост будет сосредоточен на больших приложениях, в частности, есть отличная статья по лучшим практикам AngularJS с декабрьской встречи, на которую также стоит взглянуть.

Shortcuts: github, tiles.js tiles.groovy tiles.ruby

Не секрет, что объектов в играх на порядок больше чем их возможных поведений. При прототипировании описания объектов можно составлять прямо в коде на Java, С++ или C#, но там всё довольно быстро запутается. Потом объекты выносят в базу данных, либо в XML или JSON конфиг. Это сильно помогает, ведь после редактирования конфигурации пересобирать код не требуется, и этим могут заниматься не только программисты, но и спецы по предмету (для игр это гейм-дизайнеры и контентщики). Когда разрастается команда либо количество объектов переходит какую-то черту, программисты пишут удобный редактор, который позволяет визуально править этот JSON-конфиг. В результате на выходе получается какой-то трудно поддерживаемый монстр.

Если вы не собираетесь нанимать множество людей которые вообще не умеют кодить, то можно попробовать пойти другим путём: описывать метаданные с помощью Domain Specific Language.