Группа исследователей из IBM, используя информацию о перемещениях 500 тыс. пользователей мобильной связи, разработали модель для улучшения маршрутов общественного транспорта.

Модель успешно опробовали в городе Абиджан (население 3,8 млн человек, столица Кот-д’Ивуара). На иллюстрации показаны действующие маршруты автобусов (малиновым) и улучшения, предлагаемые алгоритмом (синим). Он предложил 65 возможных улучшений, в том числе три новых маршрута, с общей экономией времени 10% в пассажиро-минутах для всех пассажиров, учитывая время поездки и время ожидания.

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

От переводчика: Брюс Шнайер, специалист мирового уровня по криптографии и информационной безопасности, а так же активный блогер и писатель, опубликовал эту статью в The Guardian после того, как стало известно, насколько плохо на самом деле обстоят дела с безопасностью криптографических технологий, и какую роль в их плачевном состоянии сыграло АНБ.

Неделю назад я перевёл статью Лионеля Дрико "Первая мировая гражданская война" из блога Рикарда Фальквинге, основателя Пиратской партии Швеции, статью эмоциональную и, возможно, слишком резкую. В отличие от пламенных пропагандистов Пиратской партии, Брюс Шнайер всегда был более сдержан и спокоен в оценках, как и подобает авторитетному инженеру и учёному. Но сейчас, похоже, терпение кончилось и у него.

---

Правительство и крупный бизнес предали интернет и нас с вами.

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

Это не тот интернет, который нужен миру, или который был задуман его создателями. Мы должны вернуть его себе. И говоря «мы», я имею в виду сообщество инженеров и программистов.

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

Здравствуйте, уважаемые Хабражители.

Имеется огромное желание вынести на суд сообщества наш прототип будущего сервиса на тему ЖКХ (не распил, а жаль), а также по возможности найти сподвижников и/или инвесторов.

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

Началось все с того, что меня познакомили с главой нашего города. Попросил он разработать для нужд администрации небольшой портал по ежедневному учету потребления энергоресурсов (ЕРЭЦ — единый расчетный энергетический центр). Данные должны были вноситься каждой организацией в ручном режиме. В ДЕЗе имеются сервера на которые собираются эти данные в автоматическом режиме, и соответственно эти данные в дальнейшем планировалось прикрутить к разрабатываемому порталу.
За бутылочкой пива со своим товарищем мы решили взяться за этот проект. Работы начались 15 апреля 2011 года (да — да, нам полгода).
Наша администрация бедная, денег платить не хотела (и не хочет), планировалось собирать абонентскую плату с организаций которые будут вести учет в ЕРЭЦ, а также в дальнейшем за автоматизацию процесса вода данных в этот самый журнал. Планам не суждено было сбыться (по многим причинам).
На данный момент в ЕРЭЦ зарегистрировано 170 организаций, более 100 пользователей, на сегодняшний день ведено более 53 000 показаний с общедомовых приборов учета.
Разработана система отчетов с произвольным выбором периодов, сравнительный отчет позволяет выбрать два периода и сравнить данные по ним.

Ввод данных в ручном режиме:

В продолжение темы Контроллер «Virt2real», или просто — Виртурилка

Итак, первый серьёзный (по нашим меркам) тираж железок успешно прошёл приёмку нами на заводе и официальную растаможку в России. Процент брака основных плат зашкалил за нуль и составил 0.5%. Очень неплохо, мы рассчитывали в худшем на 5-6 процентов брака. К слову, есть мысль отдать одну бракованую железку BarsMonster на вскрытие проца (если он заинтересуется, само собой).

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

В общем, железки уже у нас на руках, теперь начинается самое интресное

В этой статье я расскажу об одном проекте, которым занимаюсь уже довольно продолжительное время и который с некоторых пор доступен широкой публике. Речь идёт о системе управления “умным домом” MajorDoMo (Major Domestic Module), являющейся центральным блоком комплекса программно-аппаратных решений, которые я, в силу своих скромных возможностей, внедряю в своём домашнем хозяйстве.



