Был как-то проект у меня, который был связан с картой города. И возникла идея, что раз есть карта с маршрутами и соответствующими остановками городского транспорта, то почему бы не сделать поиск пути из пункта А в пункт Б на ней.

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

Где-то около часа или двух я сидел и не мог ничего придумать, а потом появилась идея, что я могу рассматривать маршрут, не как множество остановок, а как 1 точку. И если я сверну маршруты в точку, то я получу очень простой граф.
Идея показалось неплохой, и мне понравилась.

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

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

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

Качество видео ужас, но как сделать получше я так и не обнаружил.



Усредненное время, затрачиваемое на выполнение шагов:

gpt — 0.009с, найти ближайшие остановки к точке клика
grt — 0.001с, найти кратчайший путь от маршрута к маршруту
apt — 0.0001с, добавляем остановки и точки поворота к нашему маршруту
all — 0.01c, суммарное время выполнения поиска пути

На хабре часто публикуют статьи о самоорганизации — нам всем хочется меньше прокрастинировать, и делать больше полезного. Но что если делать полезное мешает дичайшая усталость? Никакая организация задач усталость не уберет.

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

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

1) Летом все ок, а зимой — апатия, ничего не хочется делать. Это любят называть сезонной «депрессией».
2) Утром все ок, а к вечеру на работе — мозги «не варят», ничего не хочется делать — только хабр и reddit листать. Приходите домой — и с дичайшей усталостью падаете в кресло. Сил хватает только лазить в интернете до ночи. Этот пункт — касается и работодателей, есть шанс, что люди вечером перестают работать не из-за своей лени.
3) Даже если вы просыпаетесь без будильника — вы не высыпаетесь.
4) Кофе и прочие стимуляторы — не дают бодрости, лишь делают вас злее.
5) Даже если вы спите «сколько влезет» — сны короткие и не запоминающиеся, или их нет вообще.
6) Вы замечаете, что даже 1 вещь вам иногда трудно удержать в голове. Мы можете забыть что вы сейчас хотели сделать.
7) Вы просыпаетесь уже с дичайшей усталостью
8) Вам кажется, что в комнате темно и все несколько не резкое.

В этом посте будут рассмотрены пять путей повышения эффективности кода, помогающие сборщику мусора проводить меньше времени за выделением и освобождением памяти. Долгая процедура сборки мусора может привести к явлению, известному как «Stop the world».

Общие сведения

Сборщик мусора (Garbage Collector, GC) существует для обработки большого количества выделений памяти под короткоживущие объекты (например, объекты выделенные в процессе рендеринга веб-страницы, устаревают сразу как только страница показана).

GC в этом случае использует так называемое «молодое поколение» («young generation») — сегмент кучи, где размещаются новые объекты. Каждый объект имеет поле «возраст» («age», находится в заголовке объекта), который определяет сколько сборок мусора он пережил. Как только достигнут определенный возраст, объект копируется в другую область кучи, называемую «старым» («old») поколением.

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

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

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

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

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

Одной строкой: тут рекламируется Папирия, онлайновый сервис для подготовки документов в LaTeX. Ходить на papeeria.com.

Введение

Если вы студент, то наверняка либо уже пишете курсовую или диплом, либо всерьез над этим задумываетесь. Если вы к тому же учитесь в техническом вузе и в вашей работе много формул и прочего нетекста, то возможно, вы задумываетесь над тем, в чём его писать — в LibreOffice/Word или в LaTeX. И возможно, от использования LaTeX вас останавливает только то, что Word вот он, под рукой, бери и пиши, а латех надо еще устанавливать, возиться с почти неизбежными подводными камнями и потом еще тупо глядеть на белый лист и думать с чего начать. Вот вам-то мы и хотим помочь. А также тем, кто хочет вести свою научную работу из любого места, где есть интернет.

Для всех остальных: если вы вообще не знаете, что такое латех, то рекомендуем погуглить (можно начать, например, отсюда). Если же что-то знаете и просто хотите потроллить на тему latex vs word, то поищите себе, пожалуйста, другую поляну. Будем премного благодарны.

Многие документы я подготавливаю в LaTeX, а не в Word. И к моменту, когда я определяюсь со следующим местом работы, я подвожу итоги сделанного, и, уж чтобы не пропадало, фиксирую их в документах, составляющих каркас моего CV. По моему личному убеждению, тщательность в создании документов для будущего работодателя нужна не столько для коммуникаций с «эйчарами», сколько для осмысления дороги, по которой идешь, и направления, в котором решаешь двигаться дальше. Итак, почему я для резюме выбрал LaTeX?

Это перевод 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__). Ещё, они не так хорошо документированны, как хотелось бы. Все магические методы описаны в документации, но весьма беспорядочно и почти безо всякой организации. Поэтому, чтобы исправить то, что я воспринимаю как недостаток документации Питона, я собираюсь предоставить больше информации о магических методах, написанной на понятном языке и обильно снабжённой примерами. Надеюсь, это руководство вам понравится. Используйте его как обучающий материал, памятку или полное описание. Я просто постарался как можно понятнее описать магические методы.

