Toshiba объявляет о пополнении семейства внешних жестких дисков линейками STOR.E ALU 2S и STOR.E STEEL S.

Линейка накопителей STOR.E ALU 2S в форм-факторах 2,5 дюйма и 3,5 дюйма включает модели емкостью 500 ГБ, 640 ГБ, 750 ГБ и 1 ТБ (2,5 дюйма) и 1 ТБ, 1,5 ТБ и 2 ТБ (3,5 дюйма).

В свою очередь STOR.E STEEL S включает модели в форм-факторе 2,5 дюйма емкостью 500 ГБ, 640 ГБ, 750 ГБ и 1 ТБ.

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

STOR.E ALU 2S:



STOR.E STEEL S:



Накопители будут доступны в нескольких цветах. Сроки начала продаж и стоимость пока не объявлены.

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

Основы

Мы начнём с несложного обзора модульного подхода, хорошо известного с тех пор, как Эрик Миралья (Eric Miraglia) из YUI впервые об этом написал. Если вам уже знаком модульный подход, переходите сразу к «Продвинутым техникам».

Анонимные замыкания

Скорость загрузки веб-сайтов всегда была важной темой, но стала еще более актуальной с апреля 2010 года, когда Google стал учитывать её при ранжировании сайтов в поисковой выдаче. Однако, основной уклон, как правило, делался на уменьшении размера файлов, оптимизации параметров сервера, CSS и Javascript.
Также имеет место еще один немаловажный фактор. Это скорость, с которой веб-страницы формируются на сервере. Большинство крупных современных сайтов хранит всю информацию в базах данных и используют различные языки (например, PHP или ASP) для её извлечения, формирования HTML-страницы и отправки её браузеру.

Чешский студент из британского университета Суррея Зденек Катал (Zdenek Kalal) в рамках практической части кандидатской диссертации разработал алгоритм Tracking-Learning-Detection (aka Predator) для отслеживания объектов в видеопотоке с самообучением (точность распознавания улучшается с каждым фреймом).

Демо проекта

Исходные коды на github: 1, 2, 3, 4, 5

Продолжаем тему операторов, на этот раз вас ждет рассказ об операторе запятая.

Начнем с забавного твита:



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

Что она делает?

Оператор запятая выполняет оба операнда (слева направо) и возвращает значение второго оператора. (MDC)

var a = (7, 5);
a; //5

var x, y, z
x = (y=1, z=4);
x; //4
y; //1
z; //4

В 2008 году будущая команда «Мосигры» начала воплощать свою давнюю мечту по изданию качественной отечественной настольной игры. С продажи первой партии «Шакала» началась история розничной сети. Сначала мы открыли интернет-магазин, потом магазин в реале, а затем за два года построили сеть, покрывающую крупнейшие города России, Украины, Беларуси и Казахстана.

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

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

А теперь медленно и по порядку.

Без использования unit-тестов и TDD очень легко выстрелить себе в ногу. С тестами и TDD сделать это намного сложнее, но если у вас получится, вы останетесь без ноги.

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

В этой статье я постараюсь объяснить о чем, собственно, разговор. Для чего нужно TDD и как его аккуратно использовать.

Что такое TDD в двух словах? — это написание разработчиком тестов до реализации функциональности.
По совету Роя Ошерова разобьем вопрос применимости TDD на два:

• Зачем писать тесты?
• Зачем писать тесты до реализации?

Большинство людей не умеют писать unit-тесты. И даже те, кто применяет модульные тесты в ежедневной разработке, зачастую признают, что получившиеся тесты иногда не очень эффективны по определенным причинам. К этой категории людей я могу отнести и себя. В первую очередь, такой «причиной» является некоторая появляющаяся «инертность» кода, заключающаяся в том, что если требуется немного изменить какой-то ключевой алгоритм, добавить пару строчек кода, то при этом «падают» ~100 модульных тестов и приходится тратить продолжительное время на то чтобы заставить их работать вновь. Итак, приступим к «хорошим рекомендациям» при написании автоматических модульных тестов. Нет, я не буду капитаном очевидностью, в очередной раз описывая популярный стиль написания тестов под названием AAA (Arange-Act-Assert). Зато попытаюсь объяснить, чем отличается Mock от Stub-а и что далеко не все тестовые объекты — «моки».

Релиз django 1.3 совсем скоро. Думаю, многие уже RC в продакшне используют. Но все равно, пробегусь еще раз по тому, что нас ждет, стараясь не скатиться в перевод release notes.

