В начале января я написал пост с интересными тестовыми задачками по Java. Он вызвал достаточно большой интерес, интересные задачки еще остались, поэтому продолжим.

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

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

Данная статья является первой частью текстовой версии одноименного доклада с февральской конференции C++ CoreHard Winter 2017. Так уж получилось, что вот уже 15 лет я отвечаю за разработку фреймворка SObjectizer. Это один из тех немногих все еще живых и все еще развивающихся OpenSource фреймворков для C++, которые позволяют использовать Модель Акторов. Соответственно, за это время неоднократно доводилось попробовать Модель Акторов в деле, в результате чего накопился некоторый опыт. В основном это был положительный опыт, но есть и некоторые неочевидные моменты, про которые было бы хорошо узнать заранее. О том, на какие грабли довелось наступить, какие шишки были набиты, как можно упростить себе жизнь и как это сказалось на развитии SObjectizer-а и пойдет речь далее.

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

Привет, Хабр!

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

В качестве первого шага предлагаем вам выполнить небольшое, но очень полезное практическое задание. В пятницу, 24 июля в 20:30 МСК наш технический директор Кирилл Мокевнин toxicmt проведет код–ревью нескольких типичных решений, укажет на хорошие и плохие моменты и расскажет о том, как это задание помогает многое прояснить в понимании парадигм программирования.

Содержание

1. Что такое тензор и для чего он нужен?
2. Векторные и тензорные операции. Ранги тензоров
3. Криволинейные координаты
4. Динамика точки в тензорном изложении
5. Действия над тензорами и некоторые другие теоретические вопросы
6. Кинематика свободного твердого тела. Природа угловой скорости
7. Конечный поворот твердого тела. Свойства тензора поворота и способ его вычисления
8. О свертках тензора Леви-Чивиты
9. Вывод тензора угловой скорости через параметры конечного поворота. Применяем голову и Maxima
10. Получаем вектор угловой скорости. Работаем над недочетами
11. Ускорение точки тела при свободном движении. Угловое ускорение твердого тела
12. Параметры Родрига-Гамильтона в кинематике твердого тела
13. СКА Maxima в задачах преобразования тензорных выражений. Угловые скорость и ускорения в параметрах Родрига-Гамильтона
14. Нестандартное введение в динамику твердого тела
15. Движение несвободного твердого тела
16. Свойства тензора инерции твердого тела
17. Зарисовка о гайке Джанибекова
18. Математическое моделирование эффекта Джанибекова

Введение

В прошлой статье мы напоролись на конструкцию вида — произведение контравариантного тензора Леви-Чивиты на ковариантный. И, надо сказать, упростил я его не слишком элегантно, а довольно таки топорно. К тому же, конечное выражение формулы Родрига, что в компонентной, что в бескомпонентной форме оказалось крайне неудобным в плане дальнейшего преобразования. Но я ведь обещал читателю показать, как из выражения матрицы поворота через параметры конечного поворота получить угловую скорость твердого тела, поэтому, вопросы излагаемые ниже будут иметь решающее значение в применении тензорного подхода к кинематике и динамике твердого тела. Заодно в очередной раз порекомендую довольно старый сайт «На что похожа математика», хоть и созданный на движке народа.ру, но содержащий сведения, уже несколько раз подталкивающие меня в правильном направлении при решении проблем в изучении тензорной алгебры.

Итак, поговорим о свертках тензора Леви-Чивиты.

Понятие энтропии в середине XX века ввёл Клод Шеннон. Её можно интуитивно описать как «среднее количестве битов информации в одном значении случайной величины». Но её нельзя применить к индивидуальным объектам (скажем, к тексту романа или ДНК) — где нет ансамбля многих однородных объектов, нет и случайных величин.



В середине 1960-х годов разным людям (Колмогоров, Соломонов, Левин, Чейтин) стало понятно, что можно определять количество информации (сложность) индивидуального объекта как минимальную длину программы, которая этот объект порождает (при естественных ограничениях на язык программирования). Возникла алгоритмическая теория информации, которая оказалась связанной с разными областями: от философских вопросов оснований теории вероятностей (когда мы отвергаем статистические гипотезы?) до комбинаторики (неравенства, связывающие размеры множеств и их проекций) и теории вычислимости.

Лекцию, которую мы выбрали для вас сегодня, читал на факультете компьютерных наук Вышки известный математик Александр Шень. Когда-то он под руководством Владимира Успенского, ученика Колмогорова, защитил диссертацию «Алгоритмические варианты понятия энтропии».

Я очень часто по работе слышу вопрос, задаваемый из, большей частью, академической среды, ввиду огромного количества выполняемых вычислений именно там: «Почему наши результаты разные от запуска к запуску одного и того же приложения? Мы же ничего не меняем в нем». Стоит отметить, разговор про это уже был, но лишь частично отвечающий на вопрос. Попробую рассказать про эту проблему ещё чуть-чуть.