Yaxy — proxy-сервер, подменяющий различные части HTTP-запросов и ответов на указанные в config-файле значения. Я не буду здесь описывать, как поставить, настроить и запустить сервер, это всё описано в readme репозитория. Здесь я опишу различные случаи, в которых Yaxy очень помогает, а то и вовсе незаменим.

Для работы мы используем postgresql + postgis базу данных с данными для всей планеты от osm.org. На диске она занимает около 350 Gb и работает не быстро, да и хранится на обычном винчестере 2Tb 7200rpm, без RAID-a. Т.к. нагрузка на базу данных постепенно растет, было решено ускорить дисковую подсистему, потратив при этом минимум денег. Вариантов было не много:

• купить еще один такой же винчестер и объединить их в raid-0.
• купить небольшой SSD и организовать на нем быстрый кэш:
  
  • dm-cache. Был добавлен в ядро 3.9, ставится просто.
  • bcache. Судя по обзорам самый быстрый. Основной минус — надо форматировать диски перед началом использования. Официально добавлен в ядро 3.10, распространяется как пропатченое ядро 3.9.
  • EnhanceIO. В обзорах я встретил упоминание его, как самого медленного, но простого в использовании.

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

Друзья, вы давно вставали с компьютерного кресла и разминали затекшие конечности? Сидячая работа способна неслабо подкосить здоровье — лишний вес приводит к ожирению, сахарному диабету и сердечно-сосудистым заболеваниям… И проблема эта носит планетарные масштабы — более 30% процентов населения Земли страдает от лишенго веса, а это 1,7 миллиарда человек. С этим необходимо что-то делать, и желательно эффективно и быстро.
Ответы на вопросы находятся в плоскости спорта и рационального питания — но в самих этих сферах пока вопросов больше, чем ответов.

Поэтому мы решили создать Gipis — сервис, который позволит решить эти проблемы.

В последнее время в рунете появляется статей про технологию аукциона в реальном времени – Real-time Bidding (RTB). Пока эта тема больше обсуждается на специализированных ресурсах, поэтому я буду одним из первых, кто расскажет о ней на Хабре. Это подлинная, в том числе и технологическая инновация на рынке интернет-рекламы, с которой пора знакомить с ней тех, на кого она собственно нацелена: рекламодателей, покупающих рекламу в интернете, и площадки, зарабатывающие на продаже медийной рекламы и трафика (Habrahabr.ru, например :).

По прогнозам, расценки на медийную рекламу в интернете в 2013 году вырастут на 14 процентов, в то время как в среднем реклама подорожает на 10 процентов. Медийная реклама обгонит и другие инструменты интернет-рекламы – к примеру, контекстная реклама вырастет всего на 13%. На мой взгляд, драйвером этого роста станет именно RTB.

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

А сейчас, в период между Рождеством и Новым Годом, когда особенно обострена склонность к углублённой рефлексии, приходит понимание того, что, знай я некоторые «инсайдерские» подробности управленческой деятельности заранее – сделал бы совсем другой выбор лет эдак семь назад.

Вот поэтому и родился этот немного хаотичный и очень разнокалиберный список моментов, которые очень хотелось бы передать куда-то обратно, примерно в 2005 год – дайте знать, если кто-то вдруг уже научился это делать! А пока, может быть кто-то найдёт некоторые из перечисленных ниже пунктов не до конца очевидными, или даже полезными для себя; было бы приятно осознавать, что удалось помочь кому-то сделать более осознанный выбор профессии – или просто о чём-нибудь важном задуматься.

Я уже около 20 лет программирую на Lisp и прочитал множество сообщений Usenet и статей в блогах, написанных Lisp — разработчиками. Я часто задавал себе вопрос — А существует ли типичный Lisp — разработчик, как существуют типичные представители наций или других групп людей?

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

UPD: получил инвестиции под свой проект в сфере обучения облачным технологиям

Здравствуйте уважаемые Хабравчане, особенно те, у кого есть идея своего стартапа! А вот с деньгами и осведомленностью похуже. Хочу Вам в помощь поделиться небольшой таблицей IT-инвесторов, которая была составлена для себя. Дело в том, что я также как и вы, обладаю минимум информации. Такие вопросы как: «к кому идти за деньгами», «как составить бизнес-план», и наконец «кому я вообще нужен со своей идеей» — давно стали навязчивыми.
Именно сейчас, после Новогодних праздников, самое время начать искать тех самых менторов, инвесторов, бизнес-ангелов, да и в целом зачитываться информацией на эту тему. Да, и у меня есть свой стартап, который перестал быстро развиваться и я активно ищу инвестора на дальнейшее развитие (О чем уже писал неделю назад).
Под катом таблица, со списком полезных ссылок, в помощь начинающим IT-компаниям.

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

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

Чуть лучше дело обстоит в продуктовой разработке, особенно в стартапах, где генерация требований равномерно распределена по всему жизненному циклу работы над продуктом. Благодаря принципам Lean StartUp: построить -> измерить -> изучить, продуктовые команды работают более короткими циклами. На входе каждой итерации — новая порция требований для «эксперимента», в формулирование которых часто вовлечена вся команда.

