Более полугода прошло с момента принятия стандарта C++11. В сети можно найти много материалов посвященных новому стандарту, однако большинство из них касаются самых простых возможностей, самых сладких. Я говорю о лямбда-функциях, системе автоматического выведения типов, новых спецификаторах, умных указателях и т.д. Да, это действительно интересные вещи и, можно смело сказать, они одни из самых полезных и часто используемых. Но на них свет клином не сошелся, и новенький C++11 предлагает нам не только их.

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

GNU make — широко известная утилита для автоматической сборки проектов. В мире UNIX она является стандартом де-факто для этой задачи. Являясь не такой популярной среди Windows-разработчиков, тем не менее, привела к появлению таких аналогов, как nmake от Microsoft.

Однако, несмотря на свою популярность, make — во многом ущербный инструмент.

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

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

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

Но статья, на самом деле, не об этом. Я хочу рассказать про две замечательные команды git, которые я недавно для себя открыл. Это git blame и git bisect

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

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

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

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

Amy Editor

Созданый в 2007 Петром Кронторадом (Petr Krontorad), Amy Editor продвинутый редактор с интерфейсом в стиле Mac. Amy Editor имеет в наличие кучу полезных опций, такие как нумерация строк, подсветка синтаксиса, сниппеты для более чем 20 языков, совместное использование и прочее.

» http://www.amyeditor.com

С 2007 года я работаю над созданием странного девайса — носимого компьютера (wearable computer). Поначалу казалось, ничего сложного: ноутбук в рюкзак, дисплей-очки на нос — и вот у тебя какой-никакой, а вполне носимый компьютер, позволяющий развлекаться с дополненной реальностью и прочими любопытными фичами. Главное подобрать подходящее железо — и в путь! Но все оказалось не так-то просто.

Картинки есть (и много), но они долго грузятся (хабра-эффект?) перезаливаю их на habrastorage.org…

Rust — новый экспериментальный язык программирования, разрабатываемый Mozilla. Язык компилируемый и мультипарадигмальный, позиционируется как альтернатива С/С++, что уже само по себе интересно, так как даже претендентов на конкуренцию не так уж и много. Можно вспомнить D Вальтера Брайта или Go от Google.
В Rust поддерживаются функицональное, параллельное, процедурное и объектно-ориентированное программирование, т.е. почти весь спектр реально используемых в прикладном программировании парадигм.

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

Недавно я искал книжку на lib.ru. Наткнулся на раздел «Самиздат». Оказывается, есть очень много пишущих людей, что стало для меня неким откровением. Я поделился этой мыслю со своими боевыми товарищами. Оказалось, что есть не менее популярный ресурс — stihi.ru. После этого родилась мысль сделать социальную сеть для людей пишущих.

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

Elevator pitch — 30 секунд чтобы сказать о главном.

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

Круто? Тогда дальше вас ждет слабоструктурированый поток сознания.

Что такое энерго-эффективность в применении к мобильным платформам? Простыми словами это возможность сделать больше, затратив при этом меньше энергии.

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

Документальный фильм про Стива Джобса и его стартап, компанию NEXT, которую он основал после ухода из Apple. Фильм снят в 1986 году. Перевод на русский язык — канал GTV.



Приятного всем просмотра!

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

Каждый блинчик в меню Теремка — всего лишь набор из примерно 8ми ингредиентов. С такой простой периодической таблицей элементов компания заработала 1.9 млрд долларов в прошлом году (нет, не Теремок, а всё-таки Taco Bell).
Чем больше я программирую и проектирую системы, тем больше я понимаю, что в множестве случаев можно достигнуть желаемого результата банально сочетая базовый набор инструментов, данный нам Unix. В конце концов, функциональность — это ценность, а код — это задолженность. Это утверждение обратно абсурднму тренду DevOps (разработчико-админов), исходя из которого системные администраторы начинают писать юнит-тесты и прочие вещи, чтобы помочь разработчикам, и гласит что программирование в стиле Теремка это разработчики, которые знают достаточно об администрировании (и Unix в целом) так, что они не изобретают велосипед, и приходят к простым и масштабируемым решениям.

Вот конкретный пример: представьте, вам нужно скачать и записать на диск миллионы веб-страниц для дальнейшей обработки. Как это сделать? Детки-крутышки скажут, что нужно написать распределённый паук на Clojure и запустить на EC2, коммуницируя с помощью SQS или 0MQ.

Timsort, в отличии от всяких там «пузырьков» и «вставок», штука относительно новая — изобретен был в 2002 году Тимом Петерсом (в честь него и назван). С тех пор он уже стал стандартным алгоритмом сортировки в Python, OpenJDK 7 и Android JDK 1.5. А чтобы понять почему — достаточно взглянуть на вот эту табличку из Википедии.



Среди, на первый взгляд, огромного выбора в таблице есть всего 7 адекватных алгоритмов (со сложностью O(n logn) в среднем и худшем случае), среди которых только 2 могут похвастаться стабильностью и сложностью O(n) в лучшем случае. Один из этих двух — это давно и хорошо всем известная «Сортировка с помощью двоичного дерева». А вот второй как-раз таки Timsort.

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

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

