Во многих языках программирования существует возможность объявлять объекты и переменные константными. И, соответственно, существуют рекомендации делать так, если Вы не собираетесь менять их значения. С приходом нового стандарта, в С++ появилась рекомендация возвращать объекты из функций по значению, потому что даже без RVO можно повысить производительность программы, за счет использования семантики перемещения. Что же будет, если использовать эти две рекомендации вместе: вернуть константный объект по значению? Попробуем разобраться далее.

Сервис Foursquare вызывает противоречивые чувства у многих людей. Некоторым все это нравится, и очень много интернет-пользователей отмечают места своего пребывания в конкретный момент времени, завоевывают «мэрства» и т.п. Другим же кажется, что лучшего инструмента для отслеживания действий человека, совместно с некоторыми другими социальными сетями, не найти. Тем не менее, у сервиса миллионы пользователей, которым явно должен понравиться такой инструмент, как «Time Machine»: визуальное отображение всех путешествий пользователя, с инфографикой и спокойной музыкой.

Вот некое простое значение:


И мы знаем, как к нему можно применить функцию:


Элементарно. Так что теперь усложним задание — пусть наше значение имеет контекст. Пока что вы можете думать о контексте просто как о ящике, куда можно положить значение:


Теперь, когда вы примените функцию к этому значению, результаты вы будете получать разные — в зависимости от контекста. Это основная идея, на которой базируются функторы, аппликативные функторы, монады, стрелки и т.п. Тип данных Maybe определяет два связанных контекста:

data Maybe a = Nothing | Just a

Позже мы увидим разницу в поведении функции для Just a против Nothing. Но сначала поговорим о функторах!

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

Сегодня в программе:

• auto
• nullptr
• range-based циклы
• override и final
• строго-типизированный enum
• интеллектуальные указатели
• лямбды
• non-member begin() и end()
• static_assert и классы свойств
• семантика перемещения

CMake — это система сборки ПО (точнее генерации файлов управления сборкой), широко используемая с Qt. При создании больших или сложных проектов, выбор CMake будет более предпочтительным, нежели использование qmake. KDE когда-то был переломным моментом в популярности CMake как таковой, после чего свою «лепту» внес Qt 4. В Qt 5 поддержка CMake была значительно улучшена.

Осенью 2008 года мы потратили две-три недели свободного от основной работы времени, чтобы написать маленькую утилитку для бэкапа баз данных (MS SQL Server и потом MySQL). Сегодня она приносит нам около $230 000 в год и можно с уверенностью говорить, что суммарно мы заработаем на ней больше $1 000 000.

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

В первой части этой статьи основное внимание будет уделено потокам и блокировкам в С++11, условные переменные во всей своей красе будут подробно рассмотрены во второй части…

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

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

Казалось бы, совсем недавно вышел Confluence 5, который принес пользователям уйму новых фич: новое визуальное представление, возможность переключения между приложениями непосредственно из wiki, нотификации о том, что добавлен комментарий либо содержимое страницы кем-либо изменено. Тем не менее, уже ощущается дыхание версии 5.1 Atlassian Confluence, которая направлена на упрощение процесса содания страниц с помощью технологии Blueprints. Blueprints помогает пользователям понять, какое содержимое они хотят создать и показываeт, как это сделать, буквально проводя пользователей за руку до получения готовой к просмотру wiki-страницы.

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

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

Что я понимаю под ритмом? Развитый в себе навык вспоминать и возвращаться к тем или иным темам или вопросам спустя одно и то же время. «Рваность» работы менеджера, постоянное переключение задач, «проблемно-ориентированное» управление — яркий пример, когда этот принцип не соблюдается.

Как же обуздать этот хаос?

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

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

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

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

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

Поиск высококлассных специалистов — один из самых сложных вопросов в бизнесе, связанном с разработкой ПО. Несмотря на все сложности мировой и отечественной экономики, квалифицированных кадров не хватает катастрофически. Количество проектов, требующих высокой квалификации, растет значительно быстрее, чем “зреют” специалисты (разработчик — 2-3 года, ведущий разработчик — плюс 2 года, архитектор решения — плюс 3–5 лет ...).

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

Программисты так не любят совещания по одной причине: они работают по совсем иному графику, чем другие люди. Встречи обходятся им дороже.

Эссе Пола Грэма переведено в Alconost.

Несколько дней назад на Хабре была опубликована статья Энтропия и WinRAR. В ней замечены некоторые неточности, на которые хочется дать развернутый ответ.

Начну с простого — картинка «степень сжатия различных данных». Вот она:



Удивительно, что случайная последовательность чисел сжимается где-то до 60% от исходного объема. Я точно помню, в молодости пытался зиповать сжатое видео и картинки в jpg. Архивы получались практически такого же объема, как оригинал, а иногда и на пару процентов больше! К сожалению, автор статьи не очень подробно описал, как именно он получил свой результат. Степень сжатия его последовательности случайных чисел подозрительно похожа на отношение 10/16 = 0.625.

Я попробовал воспроизвести эксперимент своими силами. Я генерировал файл со случайными символами, а потом сжимал его тем самым winRar’ом, упомянутым в заголовке. Результат таков:

Введение

