Редкое видео с молодым Стивом Джобсом, снятое в 1980 году. Профессиональный русский перевод.

Леонардо да Винчи известен тем, что за свою жизнь успел сделать много важных открытий, создать много важных изобретений и внести свой незабываемый вклад в развитие человечества. Как ему это удалось? Может быть, он был гениален и все открытия-изобретения давались ему без труда. Может быть, он мало спал, не больше 4 часов в день, а остальное время работал не покладая рук. Может быть еще десяток других версий и их совокупность. Но историк Тоби Лестер (Toby Lester) перевел на английский язык (со своими пояснениями в скобках) To-Do лист конца 15 века (примерно 1490-е года) из блокнота Леонардо да Винчи.
Картинка (большая) под катом.

Вчера Karl Seguin – автор книги The Little MongoDB Book, которую часто рекомендуют для быстрого старта с MongoDB, опубликовал аналогичное руководство для Redis под названием The Little Redis Book (при участии Perry Neal). Книга состоит из 29 страниц, написанных за 2 коротких дня с использованием Markdown. Исходная разметка книги находится на GitHub. Сама книга распространяется свободно под лицензией Attribution-NonCommercial 3.0 Unported license.

Содержание книги

• About This Book
• Introduction
• Chapter 1 — The Basics
• Chapter 2 — The Data Structures
• Chapter 3 — Leveraging Data Structures
• Chapter 4 — Beyond The Data Structures
• Chapter 5 — Administration
• Conclusion

Скачать

The Little Redis Book (PDF)

Компания Google опубликовала ряд рекомендаций, как уменьшить задержку (latency) для TCP-соединений между веб-сервером и браузером. В этих рекомендациях обобщаются исследования, которые компания вела в течение нескольких лет.

1. Увеличьте первоначальный размер congestion window до 10 (IW10). Сейчас в начале TCP-соединения отправляется три пакета данных в три раунда (RTT) для передачи небольшой информации (15 КБ). Наши эксперименты показывают, что IW10 уменьшает сетевую задержку для веб-соединений более чем на 10%.

2. Уменьшите первоначальный таймаут с 3 секунд до 1 секунды. RTT в 3 секунды был приемлем пару десятилетий назад, но в современном интернете нужен гораздо меньший таймаут. Наше обоснование для этого хорошо задокументировано здесь.

Данная мини-заметка в первую очередь является ответом на вопрос. Так как мой аккаунт read-only, то вот такой вот способ ответа. «А жизнь-то налаживается!» ©

Первый вывод после прочтения вопроса и ответов — не делайте так, как предложил defuz. Он не понимает суть проблемы, и если вы сделаете как им предложено — скорее всего, вы потеряете данные.
Второй: alekciy тоже не совсем прав, но тут шансов на потерю данных гораздо меньше. Почти никаких.
Ну и третий: блин, ну когда же люди поймут, что владеть используемым инструментом это реально необходимо? Читайте документацию!

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

Почему же для устранения смаза и расфокусировки практически ничего нету (unsharp mask не в счет) – может быть это в принципе невозможно? На самом деле возможно – соответствующий математический аппарат начал разрабатываться примерно 70 лет назад, но, как и для многих других алгоритмов обработки изображений, все это нашло широкое применение только в недавнее время. Вот, в качестве демонстрации вау-эффекта, пара картинок:



Я не стал использовать замученную Лену, а нашел свою фотку Венеции. Правое изображение честно получено из левого, причем без использования ухищрений типа 48-битного формата (в этом случае будет 100% восстановление исходного изображения) – слева самый обычный PNG, размытый искусственно. Результат впечатляет… но на практике не все так просто. Под катом подробный обзор теории и практические результаты.
Осторожно, много картинок в формате PNG!

В Django версии 1.3 были представлены class-based views — способ описания view в виде классов. Документация, однако, касается только generic views, не описывая общую технику написания «вьюх» в виде классов. Начав использовать generic views и затем пытаясь изменить их поведение, я постепенно дошел до того момента, когда мне пришлось смотреть исходный код, чтобы понять, как что-то сделать. Поэтому я решил написать этот текст. Цель его — объяснить, как использовать class-based view и чем это может быть полезно.

Почитал я немного про автовыставку в Детройте, про то, что Lane Departure Warning становится все более и более популярным и решил, что надо бы поделиться своим опытом изготовления прототипа этой системы из нехитрых компонентов в виде веб-камеры, Питона, OpenCV и пары дней усердной медитации:)

Историю создания прототипа можно почитать и посмотреть под катом… (там картинки, много...)