С 5 марта открыта регистрация на участие в главном российском чемпионате по спортивному программированию — Russian Code Cup (RCC). Победители чемпионата завоюют звание лучших программистов года и разделят призовой фонд в размере 750 000 рублей. В RCC ежегодно принимают участие несколько тысяч русскоговорящих участников со всего мира. Они сражаются за звание не только самого талантливого, но и самого быстрого программиста, поскольку решение оригинальных и сложных задач чемпионата оценивается сразу по двум критериям: качество и скорость. Этот чемпионат дает молодым программистам прекрасную возможность продемонстрировать свое мастерство, получить признание профессионального сообщества и обратить на себя внимание крупных IT-компаний.

У меня есть сайт со статьями схожей тематики. На сайте было две проблемы: спамерские сообщения и дубликаты статей, причём дубликаты часто являлись не точными копиями.

Данный пост повествует о том, как я решил эти проблемы.

Дано:

• общее количество статей 140 000;
• количество спама: примерно 16%;
• количество не чётких дубликатов: примерно 63%;

Задача: избавиться от спама и дубликатов, а так же не допустить их дальнейшего появления.

Здравствуйте, меня зовут Александр Акбашев, я Lead QA Engineer в проекте Skyforge. А также по совместительству ассистент tully в Технопарке на курсе «Углубленное программирование на Java». Наш курс идет во втором семестре Технопарка, и мы получаем студентов, прошедших курсы по C++ и Python. Поэтому я давно хотел подготовить материал, посвященный самым распространенным ошибкам новичков в Java. К сожалению, написать такую статью я так и не собрался. К счастью, такую статью написал наш соотечественник — Михаил Селиванов, правда, на английском. Ниже представлен перевод данной статьи с небольшими комментариями. По всем замечаниям, связанным с переводом, прошу писать в личные сообщения.



Изначально язык Java создавался для интерактивного телевидения, однако со временем стал использоваться везде, где только можно. Его разработчики руководствовались принципами объектно-ориентированного программирования, отказавшись от излишней сложности, свойственной тем же С и С++. Платформонезависимость виртуальной машины Java сформировала в своё время новый подход к программированию. Добавьте к этому плавную кривую обучения и лозунг «Напиши однажды, запускай везде», что почти всегда соответствует истине. Но всё-таки ошибки до сих пор встречаются, и здесь я хотел бы разобрать наиболее распространённые из них.

Посмотришь на любую программу обучения по IT-специальности, и тут же увидишь дисциплину «Дискретная математика» (возможно, под другим названием), обычно для перво- или второкурсников. И её наличие вполне разумно, поскольку дискретная математика и непрерывная математика (представленная на первом курсе институтов с незапамятных времён математическим анализом) — две грани единой Математики, — красивой, могучей науки.

Хотя раньше такого понятия, как «дискретная математика» вовсе не было, это не значит, что не возникало дискретных задач: Абель, Дирихле, Фибоначчи, Эйлер, чьи имена возникают по ходу изучения дискретной математики, — отнюдь не наши современники! Но просто в те времена для выделения самостоятельной ветви математики ещё не сложилось критической массы задач и приёмов, не было видно взаимосвязей между ними. А большое количество плодотворных взаимосвязей между, на первый взгляд, различными понятиями, — то, что математики в своей науке очень ценят.

Ну хорошо, математикам всё математическое интересно. А зачем дискретная математика программисту?

Основная масса хранимых современными компаниями данных является неструктурированной, т.е. это данные, созданные сотрудниками компании, а не, скажем, базой данных или выгрузкой автоматического сервиса. При этом даже при идеально настроенной системе прав доступа к ресурсам нельзя гарантировать, что в отдельно взятой папке лежит действительно то содержимое, которое мы ожидаем там увидеть. Номера паспортов и кредитных карт в папке с договорами подрядчиков? Элементарно. Фоточки с без сомнения увлекательного отпуска на Гоа в папке бухгалтерской отчетности? Легко! Новинки кинопроката в каталоге для обучения сотрудников? Да запросто! Вы все еще удивлены?

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

Основные нововведения и улучшения:

• Произвольные механизмы хранения, в том числе WiredTiger. Теперь api монго отделено от того как база хранит данные. Это позволяет создавать новые способы хранения данных, например InMemory.
• Высокая производительность и эффективность. Новый механизм хранения WiredTiger использует блокировку на уровне документа, что позволяет значительно улучшить производительность. Так же он использует алгоритмы сжатия данных и индексов, что значительно уменьшает размеры хранимых данных.
• Упрощенные операции через Ops Manager. Он позволяет проводить такие операции, как развертывание, масштабирование, модернизацию и резервное копирование в несколько кликов или вызов API. Улучшена система логирования.
• Улучшен аудит безопасности.
• Улучшен язык запросов и инструменты. mongoimport, mongoexport, mongodump, mongorestore и mongooplog теперь работают быстрее. Возможность смотреть план выполнения до запроса с помощью explain.