В заказной разработке я наблюдаю 3 типа проблем, связанных с ожиданием готовых требований от клиента:

1. “Бизнес” не умеет формулировать хорошие требования, потому что не понимает процесса разработки и технологических возможностей. Спецификация содержит представление заказчика о решении проблемы, докопаться до сути которой по документу сложно.
   
   
2. “Бизнесу” не хватает времени на проработку требований. Часть вариантов использования системы, не продуманная заранее, вбрасывается в ходе разработки. Чем меньше практик, поддерживающих итеративный процесс (CI, автоматизированное тестирование, ограничение по количеству фич в работе), тем сложнее вносить изменения в требования.
   
   
3. “Бизнес” и “разработка” говорят на разных языках. Как следствие — ложное понимание требований, не проясненные предположения, вытекающие из них 'сюрпризы' в момент демонстрации. Несуществующую систему сложно описать на бумаге. Отсюда вытекают проблемы, которые можно обобщить словами заказчика: “Я не знаю точно чего хочу, но точно знаю чего не хочу”.

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

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

Ниже — обзор продуктовых техник, которые могут в этом помочь.

Приветствую.

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

Предисловие

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

Введение

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

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

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

Нам понадобится капелька абстрактного мышления, знание какого-нибудь сбалансированного дерева поиска (например, описанного мною ранее декартова дерева), умение читать простой код на C#, и желание применить полученные знания.

Итак, на повестке сегодняшнего дня — моноиды и их основное применение для кеширования вычислений в деревьях.

Моноид как концепция

Представьте себе множество чего угодно, множество, состоящее из объектов, которыми мы собираемся манипулировать. Назовём его M. На этом множестве мы вводим бинарную операцию, то есть функцию, которая паре элементов множества ставит в соответствие новый элемент. Здесь и далее эту абстрактную операцию мы будем обозначать "⊗", и записывать выражения в инфиксной форме: если a и b — элементы множества, то c = a ⊗ b — тоже какой-то элемент этого множества.

Например, рассмотрим все строки, существующие на свете. И рассмотрим операцию конкатенации строк, традиционно обозначаемую в математике "◦", а в большинстве языков программирования "+": "John" ◦ "Doe" = "JohnDoe". Здесь множество M — строки, а "◦" выступает в качестве операции "⊗".
Или другой пример — функция fst, известная в функциональных языках при манипуляции с кортежами. Из двух своих аргументов она возвращает в качестве результата первый по порядку. Так, fst(5, 2) = 5; fst("foo", "bar") = "foo". Безразлично, на каком множестве рассматривать эту бинарную операцию, так что в вашей воле выбрать любое.

Далее мы на нашу операцию "⊗" накладываем ограничение ассоциативности. Это значит, что от неё требуется следующее: если с помощью "⊗" комбинируют последовательность объектов, то результат должен оставаться одинаковым вне зависимости от порядка применения "⊗". Более строго, для любых трёх объектов a, b и c должно иметь место:
(a ⊗ b) ⊗ c = a ⊗ (b ⊗ c)
Легко увидеть, что конкатенация строк ассоциативна: не важно, какое склеивание в последовательности строк выполнять раньше, а какое позже, в итоге все равно получится общая склейка всех строк в последовательности. То же касается и функции fst, ибо:
fst(fst(a, b), c) = a
fst(a, fst(b, c)) = a
Цепочка применений fst к последовательности в любом порядке всё равно выдаст её головной элемент.

И последнее, что мы потребуем: в множестве M по отношению к операции должен существовать нейтральный элемент, или единица операции. Это такой объект, который можно комбинировать с любым элементом множества, и это не изменит последний. Формально выражаясь, если e — нейтральный элемент, то для любого a из множества имеет место:
a ⊗ e = e ⊗ a = a
В примере со строками нейтральным элементом выступает пустая строка "": с какой стороны к какой строке её ни приклеивай, строка не поменяется. А вот fst в этом отношении нам устроит подлянку: нейтральный элемент для неё придумать невозможно. Ведь fst(e, a) = e всегда, и если a ≠ e, то свойство нейтральности мы теряем. Можно, конечно, рассмотреть fst на множестве из одного элемента, но кому такая скука нужна? :)

Каждую такую тройку <M, ⊗, e> мы и будем торжественно называть моноидом. Зафиксируем это знание в коде:

public interface IMonoid<T> {
    T Zero { get; }
    T Append(T a, T b);
}

Больше примеров моноидов, а также где мы их, собственно, применять будем, лежит под катом.

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

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

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

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

Хоть и хотел я покороче, но нюансов много — так что текст все равно получился объемным… Да, и информация сгруппирована тематически, а не по сложности. Так чо не бросайте на середине :) Чтобы было не очень скучно, буду по возможности развлекать вас картинками.

Итак, поехали!

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

С любезного разрешения сообщества Java-разработчиков JUG.ru мы публикуем видеозапись выступления Андрея Бреслава о новом языке программирования Kotlin для платформы Java, которое состоялось на встрече 26 апреля.