Как только выпустили Bittorrent Sync, я сразу его стал использовать для резервирования файлов на домашнем компьютере, настроив штатным образом через web-интерфейс. Программа показала себя с наилучшей стороны, и у меня появилось желание использовать её также для копирования резервных копий на серверах…

Я настроил и использую уже около месяца Bitorent Sync в продакшене и готов поделиться некоторыми наблюдениями.

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

Дисклаймер

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

Проверяем хабр

Единственное упоминание о парадоксе Кондорсе (не путать с теоремой Кондорсе о жюри присяжных) есть в комментарии пользователя TimTowdy.

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

Хочу поделиться с сообществом опытом допиливания поддержки русского языка в GVim под Windows 7. GVim — очень мощный текстовый редактор, но в текущей Windows-реализации без тонких настроек он выглядит гадким утёнком по сравнению c GVim под Linux или MacVim.

Что будет в данной статье? Исправление локализации для Unicode в Windows-версии GVim, настройка переключения раскладки клавиатуры, включение проверки орфографии. Предполагается, что вы владеете азами работы в Vim. На хабре уже есть статья, затрагивающая тему поддержки русского языка, и хотя она всё ещё остаётся полезной, но на данный момент немного устарела.

В принципе русский язык в интерфейсе Windows версии GVim работает «из коробки», но есть небольшой нюанс: при выставленном Unicode редактор не отображает кириллицу в сообщениях и меню, поэтому либо приходится переключать GVim на английскую локализацию, либо мириться с этими «кракозябрами» в меню и «ять»-ями в приветствии программы. И это в наше время, когда подавляющие большинство программ и даже стандартный блокнот в Windows по умолчанию работает с Unicode текстом! Ситуация усугубляется ещё тем, что в сети просто нет руководств, как исправить эту проблему. Словно прекрасная девушка, танцующая красивый танец и громко пускающая газы при каждом новом па.

Исправим же это недоразумение!

Из всего, что я делаю или использую сегодня, единственное, что у меня осталось общего с моей первой работой — это написание кода.

Все остальное менялось и изменялось, и изменялось снова.

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

По-настоящему хороший комментарий — тот,
без которого вам удалось обойтись.
Дядюшка Боб

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

• С. Макконнелл, «Совершенный код. Мастер-класс»
• Р. Мартин, «Чистый код. Создание, анализ и рефакторинг»
• Д. Босуэлл, Т. Фаучер, «Читаемый код, или Программирование как искусство»

В офисе моей первой компании висело изображение с логотипом Nike и заглавными буквами JFDI. (JFDI расшифровывается как «Just Frickin' Do It» — «просто, блин, сделай это». Если не совсем очевидно, аббревиатура обыгрывает слоган компании Nike «Just Do It» — «просто сделай это»). Я уверен в том, что для успеха в бизнесе нужно быть в состоянии сделать много чего. Вы постоянно должны принимать решения, а информации никогда не хватает. Это парализует многих. Но не вас.

Переведено в Alconost.

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

Сеть полна предупреждений и предостерегающих повествований об использовании подобного подхода. Есть ужасающие истории о потере данных, исчерпании памяти или людях неспособных эффективно управлять данными в Redis, вы, возможно, интересуетесь «О чём вы вообще думаете?». Так вот, наш рассказ, почему мы всё же решили использовать Redis и как мы преодолели все эти проблемы.

Я совсем не долго изучаю и использую git практически везде, где только можно. Однако, за это время я успел многому научиться и хочу поделиться своим опытом с сообществом.

Я постараюсь донести основные идеи, показать как эта VCS помогает разрабатывать проект. Надеюсь, что после прочтения вы сможете ответить на вопросы:

• можно ли git «подстроить» под тот процесс разработки, который мне нужен?
• будет ли менеджер и заказчик удовлетворён этим процессом?
• будет ли легко работать разработчикам?
• смогут ли новички быстро включиться в процесс?
• можно ли процесс относительно легко и быстро изменить?

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

Примечание переводчика: Оригинал здесь. Все примеры в оригинале написаны на JavaScript, но я решил перевести их на Scheme. Уверен, менее понятно не стало, но зато видна вся красота этого языка.
UPD: добавил ко всем примерам справа еще и оригинальные примеры на JavaScript.


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

Для понимания примеров в этой статье необходимы базовые понятия о функциях в LISP (Scheme). Если вы понимаете, что напечатает этот код, можно смело читать дальше:

(define x 10) (define (f y) (display x) (newline) (display y) (newline) ) (define g f) (f 1) (g 2)

var x = 10; var f = function(y) { console.log(x); console.log(y); } var g = f; f(1); g(2);

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

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

Как же они этого добиваются?

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

Мастер Вэ Ку и разработчик под Вин Ды
Никакой разницы
Мастер Вэ Ку и прислужник Разметки
Мастер Вэ Ку и Мастер Ю Никс
Нет наилучшего инструмента
Сон мастера По У Пэ
Лучший редактор
Отчаяние медленного ученика
Постижение Vimscript
Посвящение Vim

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

Многие из вас наверняка заметили, что я пишу книгу о Zend Framework. Недавно я закончил черновики двух глав: «Архитектура приложений на Zend Framework» и «Понимая Zend Framework». В первой главе объясняется архитектурный шаблон Model-View-Controller (MVC) и причины, по которым он стал стандартом де-факто для веб-приложений. Во второй исследуется связь MVC с компонентами Zend Framework, их структурой и взаимодействием.

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

Эта сторона фреймворков никогда не привлекала особого внимания. И все же именно она лежит в основе целого класса проблем в тех приложениях, которые пытаются использовать MVC по образу и подобию фреймворков для веб-приложений. Более того, попытки донести идею модели до других разработчиков нередко напоминают битье головой о стену. Я не хочу сказать, что все разработчики тупые или не понимают саму идею, просто никто из них (вне зависимости от того, работают они с PHP или нет) не связывает модели с той областью, которая наделяет их смыслом — принципами объектно-ориентированного программирования.

Мы, программисты, — оптимисты. Это проявляется во всем цикле разработки ПО от оценки сроков до написания кода и внедрения. Как показывает моя практика, в разработке ПО законы Мерфи работают в 100% случаев. Несмотря на это, я раз за разом сталкиваюсь с «программистами-оптимистами».

Топ «оптимистичных» допущений:

Chrome Logger это Google Chrome расширение для отладки серверсайд приложений в консоли хрома.

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

Инструкции по применению инсайд.

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

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

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

Один из самых известных Unix-программистов Мигель де Икаса (основатель проектов GNOME и Mono) в своём блоге дал парочку советов, как повысить продуктивность работы в шелле Unix. Он говорит, что иногда встречает молодых хакеров и бывает поражён, насколько мало трюков они знают.

Мигель де Икаса рекомендует ликбез по-быстрому:

1. Прочитать «Unix. Программное окружение» Кернигана и Пайка [русское издание], займёт несколько дней, от силы неделю. Книжка очень старая (1984), но лучше всех разъясняет автоматизацию различных действий в консоли. Вторая книжка — UNIX for the Impatient, чтобы прокачать навыки.

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

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

Под катом приводится краткое описание одного из самых известных генетических алгоритмов вещественной оптимизации — алгоритма дифференциальной эволюции (Differential Evolution, DE). Для сложных задач оптимизации функции n переменных этот алгоритм обладает настолько хорошими свойствами, что зачастую может рассматриваться как готовый «строительный блок» при решении многих задач идентификации и распознавания образов.

К хорошим постам «Код в стиле «дамп потока сознания»» и «Микро-рефакторинг, о котором мы так часто забываем».

• Почему большинство программистов не любят «читать чужой код»?
• Почему рефакторинг и внесение изменений становятся серьезной проблемой?
• Почему так часто случается, что легче переписать с нуля?
• Почему одни программисты называют других хорошими или плохими словами?

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

Если ты всегда мечтал написать свой язык программирования — добро пожаловать. Здесь ты наверняка найдёшь для себя что-нибудь интересное.

GitHub-юзер yawnt собрал чудесную подборку ссылок для любителей драконов, языков и прочих вкусных внутренностей. А знающие камрады в комментариях наверняка поделятся с тобой и другими яствами.

Пишет yawnt следующее:

С каждым днём мне всё интереснее тема компиляторов, интерпретаторов и дизайна языков программирования в целом. И я решил поделиться с народом ссылками на собранные мной материалы (большую часть мне самому ещё предстоит прочитать :<). Надеюсь, кому-нибудь они окажутся полезными.

Я не включил (и не собираюсь) в список ссылки на официальную документацию, т. к. считаю очевидным, что первым делом следует смотреть именно туда ;P.