После продолжительного перерыва мне пришлось вернуться к программированию на C++. После C# очень не хватало ключевого слова var и возможностей построения запросов linq. Однако как оказалось прогресс не стоит на месте и за время моего отсутствия вышла новая версия С++11, имеющая новые интересные возможности, к тому же реализованная в большинстве компиляторов. Я занимался кросс-платформенным проектом и меня интересовали компиляторы GCC для Linux, Visual Studio и mingw для мира Windows. Попытка найти linq-like библиотеку не увенчались успехом, все, что я находил, было нежизнеспособной поделкой на коленке. Смирившись, я бросил поиски, однако в апреле 2012 вышла обнадеживающая статья LINQ to Objects на языке C++, в которой описывалась библиотека, которая мне подходила. Попробовав ее в деле и разобравшись в ее устройстве, я был разочарован неэффективностью, но некоторые идеи я подчерпнул. Оставалось одно – написать такую же, только с блэк-джеком, что я и сделал github.com/drbasic/CppLinq, заодно разобравшись автоматическим выводом типа (auto) и лямбда выражениями.

Проектировалась библиотека так, что бы с помощью fluent-синтаксиса и лямбда выражений пользователь мог построить граф преобразований. Эти графы можно копировать, достраивать, объединять, т.е. реализовать поведение максимально близкое к прообразу Linq to Objects из мира C#. Функционал библиотеки, недолго думая, я позаимствовал из C#, добавив, явный left join и full join. Важным ограничением библиотеки является перемещение по графу преобразования не копий, а указателей на элементы исходной последовательности. Это позволяет эффективно обходиться со сложными элементами коллекций, ведь теперь не происходит накладных расходов на копирование, но исходная последовательность из-за этого не должна быть «виртуальной». Т.е. к началу работы у каждого элемента исходной последовательности должен быть уникальный адрес и элементы не должны перемещаться в памяти во время работы linq-преобразований. В общем, для этого подходят массивы, контейнеры Qt, все стандартные контейнеры, кроме std::bitset. Сложности возникли лишь с константными последовательностями, которые так и не доделал, так как мне они были не особо нужны. Библиотека проверена и успешно компилируется Visual Studio 2010 и 2012, gcc 4.8, mingw 4.8. Проще всего совладать оказалось с компилятором Microsoft, сделать счастливыми gcc было куда сложнее, причем с внутренней ошибкой бывало падали все компиляторы, порой даже без вразумительных криков.

Хай, Хабр!
Сегодня я хочу представить, дорогому хабрасообществу свой первый хабраперевод. Программировать на языке Python — подобно песне. Но еще лучше, когда Ваш код читаем и понятен, а значит чуть более поэтичен, чем обычно бывает производстве. У каждого свои правила и свои стереотипы относительно написания и оформления исходного кода, на каком бы языке он ни был написан. Множество копий сломано о щиты на форумах, но, как ни крути, нельзя не считаться с мнением авторитетных товарищей. Так что сейчас будет представлен перевод первой части стайл-гайда для языка Python от Google. Коснется он именно постулатов написания кода (вторая часть тоже скоро появится, а посвящена она будет форматированию исходного кода). Сразу предупреждаю: тут много (если не большая часть) прописных истин, которые все знают уже давно. Но я искренне надеюсь, что Вы сможете найти тут что-то новое или хотя бы вспомнить старое. Приступим под катом. И pdf тут как тут.

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

Что же мы делали? Мы задумали, как московские «Городские проекты», посчитать пешеходное движение на улице Ленина в Новосибирске. Оказалось, что не занятые в ИТ люди, гораздо лучше могут организовать эту работу.

tl;dr: у нас все работы превращаются в ИТ, даже когда не надо. Ещё мы плохо оцениваем силы — и в нашей работе и в «аналоговой».

Начнём с объяснения, что же такое четырёхмерное пространство.


Это — одномерное пространство, то есть просто ось OX. Любая точка на ней характеризуется одной координатой.


Теперь проведём ось OY перпендикулярно оси OX. Вот и получилось двумерное пространство, то есть плоскость XOY. Любая точка на ней характеризуется двумя координатами — абсциссой и ординатой.


Проведём ось OZ перпендикулярно осям OX и OY. Получится трёхмерное пространство, в котором у любой точки есть абсцисса, ордината и аппликата.


Логично, что четвёртая ось, OQ, должна быть перпендикулярной осям OX, OY и OZ одновременно. Но мы не можем точно построить такую ось, и потому остаётся только попытаться представить её себе. У каждой точки в четырёхмерном пространстве есть четыре координаты: x, y, z и q.

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



Конечно, все очевидно: я обманывал себя постоянным откладыванием на завтра так часто, что мысль «надо бы вернуть книгу» вышла в естественный распорядок дня. Тогда я задумался: как много вещей я откладываю и чем это грозит?

И вот, что я обнаружил:

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

В качестве главного интернет-евангелиста google, Сёрф провел достаточно времени, размышляя о будущем сетевых технологий. И он имеет на это полное право — ведь именно Сёрф, вместе с Бобом Каном (Bob Kahn) был ответственен за разработку TCP/IP. Но, не удовлетворившись своей ролью отца Интернета на этой планете, Сёрф потратил годы на то, чтобы его детище вышло и в космос.

Работая совместно с NASA и JPL, Сёрф помогал разрабатывать новый стек протоколов, который может быть использован в условиях космоса — в которых, учитывая ограничения, связанные со скоростью света, а так же сложности орбитальной механики, — осуществление работы сети становится весьма сложным.

Мы [wired.com, — прим.пер.] пообщались с Сёрфом о роли этого межпланетного Интернета в исследовании космоса, имеющихся на сегодня проблемах, а так же о том, каким ему видится будущее этой технологии.