Анти-паттерны — полная противоположность паттернам. Если паттерны проектирования —
это примеры практик хорошего программирования, то есть шаблоны решения определённых задач. То анти-паттерны — их полная противоположность, это — шаблоны ошибок, которые совершаются при решении различных задач. Частью практик хорошего программирования является именно избежание анти-паттернов. Не надо думать, что это такая непонятная теоретическая фигня — это конкретные проблемы, с которыми сталкивался практически каждый разработчик. Кто осведомлен, тот и вооружён! Рассмотрим же несколько расрпотранённых анти-паттернов в программировании.

Большинство литературы посвященной паттернам в ООП (объектно-ориентированном программировании), как правило, объясняются на примерах с самим кодом. И это правильный подход, так как паттерны ООП уже по-умолчанию предназначаются для людей, которые знают что такое программирование и суть ООП. Однако порой требуется заинтересовать этой темой людей, которые в этом совершенно ничего не понимают, например «не-программистов» или же просто начинающих «компьютерщиков». Именно с этой целью и был подготовлен данный материал, который призван объяснить человеку любого уровня знаний, что такое паттерн ООП и, возможно, привлечет в ряды программистов новых «адептов», ведь программирование это на самом деле очень интересно.
Статья предназначена исключительно для новичков, так что «старожилы» ничего нового для себя не узнают. В основном статья описывает известные паттерны из книги «Приемы объектно-ориентированного программирования. Шаблоны проектирования.», но более популярным и простым языком.

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

И самое интересное: подходы, используемые при написании этой программы, будут интересны не столько академически, сколько практически — при разработке программы с использованием этих подходов разработка будет проще и удобнее (хоть поначалу и чуточку непривычно), а программа будет эффективнее, чем без них.

Впрочем, это звучит страшнее, чем является.

На Хабре уже есть несколько статей\переводов, в которых рассказывается о неизвестных фичах\тонкостях\возможностях Пайтона. Я буду пытаться не повторять их, а дополнять, но если уж так случилось, что вы это уже где-то видели — не огорчайтесь. Я уверен, что найдется что-то интересное и для вас.

Прослушав вебинар «How Google Tests Software» я был так вдохновлен, что решил записать некоторые тезисы. Эта статья и есть мой конспект. Прежде всего, я должен внести ясность относительно ее содержания. Это не дословный перевод. Здесь описаны только те вещи, которые показались мне важными. Проще говоря, здесь описано не все, что прозвучало в вебинаре. Так же существует вероятность, что я понял что-то не до конца или даже понял неправильно. Поэтому горячо рекомендую прослушать вебинар самостоятельно.
Его ведет Джэймс Витакер, который в данный момент занимает пост технического директора по тестированию ПО в Google. Джэймс совместно с коллегами готовится выпустить одноименную книгу. В ней можно будет получить исчерпывающую информацию о том, как проводят тестирование GoogleMaps, Google+, ChromeOS, Android и т.д…

Дорогой Хабр!



У нас для тебя небольшой подарок. Мы тут работали-работали и вот чего сделали.
Сняли и опубликовали почти тысячу лекций по IT и математике.

UPD2 Помогите, пожалуйста, оперативно решить вопрос насчёт организации торрентов на php.

Описание задачи

В связи с сложившейся ситуацией с поддержкой (а точнее ее отсутствием) технологии Flash на iOS, меня попросили проверить возможность реализации игр с богатой графикой на “чистых” браузерных технологиях. Честно говоря, Flash далеко не самая моя любимая платформа (так как является закрытым продуктом Adobe, а не open source), что лишь добавило мне мотивации показать, что возможны хорошие результаты и без нее...

Цель статьи рассказать о своем поиске «идеального» редактора для python кода, о том почему выбрал emacs и кратко о том как я его (emacs) настроил для работы с python.

Небольшая предистория: Разработкой на python я занимаюсь уже более двух лет и все это время пытался подобрать оптимальный редактор. Что я только не использовал за это время — mcedit, nano, gedit, netbeans, eclipse, а также некоторые другие платные варианты (демо версии). Но всегда чего то нехватало, где то автокомплита, где то подсветки, где то банально неудобно. Какой то период (около 10 месяцев) использовал Eclipse, но его прожорливость в ресурсах, зависания доводили до белого каления. Когда ошибки eclipse мне окончательно надоели, я начал поиски такого редактора который стал бы отличным помошником в работе.
Вооружившись google начал искать «идеальный» редактор.

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

Я не люблю CSS. Он простой и понятный. Это движущая сила Интернета, но он слишком ограниченный и им трудно управлять. Пришло время привести этот язык в порядок и сделать его более полезным, используя динамический CSS при помощи LESS.
Объясню свою позицию на примере. Почему бы вместо использования #FF9F94 для получения темно-персикового цвета просто не хранить значение этого цвета в переменной для её последующего использования? Что бы перекрасить сайт достаточно будет изменить значение переменной всего в одном месте и всё.
Другими словами: это будет очень изящно, если мы будем использовать немного программирования и логики в CSS, что бы сделать его более мощным инструментом. Хорошо, что это всё возможно с использованием LESS.