С более подробной информацией вы можете познакомиться здесь:
Официальный анонс 3.0
Анонс основных нововведений в Mongodb 3.0
Вебинар «Что нового в Mongodb 3.0»
pdf Что нового в Mongodb 3.0

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



В моём частном случае речь пойдёт о блокировке от «Билайна». Чтобы избавится от её назойливости, нам понадобится веб-сервер. Подойдёт установленный на локальной машине.

«Билайн» перекидывает нас на страницу blackhole.beeline.ru/?url=...., где в переменной url в закодированном urlencode виде содержится наш адрес. Копировать и декодировать его каждый раз руками достаточно скучное дело, поэтому мы попробуем использовать нашу эволюционную особенность — мозг.

Сооснователи Google Сергей Брин и Ларри Пейдж дали большое интервью венчурному капиталисту Виноду Хосле на прошедшем ежегодном саммите Khosla Ventures, и видеозапись этого интервью на прошлой неделе появилась на YouTube, пишет TechCrunch.

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

Особенно интересны были их мысли о будущем здравоохранения, учитывая последние шаги Google в этой сфере. Примерно на 29 минуте в видео выше Хосла спрашивает: «Можете ли вы представить, чтобы Google стал медицинской компанией? Эта сфера может быть больше, чем поисковый бизнес или медиа-бизнес».

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

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

Ах, да, ещё кое что. Это не пособие о том, как получить работу в Google. Основываясь на моём опыте, я не думаю что подобное вообще существует. Я не буду описывать интервью в деталях (вы не узнаете, что за вопросы мне задавали), дабы не разглашать никакой конфиденциальной информации.

Основная цель этого текста — рассказ о моём личном опыте полученном в период «до-Google». Надеюсь, что это будет хоть немного полезному кому-нибудь из вас.

Этот пост хотелось бы написать скорее в философском ключе, нежели в математическом (точнее алгебраическом): не что это за страшный зверь — ЛСА, а какая от него может быть польза «нашему колхозу», т.е. ИИ.

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

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

Формально:
ЛСА используется для выявления латентных (скрытых) ассоциативно-семантических связей между термами (словами, н-граммами) путем сокращения факторного пространства термы-на-документы. Термами могут выступать как слова, так и их комбинации, т.наз. н-граммы, документами – в идеале: наборы тематически однородных текстов, либо просто любой желательно объемный текст (несколько млн. словоформ), произвольно разбитый на куски, например абзацы.

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

Например, рассмотрим два простых сообщения из разных источников (просто пример для наглядности):

Осторожно, персистентность

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

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

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

Я хочу достичь следующих целей при использовании системы:

• помнить все термины и слова, которые когда-либо решил запомнить;
• свободно использовать факты в разговорах и дискуссиях;
• сохранять накопленный опыт: иметь информацию обо всех текущих и законченных проектах, о важных встречах и разговорах, об изученных темах;
• моментально находить любые статьи, которые когда-либо показались интересными;
• держать сознание свободным от любой текучки;
• тратить на это все не более 20 минут в день.

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

• Мой опыт по описанному вопросу
• Проблемы запоминания
• Теоретическое разрешение проблем
• Практическое разрешение проблем с Evernote
• Практическое разрешение проблем с Anki

В разработке интерфейсов отдельные фреймворки уже не так важны: когда инструменты доступны, наша задача сводится к выбору нужных. Чтобы сделать правильный выбор, следует начать с общего подхода, с методологии. Большинство методологий, однако, разработаны крупными компаниями. Применимы ли они в маленьких проектах или для успешного использования их нужно переизобретать заново?

Скорее всего, вы уже знаете об одной из таких методологий, разработанной Яндексом, — БЭМ. БЭМ утверждает, что трёх сущностей (блоков, элементов и модификаторов) достаточно для написания HTML и CSS, задания структуры кода и компонентной структуры с последующим масштабированием проекта до самого высокого уровня.

Я проработал в Яндексе достаточно долго и видел, как эта методология работает на больших проектах. В Яндексе БЭМ используют для разработки CSS- и JavaScript-компонент, с помощью этой методологии также пишут шаблоны и задают зависимости между компонентами. Есть БЭМ-инструменты, поощряются различные эксперименты с кодом, исследования. В масштабах большой компании эти трудозатраты окупаются и дают Яндексу возможность быстро и качественно разрабатывать сотни сервисов одновременно.

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

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