В заметке собраны сайты с обучающими материалами для веб-дизайнеров и веб-разработчиков. Старался не повторяться с постом 27+ ресурсов для онлайн-обучения хабраюзера nicolausYes.

Academic Earth

Множество бесплатных лекций, в том числе от известных университетов (Гарвард, MIT, Стенфорд и др.).

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

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

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


Почему нельзя просто так взять и расширить запрос.

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

Навигация по основам Linux от основателя Gentoo:

Часть I: 1, 2, 3, 4

Часть II: 1, 2, 3, 4, 5

Часть III: 1, 2, 3, 4

Часть IV

1. Файловые системы, разделы и блочные устройства (вступление)
2. Загрузка системы и уровни загрузки
3. Квоты файловых систем
4. Системные логи (итоги и ссылки)

Тут живут драконы и нет ментейнеров (вместо эпиграфа)

Очень сжатое боевое описание «что есть псевдо-терминал» и «консоль».

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

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

Как легко понять по кабелю, есть два конца: терминал и то, что ему посылает байтики в кабель.

Когда запускается шелл, то он получает в своё распоряжение виртуальное устройство /dev/tty, которое у каждого процесса своё — это «обратная» часть терминала. Передняя часть в случае кабеля реализуется путти+компьютер, в случае консоли компьютера, специализированным ядерным драйвером (виртуальными консолями). Важно: драйвер эмулирует наличие терминала.

Профессиональные программисты, как новички, так и опытные, обычно придерживаются концепции IDE, или «интегрированной среды разработки». Правда, удобно же иметь самые необходимые средства организации, написания, поддержки и тестирования кода в одном приложении с единым интерфейсом для всех инструментов? К тому же, среда, специально спроектированная для программирования, дает ряд преимуществ, таких как автодополнение, проверка и подсветка синтаксиса.

Подобные средства есть для всех распространенных настольных ОС, включая Linux и BSD, и многие из них совершенно бесплатны, так что вряд ли имеет смысл ограничивать себя в Блокнотом Windows, nano или cat.

Однако, в среде поклонников Unix гуляет в разнообразных вариациях мем о том, что «Unix — это IDE», в том смысле, что средства, которыми разработчики располагают в терминале, легко реализуют основные возможности современных IDE. Вы можете соглашаться или отказываться признать Unix «IDE» в том самом смысле, что Eclipse или Microsoft Visual Studio. Так или иначе, вас скорее всего удивит, насколько законченную среду разработки может являть собой скромный Bash.

В этой статье я опишу процесс создания собственного системного монитора. Данный системный монитор показывает:

• Hostname
• Имя пользователя
• Uptime
• Имя модели процессора
• Частоту процессора
• Загрузку процессора
• Количество оперативной памяти
• Количество используемой оперативной памяти без кэшируемых данных
• Запущенные процессы

Мы уже рассказывали о том, как был сделан выбор в пользу протокола WebDAV, а также о проблемах, возникающих на серверной стороне, и их решении.

Сегодня — о том, как устроен загрузчик файлов на сервис, и о чём нужно не забывать, когда пишешь его для сервисов масштаба Яндекс.Диска.



Для начала рассмотрим архитектуру сервиса в целом. В основе сервиса лежит mpfs – Магическая проксирующая файловая система. Это бэкэнд, который содержит в себе всю бизнес-логику по работе с файлами, папками, каталогами: все операции по копированию или созданию новых файлов идут через эту систему. Эта же система отвечает и за хранение метаданных.

Это перевод 1.17 версии руководства от Rafe Kettler.

Содержание

1. Вступление
2. Конструирование и инициализация
3. Переопределение операторов на произвольных классах
   • Магические методы сравнения
   • Числовые магический методы
4. Представление своих классов
5. Контроль доступа к атрибутам
6. Создание произвольных последовательностей
7. Отражение
8. Вызываемые объекты
9. Менеджеры контекста
10. Абстрактные базовые классы
11. Построение дескрипторов
12. Копирование
13. Использование модуля pickle на своих объектах
14. Заключение
15. Приложение 1: Как вызывать магические методы
16. Приложение 2: Изменения в Питоне 3

Вступление

Что такое магические методы? Они всё в объектно-ориентированном Питоне. Это специальные методы, с помощью которых вы можете добавить в ваши классы «магию». Они всегда обрамлены двумя нижними подчеркиваниями (например, __init__ или __lt__). Ещё, они не так хорошо документированны, как хотелось бы. Все магические методы описаны в документации, но весьма беспорядочно и почти безо всякой организации. Поэтому, чтобы исправить то, что я воспринимаю как недостаток документации Питона, я собираюсь предоставить больше информации о магических методах, написанной на понятном языке и обильно снабжённой примерами. Надеюсь, это руководство вам понравится. Используйте его как обучающий материал, памятку или полное описание. Я просто постарался как можно понятнее описать магические методы.

В этот раз я хочу поговорить о виртуальном наследовании в языке Си++, и почему его следует использовать очень осторожно. Предыдущие статьи: часть N1, N2, N3.
Статья написана по мотивам заметки "Грабли 2: Виртуальное наследование". Статья хорошая, но, на мой взгляд, несколько размыта, и новичок может не до конца уловить суть опасностей. Я решил предложить свой вариант описания проблем связанных с виртуальным наследованиям.

На прошедшем неделю назад чемпионате мира по командному программированию ACM ICPC 2013 было 11 задач, одну из которых за отведённое время не смогла решить правильно ни одна из команд.

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

В этом году на ACM ICPC был 21 аналитик из Швеции, Нидерландов, США, Словакии, Беларуси и России. И 10 из них были из Яндекса. Все они в разные годы были призёрами ICPC. Специально для Хабра они разобрали все задания чемпионата.

