Думаю многим знакомо понятие «борьба за staging», когда все разработчики одновременно за день до релиза хотят поделиться своими наработками, чтобы тестировщик их проверил как можно скорее и не пришлось всю ночь править баги, да? Кому интересно посмотреть как мы решаем данную проблему для RoR-проектов с помощью Capistrano прошу под кат.

Что за Rack?

По словам Christian Neukirchen — автора гема rack — он создан для обеспечения минимального API для подключения веб-серверов, поддерживающих Ruby (WEBrick, Mongrel и т.д.) и ruby веб-фреймворками (Rails, Sinatra и др.).

Такие фреймворки, как например Sinatra, построены над Rack или у них есть rack-интерфейс, позволяющий серверам веб-приложений подключаться к ним.

Цель rack проста — он позволяет с легкостью обрабатывать HTTP-запросы.

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

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

Как же на самом деле надо создавать, развивать и публиковать свои гемы?

Современный подход заключается в использовании Bundler совместно с другими инструментами, такими, как Git, YARD и RSpec-2.

Если вы являетесь rails-разработчиком, то вы наверняка слышали про Unicorn, http-сервер, способный одновременно обрабатывать множество запросов.

Для обеспечения параллельности Unicorn использует создание множества процессов. Т.к. созданные (форкнутые) процессы являются копиями друг друга, это значит, что rails-приложение должно быть потокобезопасным.

Это здорово, т.к. нам тяжело быть уверенными, что наш код является потокобезопасным. Если мы не можем быть уверены в этом, то ни о параллельных веб-серверах, таких как Puma, ни даже об альтернативных реализациях Ruby, реализующих параллелизм, таких как JRuby и Rubinius, не может быть и речи.

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

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

Сегодня стало известно о новой уязвимости в клиенте OpenSSH получившей идентификаторы CVE-2016-0777 и CVE-2016-0778. Ей подвержены все версии программы от 5.4 до 7.1.

Обнаруженный баг позволяет осуществить атаку, приводящую к утечке приватного ключа. Аутентификация ключа сервера предотвращает атаку типа man-in-the-middle, так что злоумышленникам понадобится сначала получить доступ к машине, на которую вы пытаетесь зайти. Хотя, при подключении к машине впервые, не сверяя ключ, MITM возможен.

До тех пор пока вы не обновите уязвимые системы рекомендуется использовать следующий фикс:

echo -e 'Host *\nUseRoaming no' >> /etc/ssh/ssh_config

Обновления для различных ОС уже выходят, в том числе выпущена portable версия OpenSSH 7.1p2.

Клиент OpenSSH версий от 5.4 до 7.1 содержит код экспериментальной функции «roaming», позволяющей продолжать сессии. Серверная часть этой функциональности никогда не была опубликована, но существующий код клиента уязвим — злоумышленники могут получить часть памяти клиентской машины, содержащую приватный ключ. По умолчанию эта функция включена, поэтому узявимость достаточно серьёзна.

Примечания переводчика:

Всем привет. Данная статья является вольным переводом (ссылка в конце). Я не претендую на какую либо 100% корректность перевода. Однако считаю, что общую суть происходящего передал полностью.

Для кого может быть полезна эта статья? Скорее всего, для начинающих Ruby on Rails разработчиков, кому просто интересно понять некоторые моменты в работе Ruby.

Для кого эта статья может быть бесполезна? Скорее всего, для чистокровных Ruby программистов и прожженых Ruby on Rails разработчиков. Высока вероятность того, что вы это уже знаете.

Зачем я сделал перевод? Эта статья мне показалась интересной и внутри меня просто появилось желание поделиться ею со всем русскоговорящим (м.б. плохо знающим английским) сообществом.

P.S. Если знаете английский, просто перейдите по ссылке в конце.

В какой-то из весенних дней этого года я ехал в троллейбусе и листал комикс о Коше. В одном из выпусков была такая фраза «НО! Её можно понять, она же фракталами в горизонт перетекает, я бы тоже замешкался...». После этого я посмотрел в окно и понял, что если мы возьмём два подходящих дробно-линейных преобразования комплексной плоскости a(z) и b(z), и рассмотрим систему итерированных функций для a(z), b(z), a⁻¹(z), b⁻¹(z), взяв в качестве начального множества картинку с Кошем, то Кош будет перетекать фракталами в горизонт!

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

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

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

Давно не писали про обновления в нашем образовательном проекте Хекслет, а тут как раз Новый год — самое время поделиться хорошими новостями. Мы сделали бесплатным популярный курс «Bash: Основы командной строки»! Это уникальный курс, потому что упражнения в нем (как и везде в Хекслете) выполняются в условиях, приближенных к боевым: вам доступен личный контейнер с root-доступом, в котором среди прочего запущена оболочка Bash.

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

Здравствуйте, меня зовут Александр Зеленин и я веб-разработчик. Я расскажу, как сделать так, чтобы ваш сайт открывался быстро. Очень быстро.

Автор: Роман Денисенко, старший инженер по тестированию DataArt.

Введение

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

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

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

Все мы в IT сталкивались с системами отслеживания ошибок — с так называемыми баг-трекерами, с issue-трекерами. Один из популярных продуктов такого рода — Atlassian JIRA.

На самом деле, Atlassian JIRA — это больше, чем просто система отслеживания ошибок. JIRA может использоваться довольно широко — в том числе и для управления проектами. Можно сказать, что JIRA — это система для отслеживания статуса задач. Задачи могут быть разными: это сбор требований, тестирование, непосредственно разработка и т. д. Я видел даже попытки подсадить на JIRA бухгалтеров — а что, мол, будет у нас agile-бухгалтерия!

На официальном же сайте JIRA описывается следующим образом:
JIRA is the tracker for teams planning and building great products. Thousands of teams choose JIRA to capture and organize issues, assign work, and follow team activity. At your desk or on the go with the new mobile interface, JIRA helps your team get the job done. В общем, основная идея JIRA в том, что она позволяет планировать работу.

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

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

На днях вышел новый стабильный релиз mongodb. В этой версии был добавлен ряд нововведений таких как новый GUI для визуальной работы с mongodb, LEFT JOIN, валидация документа и т.д. некоторые из этих свойств мы и рассмотрим на небольших примерах ниже.

• Частичный ( partial ) индекс
• Валидация
• Нововведения агрегационного фреймворка
• Новые опции в утилитах импорта экспорта
• Нововведения в CRUD
• WiredTiger и fsyncLock
• Новое GUI compass

После прочтения статьи о полезных и бесплатных плагинах для SSMS — TOP (10) бесплатных плагинов для SSMS, я решил поделиться своим списком бесплатных инструментов, которые могут быть очень полезны разработчикам баз данных, и не только. Инструменты ориентированны на разработку под Microsoft SQL Server. Некоторые инструменты, платные, однако содержат достаточно полнофункциональные бесплатные редакции, которых с головой хватает для небольших проектов.

Недавно мне удалось пройти сертификация C100DEV: MongoDB Certified Developer Associate Exam и C100DBA: MongoDB Certified DBA Associate Exam. В данной статье я хочу поделиться своим опытом и сказать на что следует обратить внимание при подготовке, и как проходил экзамен. Также приведу несколько примеров вопросов.

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

У каждого есть возможность воспользоваться специально созданной для обучения школьников средой программирования Scratch, которую разрабатывают специалисты одного из самых престижных технических учебных заведений США и мира — Массачусетского технологического института. Или игрой Minecraft, за которую Microsoft год назад заплатила $2,5 млрд и с помощью которой, в том числе, планирует обучать детей программированию. Или обучающими играми, которые создают энтузиасты и добровольцы во всём мире.

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

Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!

Содержание:

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

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

Как введение могу сказать что более 4 лет назад на самом рассвете моей карьеры в IT я собеседовался в одну всем известную и очень большую иностранную фирму. Как полагается в таком случае собеседование было на английском языке.

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

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

Относительно недавно мне посчастливилось присоединиться к команде разработки Bitbucket Server в Atlassian (до сентября он был известен как Stash). В какой-то момент мне стало любопытно, как этот продукт освещён на Хабре, и к моему удивлению, нашлось лишь несколько заметок о нём, подавляющее большинство которых на сегодняшний день уже устарело.

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

Позвольте начать с перевода статьи Тима Петтерсена «A better pull request» о том, как должен выглядеть pull request, чтобы наиболее эффективно решать возложенную на него задачу.

В первой части я сказал, что хеш таблица это немного LIST, SET и SORTED SET. Судите сами — LIST состоит из ziplist/linkedlist, SET состоит из dict/intset, а SORTED SET это ziplist/skiplist. Мы уже рассмотрели словарь (dict), а во второй части статьи будем рассматривать структуру ziplist — вторую наиболее часто применимую структуру под капотом Redis. Посмотрим на LIST — вторая часть его «кухни» это простая реализация связного списка. Это пригодится нам, чтобы внимательно рассмотреть часто упоминаемый совет об оптимизацию хеш таблиц через их замену на списки. Посчитаем сколько памяти требуется на накладные расходы при использовании этих структур, какую цену вы платите за экономию памяти. Подведём итоги при работе с хеш таблицами, при использовании кодировки в ziplist.

В прошлый раз мы закончили на том, что сохранённые с использованием ziplist 1,000,000 ключей заняли 16 мб оперативной памяти, тогда как в dict эти же данные потребовали 104 мб (ziplist в 6 раз меньше!). Давайте разбираться какой ценой: