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

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

В конце 2012 года мне пришла в голову идея, что нельзя останавливаться на разработке системы только для транспортных средств, нужно мыслить шире. Так в системе появились новые узлы. Я их назвал: Машина, Дорога, Светофор, Сервер.

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

Сегодня Яндекс запустил поиск картинки по загруженному изображению. В этом посте мы хотим рассказать о технологии, которая стоит за этим сервисом, и о том, как её делали.

Технология внутри Яндекса получила название «Сибирь». От CBIR — Content-Based Image Retrieval.

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

Для чего всё это нужно?

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

Это топик-перевод статьи Eller's Algorithm. В ней рассказывается о способе программной генерации лабиринтов. Дальнейшее повествование идет от лица автора.

 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  
|__   |__       __ __|__   |   __|  |  |  |  |
|__   |__   |__|   __ __|   __ __      |     |
|        |  |  |     |  |__      |__|  |  |  |
|__|__|  |  |   __|   __|__   |   __|__|  |__|
|   __|  |     |__ __ __|  |  |__|  |     |  |
|  |  |  |  |__|  |__   |  |   __|__ __|  |  |
|  |__    __    __ __    __|  |   __   |  |  |
|  |  |  |  |      __|  |   __|  |  |__|  |  |
|  |     |     |__   |  |  |  |  |  |__    __|
|  |  |__|__|__ __|  |     |  |  |      __|  |
|__ __|  |  |  |__   |__|   __|     |   __ __|
|   __|  |   __|__      |__   |__|  |__    __|
|  |  |     |  |     |__|  |   __    __|   __|
|   __|  |__ __|__|      __|  |  |     |  |  |
|   __ __   |      __|__|  |__   |  |  |__|  |
|__ __ __|__ __|__ __ __ __ __|__|__|__ __ __|

Алгоритм Эллера позволяет создавать лабиринты, имеющие только один путь между двумя точками. Сам по себе алгоритм очень быстр и использует память эффективнее, чем другие популярные алгоритмы (такие как Prim и Kruskal), требуя памяти пропорционально числу строк. Это позволяет создавать лабиринты большого размера при ограниченных размерах памяти.

Один вечер из жизни первого екатеринбуржского хакспейса. Небольшой рассказ о весьма полезном для всякого самоделкина начинании. Много фото интересного оборудования и проектов, мало слов. В тексте я не постеснялся привести пару ссылок. Хакспейс работает полностью на общественных началах — бесплатный офис в самом центре города, купленное основателями за свой счет совсем не дешевое оборудование. О таком начинании просто обязаны узнать все DIY-шники Екатеринбурга. Под катом 20 больших фотографий.

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

На данный момент мы успели провести уже три занятия и даже съездили на чемпионат по робо-сумо (пока, конечно, в качестве зрителей). Поэтому хочу поделиться своими первыми впечатлениям.

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

Ещё один вариант получения хоть и небольших, но нелишних денег — участие в конкурсах стартапов. Здесь кроме денег можно получить повышенное внимание от тех же инвесторов, СМИ и потенциальных клиентов, дело за малым — занять призовое место.

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

Я пообщался с победителями IDCEE 2010—2012 (до кого удалось достучаться) и спросил, как у них, собственно, дела, и как повлияла на их стартапы победа в конкурсах.

Привет, Хабр!
Аккурат к инициативе поддержки стартапов, озвученной deniskin, мы в ФРИИ продолжаем знакомить сообщество с темой бизнес-инкубаторов и акселераторов. В прошлой статье мы детально разобрали, в чём различие между бизнес-инкубаторами и акселераторами. Сегодня — расскажем о том, куда же, собственно, идти.

Канадский разработчик Питер Нитч (Peter Nitsch) решил разнообразить использование Google StreetView, переведя его в ASCII. Картинка конвертируется в реальном времени и серьезно грузит CPU и GPU. Работает все это на движке WebGL. Ценители ASCII творчества оценят.
PS Есть режим «Matrix», для ностальгирующих.

link: tllabs.io/asciistreetview
source: www.xakep.ru/post/59077

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

Хочу рассмотреть интересную для меня тему создания пользовательского интерфейса. Вероятно, это будет серия статей.

Итак: пользовательский интерфейс…. Что же это такое? Думаю, немаловажная составляющая успешного продукта. Именно то, насколько пользователям будет комфортно работать с тем или иным приложением, определяет дальнейшую судьбу, собственно, приложения и, вероятно, финансового (или не финансового) состояния разработчика.

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

Опубликовано ранее:
Часть 1
Часть 2
Часть 3

Оптимальная сортировка

Поздравляю! Теперь вы знаете о том, как анализировать сложность алгоритмов, что такое асимптотическая оценка и нотация «большое-О». Вы также в курсе, как интуитивно выяснить является ли сложностью алгоритма O( 1 ), O( log( n ) ), O( n ), O( n² ) и так далее. Вы знакомы с символами o, O, ω, Ω, Θ и понятием «наихудшего случая». Если вы добрались до этого места, то моя статья уже выполнила свою задачу.

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

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

Опубликовано ранее:
Часть 1
Часть 2

Логарифмы

Если вы знаете, что такое логарифмы, то можете спокойно пропустить этот раздел. Глава предназначается тем, кто незнаком с данным понятием или пользуется им настолько редко, что уже забыл что там к чему. Логарифмы важны, поскольку они очень часто встречаются при анализе сложности. Логарифм — это операция, которая при применении её к числу делает его гораздо меньше (подобно взятию квадратного корня). Итак, первая вещь, которую вы должны запомнить: логарифм возвращает число, меньшее, чем оригинал. На рисунке справа зелёный график — линейная функция f(n) = n, красный — f(n) = sqrt(n), а наименее быстро возрастающий — f(n) = log(n). Далее: подобно тому, как взятие квадратного корня является операцией, обратной возведению в квадрат, логарифм — обратная операция возведению чего-либо в степень.

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

Опубликовано ранее:
Часть 1

Сложность

Из предыдущей части можно сделать вывод, что если мы сможем отбросить все эти декоративные константы, то говорить об асимптотике функции подсчёта инструкций программы будет очень просто. Фактически, любая программа, не содержащая циклы, имеет f( n ) = 1, потому что в этом случае требуется константное число инструкций (конечно, при отсутствии рекурсии — см. далее). Одиночный цикл от 1 до n, даёт асимптотику f( n ) = n, поскольку до и после цикла выполняет неизменное число команд, а постоянное же количество инструкций внутри цикла выполняется n раз.

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

Введение

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

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

Встречайте корпоративного юзера блога KolibriOS. От имени этого юзера будут публиковаться статьи, написанные авторами-фрилансерами в рамках «Блог KolibriOS ищет авторов», а также участниками проекта, не имеющими пользователя на Хабре, либо не желающими по какой-либо причине публиковать статьи от своего имени.

В качестве первой публикации, предлагаем Вашему вниманию интервью с Сергеем Кузьминым (ник Wildwest), одним из «старожилов» в проекте KolibriOS (на Хабре W__W).

1. Расскажите о себе, кто Вы и откуда? Чем занимаетесь?

Я преподаю в одном из вузов Санкт-Петербурга — веду лабораторные и практикумы, читаю лекции. В науке занимаюсь алгоритмами автоматического анализа видеоинформации для систем компьютерного зрения и прикладного телевидения. Написал больше 40 статей, в прошлом году стал соавтором монографии. С открытия Coursera (весна 2012) слежу за курсами по технике и ИТ: некоторые просто скачиваю в надежде когда-нибудь посмотреть, а на других учусь — получил сертификаты от трех профессоров в области компьютерного зрения — Jitendra Malik, Guillermo Sapiro, Irfan Essa.

2. Как долго Вы в этом проекте?

Я узнал о ней (MenuetOS — прим. редактора) из печатной версии статьи www.comprice.ru/articles/detail.php?ID=43137 во второй половине июля 2003 года.

Через несколько недель я вышел в интернет, зашел на menuet.narod.ru, скачал разные дистрибутивы. Первым я решил запустить немецкий дистрибутив Gerschi (menuet.narod.ru/arch2003_3.htm). Выглядел он очень красочно.

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

Обнаружить, позиционировать (определить местонахождение) и идентифицировать…
Это важно не только при поимке нарушителя. Знать местонахождение конкретного объекта – человека, транспортного средства, груза, определенного предмета необходимо также для эффективного управления процессами, предотвращения чрезвычайных происшествий и ликвидации их последствий, наконец, даже при проведении такой рутинной операции, как инвентаризация, (например, при передаче смены).

К сожалению, в отличие от АСУТП, где информация о параметрах техпроцесса оперативно и точно определяется контрольно измерительной аппаратурой, позиционирование и идентификация подвижных объектов в большинстве случаев не может выполняться без участия человека и свойственных человеку ошибок – вольных или невольных. Будь то девочка со сканером на складе или секьюрити перед десятком-другим мониторов – влияние человеческого фактора неизбежно. А по мере интенсификации и увеличения масштабов производства цена возможной ошибки становится все выше.
Поэтому автоматическая идентификация и позиционирование подвижных объектов без участия человека становится все более актуальной задачей.
О возможных решениях и пойдет речь в этом топике.

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



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

По-моему, эта статья — самое важное, что я в жизни сделал. Не самое сложное, объёмное или интересное, а важное.

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

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

Конференция закончилась всего несколько часов назад, поэтому в голове еще небольшой сумбур от количества и качества полученной информации. Надеюсь, написав этот пост у меня получиться разобраться в собственных мыслях. Сначала будут общие впечатления, затем кратко пробегусь по докладам и закончу мыслями на тему того, о чем говорили на конференции, благо таких мыслей накопилось по ходу прилично. Хотите узнать, о чем сейчас говорят в мире DevOps? Тогда вам под кат. И да, пост будет длинным, но в конце будет бонус-сюрприз).

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

P.S. Международные названия журналов, насколько мне известно, не имеют официальных переводов, поэтому перевод дан по смыслу с указанием оригинального названия

Нидерландская издательская компания Эльзевир (Elsevier) публикует множество самых известных мировых журналов по математике, включая «Успехи математики» («Advances in Mathematics»), «Доклады по математике» («Comptes Rendus Mathematique»), «Дискретная математика» («Discrete Mathematics»), «Европейский журнал по комбинаторике» («The European Journal of Combinatorics»), «История математики» («Historia Mathematica»), «Журнал по алгебре» («Journal of Algebra»), «Журнал теории приближений» («Journal of Approximation Theory»), «Журнал по комбинаторике. Серия А» («Journal of Combinatorics Series A»), «Журнал функционального анализа» («Journal of Functional Analysis»), «Журнал по геометрии и физике» («Journal of Geometry and Physics»), «Журнал математического анализа и его приложений» («Journal of Mathematical Analysis and Applications»), «Журнал по теории чисел» («Journal of Number Theory»), «Топология» («Topology»), «Топология и её приложения» («Topology and its Applications»). В течение многих лет компания подвергается жесткой критике за свою практику ведения бизнеса. Позвольте мне кратко обобщить основные пункты, на которых основана эта критика.

1. Цены издательства непомерно высоки – настолько выше среднего, что просто удивительно, что это так долго сходит издательству с рук.
2. Один из способов, с помощью которого им удается этого добиваться, – это так называемая «продажа пачкой», суть которой в том, что библиотеки не могут выбирать, на какие именно журналы подписаться, они могут выбрать либо большую подборку (сделанную издательством, а не библиотекой) либо вообще ничего. То есть если некоторые из журналов в «пачке» незаменимы для библиотеки, то ей приходится подписываться и по очень высоким ценам на большое число журналов по разным наукам; при этом многие из этих журналов библиотеке вообще не нужны («Журнал хаоса, солитонов и фракталов» являет собой яркий пример периодического издания, которое многие математики считают просто ничтожным, при этом библиотеки по всему миру вынуждены на него подписываться). Учитывая то, что бюджет библиотек часто весьма ограничен, на практике это означает, что из-за этого им просто не хватает средств, чтобы подписаться на многие журналы других издателей, которые гораздо нужнее. В результате страдают не только библиотеки, но и другие издательства, что безусловно, является одной из причин, почему Эльзевир предпочитает эту схему.
3. Если библиотеки пытаются договорится о лучшей сделке, Эльзевир не церемонится с тем, чтобы перекрыть им доступ ко всем журналам.
4. Эльзевир поддерживает многие меры, такие как «Закон о научных работах» ( «Research Works Act» ), которые препятствуют попаданию работ в открытый доступ. Также издательство Эльзевир поддерживало законопроекты SOPA и PIPA и активно их лоббировало.

Я мог бы продолжить, но на этом остановлюсь.

Кажется необъяснимым, почему ситуация продолжает развивается подобным образом. В конце концов, математики (как и другие ученые) жалуются на это уже долгое время. Почему бы им просто не отказаться публиковаться в журналах, издаваемых Эльзевиром?