Совсем недавно на Хабре появилась статья о реализации дружеских связей в ВКонтакте с помощью Wolfram Mathematica. Идея мне понравилась, и, естественно, захотелось сделать такой же граф, используя Python и d3. Вот, что из этого получилось.

В статье опишу свой опыт эвалюации (и апостилирования для этого) диплома через World Education Services, США (далее — WES).
Исходный материал:
— диплом о высшем образовании, Казанский государственный университет (ныне — КФУ), экономический факультет
— диплом кандидата наук, Казанский государственный технологический университет (ныне — КНИТУ), специализация — экономика.
Постараюсь ответить на вопросы, которые возникали у Меня самого, когда искал информацию по этой теме.

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

У каждого есть возможность воспользоваться специально созданной для обучения школьников средой программирования Scratch, которую разрабатывают специалисты одного из самых престижных технических учебных заведений США и мира — Массачусетского технологического института. Или игрой Minecraft, за которую Microsoft год назад заплатила $2,5 млрд и с помощью которой, в том числе, планирует обучать детей программированию. Или обучающими играми, которые создают энтузиасты и добровольцы во всём мире.

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

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

Преподаватель курса – Алексей Калинин, исполнительный продюсер СООО «Гейм Стрим», минского центра разработки Wargaming, автор 30 настольных и 10 компьютерных игр.

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

Доброго времени суток, уважаемые хабравчане! В Elasticweb мы негласно ратуем за Nginx и, наверное, мы одни из немногих хостингов, которые не поддерживают Apache и .htaccess соответственно. В связи с этим, большое количество обращений в тех. поддержку связано с оказанием помощи в написании конфигурационного файла для Nginx. Поэтому мы решили собрать коллекцию полезных сниппетов и коллекцию готовых Nging конфигов для наиболее популярных CMS/CMF/Фреймворков на PHP.

Схема отработки аварии первого уровня в «Мультикарте»

Есть такой миф, что у нас отказоустойчивых инфраструктур у крупных компаний не было примерно до 2007 года. Мол, именно тогда начали появляться документы DRP (аварийного восстановления), выделяться отделы риск-менеджмента и так далее.

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

А теперь поехали развеивать другие мифы про DRP и непрерывности. Ну и заодно расскажу про наш последний проект — аварийные планы «Мультикарты», то есть той системы, через которую идут все ваши оплаты картами в России.

Ну и, конечно, истории былинных провалов.

В одной из своих статей я рассказывал об асинхронной работе с Tarantool на Python. В данной статье продолжу эту тему, но внимание хочу уделить обработке информации через очереди на Tarantool. Мои коллеги опубликовали несколько статей о пользе очередей (Инфраструктура обработки очередей в социальной сети Мой Мир и Push-уведомления в REST API на примере системы Таргет Mail.Ru). Хочу дополнить информацию об очередях на примере решений наших задач, а также рассказать о работе с Tarantool Queue на Python и asyncio. Почему мы выбираем именно Tarantool, а не Redis или RabbitMQ?

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

Сразу скажу, что делал это не первый раз, до этого успешно делал партицирование у сайта на битрикс примерно вот таким образом:

Шаг 1. Убираем AUTO INCREMENT из таблицы b_iblock_element.

ALTER TABLE b_iblock_element MODIFY ID INT(11) NOT NULL

Шаг 2. Удаляем PRIMARY key из таблицы.

ALTER TABLE b_iblock_element DROP PRIMARY KEY

Шаг 3. Создаем новый PRIMARY KEY, который будет содержать прошлый ключ и IBLOCK_ID, по которому идет разбиение на partition`ы.

ALTER TABLE b_iblock_element ADD CONSTRAINT id_iblock_id PRIMARY KEY (ID,IBLOCK_ID)

Шаг 4. Возвращаем AUTO INCREMENT.

ALTER TABLE b_iblock_element MODIFY ID INT(11) NOT NULL AUTO_INCREMENT

Шаг 5. Наконец то делаем разбиением на 10 частей.

ALTER TABLE b_iblock_element PARTITION BY HASH(IBLOCK_ID) PARTITIONS 10;

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

Теперь же мне предстояло разбить другую таблицу, и хотелось бы ее разбить сразу по 2 полям: по типу и дате. Причем дату хотелось разбить по месяцам и данные хранить не больше года.

Разрешите представить вам перевод статьи Нолана Лоусона «У нас проблемы с промисами», одной из лучших по теме из тех, что мне доводилось читать.

У нас проблемы с промисами

Дорогие JavaScript разработчики, настал момент признать это — у нас проблемы с промисами.

Нет, не с самими промисами. Их реализация по спецификации A+ превосходна. Основная проблема, которая сама предстала передо мной за годы наблюдений за тем, как многие программисты борются с богатыми на промисы API, заключается в следующем:

— Многие из нас используют промисы без действительного их понимания.

Если вы мне не верите, решите такую задачку:

Вопрос: В чем разница между этими четырьмя вариантами использования промисов?

doSomething().then(function () {
  return doSomethingElse();
});

doSomething().then(function () {
  doSomethingElse();
});

doSomething().then(doSomethingElse());

doSomething().then(doSomethingElse);

Всем привет!

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

Давайте я отвлеку вас от котиков и расскажу, основываясь на своём опыте, какие подводные камни появляются при переходе с MyISAM на InnoDB, и как их избежать. Код приложения будет на PHP.

Этот пост я решил написать, прочитав огромное количество неправильных ответов на запрос из сабжа в интернете. По всему интернету разбросаны неграмотные или не полные ответы, в результате чего складывается впечатление о том, что смигрировать вашу базу данных на InnoDB — это очень просто. Нет, это не просто! Итак, начнем!

Зачем переходить на InnoDB

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

Подготовительный этап

1. Из банального — это обеспечить необходимое количество свободного места на диске, где у нас развернута база. InnoDB занимает примерно в 1,5 раза больше места, чем MyISAM.

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

SELECT /*017*/ client_id, money, lastname FROM clients WHERE money > 100;

Я с удивлением обнаружил, что многие разработчики, даже давно использующие postgresql, не понимают оконные функции, считая их какой-то особой магией для избранных. Ну или в лучшем случае «копипастят» со StackOverflow выражения типа «row_number() OVER ()», не вдаваясь в детали. А ведь оконные функции — полезнейший функционал PostgreSQL.
Попробую по-простому объяснить, как можно их использовать.

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

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

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

Один технический специалист нашей компании PayOnline, которая занимается автоматизацией приема платежей, предложил перевести статью автора Pascal de Vink, который проработал тим-лидом уже 2 года. Когда Pascal только занял эту должность, оказалось, что ко многим вещам он был просто не готов. Эта статья поможет избежать многих ошибок на пути от разработчика к лидеру команды. Ниже идет непосредственно перевод.

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

Меньше заниматься разработкой

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

Введение. В современном мире существует большое количество задач, в рамках которых приходится обрабатывать большие массивы однотипных данных. Яркими примерами являются системы для анализа биржевых котировок, погодных условий, статистики сетевого трафика. Многие из этих систем используют различные реляционные базы данных, в таблицах которых содержатся такие объемы данных, что правильное составление и оптимизация запросов к этим таблицам становится просто необходимым для нормального функционирования системы. В этой статье описаны методы решения ( и сравнительные временные характеристики используемых методов ) нескольких задач по получению данных из таблиц СУБД MySQL, содержащих статистику о проходящем через маршрутизаторы одного из крупных российских сетевых провайдеров сетевом трафике. Интенсивность потока данных, поступающего с главного маршрутизатора такова, что ежесуточно в таблицы базы данных используемой системы мониторинга сетевого трафика поступает в среднем от 400 миллионов до миллиарда записей, содержащих информацию о транзакциях TCP/IP (рассматриваемый маршрутизатор экспортирует данные по протоколу netflow). В качестве СУБД для системы мониторинга используется MySQL.

«Moving from the one-room schoolhouse to the one-world schoolhouse is now a reality» (Cisco Systems)

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


Мы учились английскому у этого парня

Микрософт с помощью пасьянса и косынки учила пользователей пользоваться мышью,
теперь с помощью windows 10 учит читать лицензионное соглашение.

После выхода windows 10 сразу появились сообщения о сборе информации о действиях пользователей и много обсуждений, что делать. Достаточно быстро пользователи составили список основных серверов, собирающих информацию и попытались их заблокировать через файл hosts. Но скептики сразу выдвинули здравое предположение, что MS мог предусмотреть этот метод и некоторые адреса прописать в коде. Тем более, что MS всегда может актуализировать адреса серверов через windows update.

В нашей компании начали появляться первые пользователи windows 10, и мы решили опробовать блокировку передачи телеметрии через встроенный windows firewall.

Введение

Apache и Nginx — 2 самых широко распространенных веб-сервера с открытым исходным кодом в мире. Вместе они обслуживают более 50% трафика во всем интернете. Оба решения способны работать с разнообразными рабочими нагрузками и взаимодействовать с другими приложениями для реализации полного веб-стека.

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

Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!

Содержание:

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита