Здравствуйте всем!

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

Удобочитаемый синтаксис, прост в обучении, высокоуровневый язык, Объектно-Ориентированый язык программирования (ООП), мощный, интерактивный режим, масса библиотек. Множество иных плюсов… И это всё в одном языке.
Для начала окунёмся в возможности и узнаем, что же умеет Python?

Введение

Многие интересуются Full-Mesh (или P2P) VPN, хотят использовать их для игр с друзьями, для связи удаленных офисов, серверов, да для чего угодно. Обычные VPN, вроде OpenVPN или PPTP, пропускают весь трафик через центральный сервер, а Full-Mesh соединяются непосредственно с нодами, зачастую пробивая NAT.

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

Зачем что-либо измерять?

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

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

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

А если не приходят, значит метрику можно смело выбросить ;)

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

1. Формирование структуры задач.
2. Поиск литературы в каталогах.
3. Сбор, обработка и систематизация информации.
4. Формирование списка литературы.
5. Составление плана по вехам.
6. Определение предмета исследования.
7. «Summary» для научного руководителя.

Внимание! Данная статья рассчитана на людей, имеющих представление о том, что такое инспекции кода, и желающих внедрить эту методику в своей компании.


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

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

Итак, начнем.

Я хотел написать статью про линейную регрессию, но потом подумал, да ну её, лучше куплю квартиру. И пошёл искать, что предлагают. А предлагают, как оказалось, много чего. В подходящий мне ценовой диапозон попало больше 500 квартир. И что, мне теперь все это просматривать? Ну нееет, программист я в конце концов или не программист. Надо это дело как-то автоматизировать.

В комментариях к статьям N-е число Фибоначчи за O(log N) и Еще один алгоритм вычисления чисел Фибоначчи указывалось на тот факт, что уже 100-е число Фибоначчи не помещается в 4 байта, а в «длинной» арифметике скорость выполнения умножения резко просядет. Более того, были предположения, что примитивное сложение может оказаться быстрее. Я решил сравнить 2 алгоритма — простое сложение и алгоритм с логарифмическим количеством операций — и написал тестовую программу на С. Для «длинной» арифметики использовал библиотеку GMP.

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

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

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

Доброго времени суток, хабролюди!

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

Очень многие жители северо-запада часто ездят в Финляндию за покупками и на отдых. В таких поездках очень не помешал бы нормальный интернет для звонков по СИПу/Skype'у (друзья просят привезти им чего-нибудь вкусненького из магазинов, а по скайпу им можно показать витрину), да и гуглокарты с он-лайн переводчиком очень полезны.

В своей первой же поездке в Лаппенранту я озаботился мобильным интернетом. В Финляндии развита контрактная система, поэтому для приезжих остается только «Prepaid» (т.е. предоплатная система расчётов, которая как раз сильно развита у нас). Вариантов с препейдом в Финляндии три:

1. DNA Dataprepaid, от оператора DNA. Даёт определенное количество трафика на 180 дней на скорости 21 мбит/с
2. SaunalahtiPREPAID, от оператора Elisa. Безлимитка на скорости до 4 мбит/с с оплатой по дням или пакетами на несколько дней.
3. Sonera Easy Prepaid безлимитка за 1.9€/сутки. Со скоростью не очень ясно.

Т.к. я езжу в Финляндию периодически и особые скорости мне не нужны, то меня заинтересовала Saunalahti.

Здравствуйте, уважаемые хабравчане! Это моя вторая статья, и мне хотелось бы поговорить о вычислительной геометрии.

Немного истории

Я являюсь студентом уже 4 курса математического факультета, и до того как я начал заниматься программированием, я считал себя математиком на 100 процентов.

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

Мне очень нравится подход моего преподавателя: «разберись с этой темой, а потом расскажи нам, да так чтоб мы все поняли».

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

Я помню, как долго мучился с этими задачами, чтобы они прошли все тесты на сайте informatics.mccme. Зато теперь я очень рад, что прошел через все испытания и знаю, что же такое задачи вычислительной геометрии.

Дмитрий Фалалеев решил открыть новый медийный проект Terafirrma о российской индустрии стартапов, где будут публиковаться материалы из первых рук, только от непосредственных участников и только по делу. Одним из первых участников стал наш Сергей Белоусов рассказавший о некоторых тонкостях своего подхода к отбору стартапов и ошибках стартаперов.



Итак, вот ключевые проблемы:

— Нет явного лидера. Или, как вариант, лидеров несколько и обязанности между ними не распределены. Первый раз я акцентировал свое внимание на этом года три назад и сейчас могу совершенно точно сказать, что эта ошибка почти на 100% фатальна для проекта. Мы видели самые разные ситуации: начиная командами, где лидеры боролись за власть в ущерб бизнесу, и заканчивая стартапами, которые каждый раз делегировали нам на встречу нового человека – этакий «колхоз». Так или иначе, мы хотим общаться с одним и тем же персонажем, который станет для нас интерфейсом к команде и сможет отвечать на возникающие у нас вопросы и решать проблемы своей компании. Если такого лидера нет, это повод задуматься – в первую очередь, кстати, самому стартапу. Для нас же как для инвесторов вероятность успеха таких вложений очень невысока. Так что делайте выводы.


В любом проекте должен быть свой Брюс Ли. by Aled Lewis

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

Курс этот предназначен прежде всего для junior developer'ов и позволяет повысить уровень аргументации в холиварах на тему «почему PHP (Java, Perl, Bash) отстой».

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

Часть первая: Как появлялись языки и зачем
Часть вторая: Принцип сохранения функционала
Часть третья: Синтаксический сахар или история развития языков

1. Мир пытается оставить тебя тупым. Начиная от банковских платежей и процентов и заканчивая чудо-диетами — из необразованных людей легче вытрясти деньги и ими проще управлять. Занимайтесь самообразованием столько, сколько можете — для того, чтобы быть богатым, независимым и счастливым.

Привет, Хабр!

Буквально совсем недавно мы рассказали об обновленном интерфейсе нашей Эвитерры (с помощью которой можно дешево и быстро покупать любые авиабилеты).

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

Вдобавок, после обновления интерфейса многие стали нас спрашивать: «А зачем вам такой календарь?», «А зачем вам такая большая карта, если на ней показывается только путь от пункта отправления в пункт назначения?».

В предыдущей статье, посвященной анализу производительности целочисленного умножения были получены удивительные результаты, требующие интерпретации, а именно — почему при генерации кода в VS2012 значительно (в 5,5 раз) падает скорость, а в VS2010 такого не наблюдается, в чем секрет быстрого кода?

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

Но команду ADC почему-то не любят компиляторы, причем настолько не любят, что нет простого способа заставить компилятор начать использовать команду ADC вкупе с флажком Carry. Можно, конечно, написать это на ассемблере. Но написание быстрого кода вручную — это непосильная задача, предусмотреть все тонкости и сделать что-то быстрее оптимизирующего компилятора практически невозможно. Еще есть проблема, что в Visual Studio C++ x64 зачем-то отказались от встроенной команды _asm, и чтобы воспользоваться ассемблерными вставками, нужно создавать отдельный ASM-файл, что делать очень не хочется.

На самом деле — нам бы очень пригодился явный intrinsic команды add-with-carry, но Microsoft hard-working создатели компилятора, когда у них спросили об этом напрямую, заявили что add-with-carry intrinsic имеет ограниченное применение и поэтому в текущем компиляторе его нет. Очень и очень зря.

Михаил Лукин из Российского квантового центра осуществил прорыв в постройке квантового компьютера. Ученые смогли достаточно долго сохранить данные в квантовой вычислительной системе — исследователи считают что мы стоим в одном шаге от создания реального квантового компьютера.

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


Лекция в Digital October

Под руководством Лукина группа ученых из Гарвардского университета смогла создать квантовые биты, хранящие информацию в течение примерно 2 секунд. Это примерно на 6 порядков дольше, чем в ходе предыдущих экспериментов. Отдельной особенностью созданного кубита стало то, что он способен работать при комнатной температуре.

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

Большинство существующих квантовых систем создаются на базе сложного и дорогого оборудования, включая установки, охлаждающие систему до абсолютного нуля (-273 по Цельсию). Группа ученых во главе с гарвардским профессором физики Михаилом Лукиным (Mikhail Lukin) использовала алмазы, выращенные в лабораторных условиях.

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

Приступая к написанию тестовой программы для этой статьи я внутренне ожидал, что CPU Intel положит на обе лопатки AMD, так же как и одноименный компилятор без боя победит Visual Studio. Но не все так просто, может быть, на это повлиял выбор программного теста?

Для теста я использовал целочисленное умножение двух 128-ми битных чисел с получением 256-ти битного результата. Тест повторялся 1 млрд раз и занял всего от 12 до 85 секунд. Использовались процессоры AMD FX-8150 3.60GHz и Intel Core i5 2500 3.30GHz. Никакой мультипоточности, никакого разгона.

Использовались компиляторы Intel Parallel Studio XE Version 12.0.0.104 Build 20101006 его более новая реинкарнация 12.1.5.344 Build 20120612, Visual Studio 2010 SP1 и самый современный Visual Studio 2012 (с интерфейсом Metro и CAPSLOCK меню), он же С++ 11.0 Release Candidate. Про опцию -O2 не забываем, она включена у Visual Studio. А для Intel это необязательно, он оптимизирует с -O2 по умолчанию, для Intel включена опция -O3.

DISCLAIMER: Эта заметка подразумевает наличие у читателя базовых знаний о юнит тестах, в чем автор этих строк не сомневается, а также базовых знаний о проектирование по контракту, которые можно пополнить начиная отсюда.

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

Итак, давайте вкратце рассмотрим, в каком именно месте находится пересечение контрактов и юнит тестов, и постараемся ответить на вопрос: являются ли постусловия избыточными при наличии юнит тестов?