Жизнь — дерьмовая штука. По крайней мере, так считают многие «взрослые» люди, с которыми мне довелось общаться. Они постоянно жалуются на свою работу, неудовлетворительные отношения и раздолбаев-детей, которые никак не хотят становиться такими, какими хотят их видеть родители. Жизнь для этих людей — это бесконечная карусель разочарований, неприятностей и несбывшихся надежд. Они встают рано утром с больной головой, заливают в рот пару литров кофе и едут на работу в состоянии, которому позавидовали бы самые отъявленные зомби. Они ненавидят свою работу и считают, что их занятия бессмысленны и никому не нужны. Но, не смотря на это, они с упорством леммингов продолжают делать эту работу, день за днём, год за годом. Они продираются сквозь собственную жизнь, надеясь, что всласть поживут потом, когда отработают 10-20-30 лет. Так вот, это всё херня. Когда вам будет пятьдесят, вы настолько устанете от такой жизни, что единственным вашим желанием будет лечь и сдохнуть. Да и здоровье будет уже не то, потому что вы слили его, занимаясь всякой ерундой, до которой вам даже не было дела. Так что, когда вы выйдете на пенсию, вы не поедете в Африку охотиться на львов, потому что солнце плохо сказывается на вашем давлении. Вы также не поедете на Северный полюс, потому что у вас артрит и холод — не лучшее для него лекарство. Южный полюс отпадает ещё и потому, что вы недолюбливаете пингвинов, что неудивительно, учитывая ваш 30-летний стаж работы сисадмином. Так что же вам остаётся? Поездки на дачу и вечера в уютной компании телевизора, вот что. Прожив 30 лет в постоянной борьбе с самим собой, у вас просто не останется сил на то, чтобы оторвать задницу от дивана.

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

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

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

HTML5 Boilerplate это удобный шаблон для HTML5 проектов, а так же квинтесенция полезных и удобных техник для создания качественных сайтов.

— появилась возможность собрать «HTML5 Boilerplate» под себя.
— уменьшен общий размер.
— на сайте появилась документация.
— …

Подробнее в блоге Пола Айриша или на сайте проекта HTML5 Boilerplate.

Начав писать топик про мои извращения с TeX-ом понял, что очень недостаёт нормальной подсветки синтаксиса. Гугление по Хабру и окрестностям навело на пару редакторов, которые у меня не заработали и описание подрихтованного formatter-а для pygments.
Решив «а чем я хуже», набросал «на коленке» скрипт на python-е, который мне код-то и раскрашивает.

Так получилось, что на хабре принято подсвечивать код с помощью Source Code Highlighter. Список поддерживаемых языков не впечатляет, да и возможности выбрать цветовую схему я не нашел. Существует библиотека pygments, которая понимает большинство используемых языков, умеет выдавать на выходе html, картинки, latex и не только. Но для хабры, как известно, нужен особый подход, и html вывод pygments хабра не пропускает. В связи с этим я написал небольшой класс для pygments, который исправляет это досадное недоразумение. Воспользоваться веб-версией можно по адресу paste.ly.

Хабрапитонерам привет!

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

Сейчас я хочу понегодовать на паттерн «все настройки — в settings.py». Понятно, что популярность он набрал благодаря Django. Я то и дело встречаю в проектах, никак не завязанных на этот фреймворк ту же самую историю: большая кодовая база, маленькие, хорошенькие никак не связанные друг с другом компоненты, и нате вам: все дружно из произвольных мест лезут в волшебный недомодуль settings за своими константами.

Итак, почему же такой подход на мой взгляд отвратителен.

Добрый вечер, трепетно следящие за правильностью постов хабралюди.

Кто чем занимается воскресным днём, а я решил написать небольшое расширение для Google Chrome, которое, возможно, немного облегчит вам жизнь.

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

Работает оно достаточно привычным, благодаря системе orphus, способом: выделяем слово, в котором есть опечатка, нажимаем заветные Ctrl+Enter, открывается окно отправки сообщения автору, где большая часть текста уже написана автоматически, нам остаётся только подсказать автору правильный вариант. В настройках расширения вы можете задать шаблон для темы и текста сообщения.

Собственно, ссылка на расширение в галерее — тыц.
Исходный код в bitbucket — здесь.

P.S. Буду рад, если кто-нибудь согласится собрать расширение для Firefox и Opera.
P.P.S. Можете проверить работу расширения прямо на этом посте ;)

UPD: как это часто бывает, идея приходит сразу нескольким людям. Уже сделано расширение с похожим функционалом — ХабраГрамотность. Возможно оно вам покажется лучше.
UPD2: обнаруженные ошибки постараюсь за сегодня исправить. Спасибо за отчёты.

Регулярные выражения (РВ) это, по существу, крошечный язык программирования, встроенный в Python и доступный при помощи модуля re. Используя его, вы указывается правила для множества возможных строк, которые вы хотите проверить; это множество может содержать английские фразы, или адреса электронной почты, или TeX команды, или все что угодно. С помощью РВ вы можете задавать вопросы, такие как «Соответствует ли эта строка шаблону?», или «Совпадает ли шаблон где-нибудь с этой строкой?». Вы можете также использовать регулярные выражения, чтобы изменить строку или разбить ее на части различными способами.

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

• создать паука, выполняющего GET запросы,
• извлекать данные из HTML документа,
• обрабатывать и экспортировать данные.

Столкнувшись с вопросом выбора базы данных для проекта, провел небольшое исследование Google App Engine на предмет скорости работы с данными. Результаты исследования оформил в виде таблиц.

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

JavaScript Garden — справочник на английском, посвященный тонкостям JavaScript.

Из него я, например, узнал, что массивам можно задавать length:

var list = [1, 2, 3, 4, 5];
list.length = 3;
console.log(list); // => [1, 2, 3]