Суть сводится к тому, что эту команду в виде «make install» или «sudo make install» использовать в современных дистрибутивах нельзя.

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

By Mike Vanier

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

1. Я думаю, что могу объяснить некоторые стороны монад лучше, чем многие другие руководства, которые я видел.
2. Я стал гораздо лучше понимать монады, чем теперь и хочу поделиться по мере сил и возможностей.

Предварительные требования

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

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

Из знакомых мне айтишников очень немногие стараются правильно произносить английские слова. Конечно, привычнее произносить C++ как «си-плюс-плюс», а не «си-плас-плас» или «опен-бэ-эс-дэ», а не «оупэн-би-эс-ди».
Но когда «echo $value;» читают как «ечо валуй» — это уже не смешно. Другой человек вас может просто не понять, особенно иностранец.

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

♫ — прослушать произношение в словаре
► — прослушать произношение на youtube

Начнем с названий:

ABBYY	аби		►
Adobe	эдоуби	[əˈdəʋbɪ]	♫
Apache	эпэчи	[əˈpætʃiː]	►	от «a-patchy»
Asus	офиц. э́сус амер. э́йсус		►
BenQ	бенкью		♫
Cisco	сискоу	[ˈsɪskoʊ]	♫
EBay	ибэй		♫
Eee PC	и писи		►
Ethernet	изэрнэт	[ˈiθərˌnɛt]	♫
Itanium	айтэйниум	[aɪˈteɪniəm]	►
Juniper	джу́нэпэр	[ˈdʒunəpər]	♫
LaTeX	лэйтех лэйтек латех латек	[ˈleɪtɛk] ['leɪtɛx] [ˈlɑːtɛx] [ˈlɑːtɛk]
Linux	офиц. линэкс вар. линукс	[ˈlɪnəks] [ˈlɪnʊks]	►
Mac OS X	мэк оу-эс тэн		►
MySQL	офиц. май-эс-кью-эл вар. май-сиквел		►	как «My Ess Que Ell», см. оф. сайт
nginx	энджин-икс		►	(от engine-x)
PuTTY	пати	[ˈpʌtɪ]		см. оф. сайт
Qt	кьют	[kyut]		см.
TeX	тех тек	[ˈtɛx] [tɛk]		не «текс»
XBox 360	экс-бокс фри сискти		♫
Xen	зен	[ˈzɛn]	♫
Xeon	зион		♫
Xerox	зирокс	[ˈzɪərɒks]	♫
Xilinx	зайлинкс	[ˌzaɪliːŋks]	►
ZyXel	рус. зайксел амер. зайзел		►	см.

Аббревиатуры:

GNU	гну		►	вар. гню
GWT	гвит	[ˈɡwɪt]
ICANN	айкэн		►
IEEE	ай-трипл-и		►	как «I triple E»
ISO	айсо		►
PNG	пинг	[ˈpɪŋ]	♫	как «ping», см. спецификацию
PXE	пикси	[ˈpɪksi]	►
RUP	рап		►
SCSI	скази	['skʌzi]	♫
SOAP	соуп	[soʊp]	►
SQL	эс-кью-эл	[ˈɛsˈkjuˈɛl]		неофиц. «сикуел»
SWF	свиф	[ˈswɪf]		см. спецификацию
WYSIWYG	визивиг	[ˈwɪziˌwɪg]	♫
XAML	зэмл	[ˈzæməl]	►
XUL	зул	[ˈzuːl]
Yii	длинное «и»	[ji:]	►

Обычно аббревиатуры произносятся по правилам английского языка: API — эй-пи-ай, PCMCIA — пи-си-эм-си-ай-эй, OpenBSD — оупен-би-эс-ди и т.д.

Предлагаю вашему вниманию перевод недавнего поста в электронном журнале Queue авторства Poul-Henning Kamp.

Ошиблись ли Кен, Деннис и Брайан при выборе использовать NUL-завершенные текстовые строки?

ИТ стимулирует и реализует современную западную экономику. Соответственно мы часто видим заголовки про ошеломляюще огромные суммы денег, связанные с ошибками в ИТ. Какое же решение, связанное с ИТ или КН [компьютерными науками], является наиболее дорогим?

Ошибки в обработке ошибок являются наиболее распространенным источником ошибок

Бредня, пришедшая в голову при написании этой статьи

Основные баталии по поводу того, что лучше использовать при программировании на C# – исключения или коды возврата для обработки, ушли в далекое прошлое (*), но до сих пор не утихают баталии другого рода: да, хорошо, мы остановились на обработке исключений, но как же нам их обрабатывать «правильно»?

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

Существует множество «за» и «против» такого способа перехвата и обработки исключений, но сегодня я хочу рассмотреть несколько другую тему. А именно тему обеспечения согласованного состояния приложения в свете возникновения исключения – три уровня безопасности исключений.

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

У статьи есть продолжение, которое, по-сути, является её приквэлом.