Доброго времени суток. Этот топик рассчитан на тех, кто имеет представление об ограниченных машинах Больцмана (restricted Boltzmann machine, RBM) и их использовании для предобучения нейронных сетей. В нем мы рассмотрим особенности применения ограниченных машин Больцмана для работы с изображениями, взятыми из реального мира, поймем, почему стандартные типы нейронов плохо подходят для этой задачи и как их улучшить, а также немного пораспознаем выражения эмоций на человеческих лицах в качестве эксперимента. Те, кто представления o RBM не имеет, могут его получить, в частности, отсюда:

Реализация Restricted Boltzmann machine на c#,
Предобучение нейронной сети с использованием ограниченной машины Больцмана

Тема анонимности в Интернете является сейчас достаточно модной и интересной, и особенно теперь, когда новостные порталы пугают наc всякими там PRISM, правительственными инициативами и прочим. Большинство людей озабочены тем, как сохранить тайну своей личности в сети и поэтому все темы так или иначе посвящены ЗАЩИТЕ. Но иногда, раскрытие анонимности это не такое уж и плохое дело. Да-да, эта заметка — мой опыт борьбы с анонимностью своими силами, без помощи спец-служб…

Доброго времени суток уважаемые хабражители. Сегодня увидел один интересный проект на GitHub. Эта маленькая библиотека (Voyeur.min.js — 1.2kb) очень привлекает своим синтаксисом и неплохим функционалом.



Даже не переводя документацию с официального сайта, код можно понять интуитивно. По традиции приведу несколько примеров:

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

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

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

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

Группа американских учёных, получив финансирование от исследовательского центра Национальной разведки США (IARPA) разработала высокоуровневый язык программирования Quipper. Он создан на основе Haskell и лучше подходит для реализации квантовых алгоритмов, чем QCL (основан на C).

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

Весной 2012 г., Питер Тиль (Peter Thiel), один из основателей PayPal и первый инвестор FaceBook, провел курс в Стенфорде — «Стартап». Перед началом Тиль заявил: «Если я сделаю свою работу правильно, это будет последний предмет, который вам придется изучать».

Один из студентов лекции записывал и выложил транскипт. В данном хабратопике degorov, переводит шестнадцатое занятие, редактор astropilot.

Занятие 1: Вызов будущего
Занятие 2: Снова как в 1999?
Занятие 3: Системы ценностей
Занятие 4: Преимущество последнего хода
Занятие 5: Механика мафии
Занятие 6: Закон Тиля
Занятие 7: Следуйте за деньгами
Занятие 8: Презентация идеи (питч)
Занятие 9: Все готово, а придут ли они?
Занятие 10: После Web 2.0
Занятие 11: Секреты
Занятие 12: Война и мир
Занятие 13: Вы — не лотерейный билет
Занятие 14: Экология как мировоззрение
Занятие 15: Назад в будущее
Занятие 16: Разбираясь в себе
Занятие 17: Глубокие мысли
Занятие 18: Основатель — жертва или бог
Занятие 19: Стагнация или сингулярность?

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

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

Примечание от переводчика:
Представляю вам, перевод интересной статьи Армина Ронахера, автора веб-фреймворков Flask и Werkzeug, шаблонизатора Jinja2 и вообще известного питониста об актуальных техниках и подводных камнях, применяемых им в его проектах при добавлении поддержки третьего питона. Небольшая заметка по поводу названия данной статьи. Оно является отсылкой к статье Армина 2010 года «Портирование на питон 3. Руководство», в которой он описывал подготовку кода для автоматического портирования через утилиту 2to3. Как показывает практика, сегодня такой подход является скорее антипаттерном, т.к. с одной стороны, качество кода в результате подобных операций заметно ухудшается, а кроме того, такой код заметно труднее поддерживать.

После чрезвычайно болезненного опыта портирования Jinja2 на третий питон, мне пришлось оставить проект на холостом ходу на некоторое время, т.к. я слишком сильно боялся сломать поддержку питона 3 версии. Подход, который я использовал состоял в написании кода для питона 2 версии и перевода с помощью 2to3 на третий питон во время установки пакета. Самым неприятным побочным эффектом стало то, что любое изменение, которое вы вносите, требует примерно минуты на перевод, тем самым убивая скорость ваших итераций. К счастью, оказалось, что если правильно указать конечные версии питона, процесс идет ощутимо быстрее.

Томас Волдман из проекта MoinMoin начал с запуска Jinja2 через мой python-modernize с правильными параметрами, и пришел к единому коду, который работает под 2.6, 2.7 и 3.3. Путем небольших приборок мы смогли прийти к приятной кодовой базе, которая работает со всеми версиями питона и при этом, в большинстве своем, выглядит, как обычный код на питоне.

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

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

Привет! Ниже речь пойдет об известных всем операторах new и delete, точнее о том, о чем не пишут в книгах (по крайней мере в книгах для начинающих).
На написание данной статьи меня побудило часто встречаемое заблуждение по поводу new и delete, которое я постоянно вижу на форумах и даже(!!!) в некоторых книгах.
Все ли мы знаем, что такое на самом деле new и delete? Или только думаем, что знаем?
Эта статья поможет вам разобраться с этим (ну, а те, кто знают, могут покритиковать:))

Возможно вы помните пост: Нужна ли книга по Hadoop?, в котором мы хотели узнать ваше мнение, стоит ли издавать эту книгу на русском языке. Прошли положенные 9 месяцев, и мы готовы представить её вашему вниманию.

Встречайте: