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



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

Доброй пятницы, уважаемый хабр!

Думаю, многие хабравчане проводят какую-то часть своего досуга за компьютерными играми. И если дело касается игр последних лет, то проблем нет, лишь бы мощности компьютера хватало. Но со старыми играми всё не так просто.

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

Предположим, что ваша любимая игра все же запустилась. Сначала радости нет предела. Но только до тех пор, пока вы не обнаружите, что максимальное доступное разрешение — 1024х768, а то и вовсе 800х600. На современном мониторе это означает огромные элементы GUI игры, смазанную картинку, а если монитор широкоформатный — еще и сильно искаженные, «пузатые» пропорции. Некоторых фанатов такие мелочи, конечно же, не смущают. Но зачем отказывать себе в максимальном удовольствии от игры, если решить проблему не так уж и сложно?

Под катом — способ запустить с современным разрешением некоторые популярные игры начала 2000х.

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

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

Мне часто задают вопрос: «Как ты находишь время?». Чаще всего речь идет об open source, иногда о книгах, изредка — о других вещах. Обычно я уклонялся от ответа чем-нибудь вроде: «Блин, не знаю, просто беру и нахожу». Но этот ответ не слишком полезен. Да и мне было интересно, смогу ли я справляться со временем еще лучше. Так что я немного порефлексировал, и вот как я нахожу время:

Rebase — один из двух способов объединить изменения, сделанные в одной ветке, с другой веткой. Начинающие и даже опытные пользователи git иногда испытывают нежелание пользоваться ей, так как не видят смысла осваивать еще один способ объединять изменения, когда уже и так прекрасно владеют операцией merge. В этой статье я бы хотел подробно разобрать теорию и практику использования rebase.

Теория

Итак, освежим теоретические знания о том, что же такое rebase. Для начала вкратце — у вас есть две ветки — master и feature, обе локальные, feature была создана от master в состоянии A и содержит в себе коммиты C, D и E. В ветку master после отделения от нее ветки feature был сделан 1 коммит B.

Это перевод статьи «How to trick C/C++ compilers into generating terrible code?», автор оригинала — Aater Suleman.

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

Дейл Риз — один из разработчиков PHP-фреймворка Laravel — выложил на Гитхаб весьма приятную подборку цветовых схем, совместимую с Sublime Text 2, Vim и TextMate. В неё входят преимущественно тёмные темы (21 из 25), и, что бывает не так уж часто, практически все они выглядят очень прилично — есть из чего выбрать. Инструкции по установке и скриншоты каждой темы — в репозитории.
Под катом — скриншоты всех 25 схем.

Администраторам Linux писать скрипты на Bash приходится регулярно. Ниже я привожу советы, как можно ускорить эту работу, а также повысить надежность скриптов.

Совет 1

Не пишите скриптов, которые выполняют действия ничего не спрашивая. Такие скрипты нужны довольно редко. А вот всевозможного «добра» для копирования, синхронизации, запуска чего-либо, хоть отбавляй. И если в любимом Midnight Commander Вы вдруг нажали не на тот скрипт, то с системой может произойти все что угодно. Это как правила дорожного движения — «написано кровью».

Совет 2

Отталкиваясь от предыдущего, в начало каждого скрипта неплохо помещать что-то вроде:

read -n 1 -p "Ты уверен, что хочешь запустить это (y/[a]): " AMSURE 
[ "$AMSURE" = "y" ] || exit
echo "" 1>&2

Команда echo, кстати, здесь нужна потому, что после нажатия кнопки <y> у вас не будет перевода строки, следовательно, следующий любой вывод пойдет в эту же строку.

Совет 3

Это ключевой совет из всех. Для того, чтобы не писать каждый раз одно и то же — пользуйтесь библиотеками функций. Прочитав много статей по Bash, я вынужден констатировать, что этой теме уделяется мало внимания. Возможно в силу очевидности. Однако я считаю необходимым напомнить об этом. Итак.
Заведите свою библиотеку функций, например myfunc.sh и положите ее, например в /usr/bin. При написании скриптов она не только поможет сократить ваш труд, но и позволит одним махом доработать множество скриптов, если Вы улучшите какую-либо функцию.
Например, в свете совета 2 можно написать такую функцию:

Введение

Современный темп разработки ПО просто поражает своей скоростью. Функционал всегда «нужен вчера». Зачем? Конкуренция — обойдут, обгонят. Времени тестировать нет, надо отгружать функционал, надо, надо, надо.

На помощь командам разработки приходят практики, методологии, подходы и четкие регламенты. Попробую сформулировать в виде десяти правил концепцию «спокойной» разработки. А она то вынудит использовать современные методологии разработки ПО. И заказчик спокоен, и нервы свои целы. Profit!

Преамбула

Здравствуйте. Я являюсь главным разработчиком крупнейшего в СНГ сервера Minecraft (не буду рекламировать, кому надо, те знают). Уже почти год мы пишем свою реализацию сервера, рассчитанную на больше чем 40 человек (мы хотим видеть цифру в 500 хотя бы). Пока всё было удачно, но последнее время система начала упираться в то, что из-за не самой удачной реализации сети (1 поток на ввод, 1 на вывод + 1 на обработку), при 300 игроках онлайн работает более 980 потоков (+ системные), что в сочетании с производительностью дефолтного io Явы даёт огромное падение производительности, и уже при 100 игроках сервер в основном занимается тем, что пишет/читает в/из сети.

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

Здесь я постараюсь расписать серверную часть работы с сетью через Netty, может быть это кому-то будет полезно.

Те, кто мог видеть мою прошлую статью (а она довольно related к данной теме), знают, что вот уже больше полутора лет я разрабатываю собственную реализацию сервера Minecraft, рассчитанную, в первую очередь, на высокие нагрузки. Тем не менее, в своей работе мы используем так же и стандартный сервер (Bukkit) для нескольких мини-серверов, просто чтобы было разнообразие. И вот, столкнувшись с очередной версией сервера, которая стала раз в 5 хуже предыдущих, я уже не выдержала, и решила написать эту статью.

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

Вам не нужно знать ничего о майнкрафте и особенно о его сервере, в данной статье я хочу просто рассказать, как работает оригинальный сервер Minecraft, а так же его «обвязка» — Bukkit, рассказать, почему такая система не работает и не должна. Я не претендую на идеальные знания о разработке серверов и не утверждаю, что мой сервер написан правильно и лучше всех. Я просто делюсь своим опытом, основанным на двух годах работы с сервером от всем известной Mojang и на полутора годах разработки своего сервера. Вся представленная здесь информация является моим личным мнением, а статья предназначена для расширения кругозора или даже обучения и может быть интересна как новичкам, так и продвинутым профессионалам.

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

Вкратце, задача была такой — есть некий робот на С++, обдирающий HTML страницы, и собранное складывающий в БД (MySQL). С массой функционала и вебом на LAMP — но это к повествованию отношения не имеет.

Предыдущая команда умудрилась на 4-ядерном Xeon в облаке получить фантастическую скорость сбора аж в 2 страницы в секунду, при 100% утилизации CPU как сборщика, так и БД на отдельном таком же сервере.

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

Речь пойдет про использование контейнеров LXC, причем внутри другой виртуальной машины.

Abstract: рассказ о том, как быстро и красиво делать обработку списков в шелле, немного мануала по xargs и много воды про философию то ли программирования, то ли администрирования.

Немного SEO-оптимизации: карринг, лямбда-функция, композиция функций, map, фильтрация списка, работа с множествами в шелле.

Пример

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

Это не реальная «задача», это учебный пример, решая который (в решении будет однострочник) я расскажу про очень необычный и мощный инструмент системного администрирования — линейное функциональное программирование. Линейное оно, потому что использование пайпа "|" это линейное программирование, а использование xargs позволяет превратить сложную программу с вложенными циклами в однострочник функционального вида. Целью статьи будет не показать «как найти размер библиотек» и не пересказать аргументы xargs, а объяснить дух решения, пояснить стоящую за ним философию.

Лирика

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

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

Даже словами видно, что второй вариант короче.

Есть такая библиотека knockout.js. Она отличается от прочих хорошим туториалом для начинающих и кучей понятных рабочих примеров. Еще там стройная MVVM модель, декларативные связи и так далее.

Короче, если вы, как и я, поиграли с этой библиотекой, понаписали красивых формочек, и вам это понравилось, то все это дело захотелось применить на реальном проекте. И тут проблема — в реальном проекте формочек больше чем одна. А раз такие инструменты, то хочется single web page application и никак иначе. А делать один контроллер и все темплейты заверстывать на одну страницу тоже тупо и тормозно.

Под катом приведу основу своего сложного приложения. Само оно совсем не сложное, но модульное и допускает расширения, а темплейты и модели подгружаются динамически. Идея была подсмотрена в этой презентации — http://www.knockmeout.net/2012/08/thatconference-2012-session.html, код презентации выложен на github — https://github.com/rniemeyer/SamplePresentation — на базе этого кода будем писать свой.

MongoDB — замечательная база данных, которая становится все популярнее в последнее время. Все больше людей с SQL опытом начинают её использовать, и один и первых вопросов, который у них возникает: MongoDB transactions?.

Если поверить ответам со stackoverflow, то все плохо.

MongoDB doesn't support complex multi-document transactions. If that is something you absolutely need it probably isn't a great fit for you.

If transactions are required, perhaps NoSQL is not for you. Time to go back to ACID relational databases.

MongoDB does a lot of things well, but transactions is not one of those things.

Но мы не поверим и реализуем транзакции (ACID*) основанные на MVCC. Ниже будет рассказ о том, как эти транзакции работают, а тем, кому не терпится посмотреть код — добро пожаловать на GitHub (осторожно, java).

Пост не о MongoDB, а о том, как использовать compare-and-set для создания транзакций, а durability обеспчивается ровно в той степени, в которой её обеспечивает хранилище.

Первая часть короткого и жесткого введения в Haskell. Вторую часть можно найти здесь

tl;dr: Очень краткое и сжатое введение в Haskell.

• Введение
  
  • Установка
  • Без паники
  • Самые основы Haskell
    
    • Объявление функций
    • Пример использование типов
    
    
  
  
• Необходимый минимум из Haskell
  
  • Выражения
    
    • Арифметические
    • Логические
    • Возведение в степень
    • Списки
    • Строки
    • Кортежи
    • Разбираемся со скобками
    
    
  • Полезные вещи для записи функций
  
  
• Сложная часть
  
  • Функциональный стиль
    
    • Функции высшего порядка
    
    
  • Типы
    
    • Вывод типов
    • Создание новых типов
    • Рекурсивные типы
    • Деревья
    
    
  • Бесконечные структуры
  
  

UPD. Если туториал вам понравился, черкните пару строк автору оригинальной статьи. Человеку будет приятно ;)

Вторая часть ПЕРЕВОДА короткого и жесткого введения в Haskell. С первой можно ознакомиться здесь

Оригинал здесь

• Чертовски сложная часть
  
  • Разбираемся с IO
  • Объяснение трюка с IO
  • Монады
    
    • Maybe это монада
    • Монада списков
    
    
  
  
• Приложение
  
  • Еще несколько слов о бесконечном дереве
  
  

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

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

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

При разработке приложений с модульной структурой на JavaScript возникает две проблемы:

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

Обе эти задачи решаются при использовании подхода Asynchronous Module Definition. Он сводится к описанию модулей функцией define и подключению их с помощью require. На данный момент есть несколько инструментов, реализующих AMD. Я начал своё знакомство с ними с RequireJS и был удивлён, насколько удобно и просто можно описывать зависимости модулей. Расскажу, как это работает, на простом примере.