Но обо всём по порядку…

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

Меня зовут Андрей Кармацкий, и я руковожу работой над дизайном Яндекс.Карт. Весной я ездил в Новосибирск на конференцию Codefest 2013, на которой рассказывал о том, как мы разрабатываем дизайн Яндекс.Карт. Это была хорошая возможность структурировать накопленные знания в небольшую историю, которой хочется поделиться и с вами.

Почему я люблю карты?

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

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



Сегодня, спустя много-много лет, технологии и алгоритмы позволяют творить в картографии невероятные вещи.

Аутентификация пользователей в экосистемах наподобие Google или Envato реализована в виде отдельных сервисов (accounts.google.com, account.envato.com), предоставляющих необходимые данные и токены сайтам-клиентам. В ходе разработки некоторых проектов на Ruby on Rails мне и пришлось столкнуться с подобной задачей. По-научному — single sign-on или технология единого входа.

Нужен был (1) общий сервис для всех сайтов экосистемы, с (2) преимущественно социальной авторизацией, в угоду входу по связке «логин+пароль».
Сервис, (3) аккумулирующий в себе данные из тех социальных сервисов, с помощью которых пользователь входит в систему, и (4) предоставляющий эти данные сайтам-клиентам.

Задача оказалась настолько же интересной, насколько и нестандартной. Началось все с полезной, но уже немного устаревшей статьи — автор предлагал использовать гем omniauth и кастомную стратегию на сайтах клиентах, а на сайте-провайдере — использовать тот же omniauth в связке с devise для аутентификации через соц. сервисы.

Devise в моем случае подходил мало (завязка на логине+пароле), поэтому предпочтение было полностью отдано omniauth. С этого и началось мое маленькое приключение, о ходе которого предлагаю вам ознакомиться в данной статье.

Я давно регулярно читаю Хабр и заметил, что здесь довольно мало внятных статей о локализации ПО, ориентированных на разработчиков. По своему опыту управления проектами локализации я могу сказать, что локализация — это не только перевод строк и адаптация приложения к контексту той или иной страны, но и постоянное противоборство (в идеальных случаях — равноправное взаимодействие) с разработчиками.
В этой статье я постараюсь на примере показать, как можно создать так называемый localization-friendly code, то есть, организовать ресурсы таким образом, чтобы существенно облегчить локализацию приложения, снизив избыточные временные и финансовые затраты.
Сразу же оговорюсь, что речь пойдёт в первую очередь об интернационализации, то есть, об учёте всех лингвистических особенностей на этапе разработки. Если же ресурсы вашего проекта изначально не подразумевали локализацию, а впоследствии вы решились на неё, то их «затачивание» под локализацию может выйти намного дороже, чем доход от неё.

На Хабре не раз обсуждались вопросы локализации/интернационализации приложений. Мы – компания ABBYY Language Services – давно работаем в области лингвистических услуг, сервисов и технологий, и локализацией софта занимаемся постоянно. У нас в этом вопросе накопился значительный опыт, мы решили им поделиться, сделав больший акцент на организации всего процесса. Локализация приложений — более сложная задача, чем принято считать, и подойти к ней можно разными способами: можно изначально создать простой и понятный текст, можно вложиться в крутых переводчиков, которые из любого текста вытянут смысл, можно сделать подготовку и перевод текста «как-нибудь», но посадить сообщество или тестировщиков на выверку финального результата. Необходимо только помнить, что выверка исходного текста делается на одном языке, а выверка результата — на всех языках, т. е. усилий надо затратить в N раз больше.

Вообще, локализация — это по факту открытие еще одного рынка, и понятно, что, при принятии решения о локализации, руководство рассчитывает получить дополнительную прибыль. При этом зачастую в эту самую локализацию вкладывают лишь малую часть от общего бюджета разработки (скажем, порядка 1–2 %). Т.е. расчет идет на то, что, добавив 1 %, можно получить + 50 % дохода. Насколько реалистичными могут быть такие ожидания?

thoughtbot (с маленькой буквы) — одна из ведущих американских консалтинговых фирм, ориентированных на веб разработку с помощью Ruby on Rails. thoughtbot эксплуатирует распространенную в этой среде бизнес-модель, и зарабатывает не только за счет консалтинга, но и за счет своих больших вкладов в Open Source, активного участия в жизни сообщества (например, подкаст Giant Robots Smashing into Other Giant Robots), образовательной деятельности (воркшопы, менторство), внутренних продуктов и литературы.

На их счету до сегодняшнего дня числилось две полноценных книги: The Playbook — исчерпывающий справочник по внутреннему распорядку и трудовым хитростям thoughtbot (бесплатна для изучения на их сайте), и Backbone.js on Rails — не менее исчерпывающее руководство по использованию JS фреймворка Backbone вместе с Ruby on Rails.

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

Сегодня они объявили о начале работы над новой книгой, под названием «Ruby Science. The reference for writing fantastic Rails applications». Более того, начать чтение книги и принять участие в её развитии можно уже сейчас.

Некоторое время назад я прочитал интересный пост, посвященный полезным фрэймворкам и библиотекам для разработки под iOS. С вашего позволения и согласия Coder89 представляю «Полезные штуки для iOS-разработчика часть вторая».

«Хочу программировать под iPhone — говори, что почитать...»
Любимая девушка

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

Под катом книги, видеокурсы и блоги, которые будет полезно прочитать/посмотреть.

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

Написать этот пост меня привлекла эта статья. Многие ее помнят по вот этой картинке.

Статья затрагивает правильную тему, однако с точки зрения математики и здравого смысла она в корне не верна.

Хочу поделиться в вами несколькими трюками, которые помогут сделать работу с Ruby on Rails лучше, быстрее, а также позволят вам много зарабатывать и более лучше одеваться.

Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.

Не так давно Дженна Байлотта написала замечательную статью «Как дизайнерам ужиться с разработчиками», в которой она описывает методы работы в команде, позволяющие дизайнерам и разработчикам добиться лучшей производительности. Я в свое время работал с дизайнерами (а, работая в UI, и с разработчиками) и столкнулся с похожими проблемами, так что мне понятен ее практичный подход. Во время командной работы никогда не помешает уважать труд своих коллег и понимать их способ мышления.

Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.

Эта картинка, если на первый взгляд, выглядит фотографией реального облака в реальных небесах:



Тем не менее на сайте «CSS3D Clouds» объёмное облако вращается, реагируя на движения мыши, и может быть заново (иначе) сгенерировано в любой момент. Ведь на деле оно является итогом применения JavaScript и трёхмерных CSS-преобразований к нескольким копиям одной и той же картинки облака: из них, как из вокселей, формируется более крупное облако.

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

Основанный на трансформациях и переходах CSS3, javascript-фреймворк для создания презентаций impress.js выходит за рамки понятия “слайд” и позволяет строить презентации в открытом, неограниченном трёхмерном пространстве. Источником вдохновения для него послужил сервис prezi.com. Репозиторий impress.js на Гитхабе появился меньше месяца назад, но уже стал одним из самых популярных. Нетерпеливые могут посмотреть небольшую демку здесь, а остальные — создать пример необычной презентации прямо сейчас.

Оглавление

• Часть 1
• Часть 2
• Часть 3
• Часть 4
• Часть 5

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

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

Зачем вам нужен собственный фреймворк? (Why would you like to create your own framework?)

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

1. Что бы изучить низкоуровневую архитектуру современных веб-ориентированных фреймворков, в частности Symfony2 и ее компонентов.
2. Что бы создать фремворк «под ключ» для ваших специфических нужд. (Только прежде убедитесь, что ваши нужды действительно специфические)
3. Для эксперимента ради удовольствия ( научился и забил )
4. Для рефакторинга уже существующих приложений, которые нуждаются в более современных и устоявшихся практических решениях.
5. Что бы доказать что вы это можете (… пусть и с небольшой помощью)