Не так давно я рассказывал о геме Oxymoron, позволяющем очень просто и быстро строить современные Single Page Application на AngularJS и Ruby on Rails. Статья была встречена весьма позитивно, поэтому пришло время написать более-менее сложное приложение, чтобы показать все возможности гема.

Перевод поста Eila Stiegler "The Wolfram Language Worldwide Translations Project".

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

---

Довольно много времени прошло с тех пор, как я закончила колледж в Германии. И я до сих пор хорошо помню те длинные бессонные ночи, что проводила за выполнением трудных домашних заданий, исследований, и почти полное отсутствие свободного времени. Но так же я хорошо помню и занятия по программированию. Я старалась приступить к ним как можно позже. Но когда программирование уже вошло в список моих обязательных предметов, у меня уже не было возможности его игнорировать. И так как английский — не мой родной язык, мне тяжело давались принципы программирования, которые были для меня чем-то уж очень абстрактным; я постоянно терялась среди названий различных функций, которые приводились на английском. И пускай мне далось всё это весьма тяжело, я с успехом закончила обучение, и вот теперь, годы спустя, я являюсь частью проекта, который мог бы тогда мне сильно помочь — проекта по переводу Wolfram Language на различные языки.

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

Как обычно обучаются программированию? Судя по моему опыту, студентам дают кусок кода и объясняют для чего он нужен. Таким образом, у них появляется возможность познакомиться со структурой и различными функциями. Чтобы облегчить этот процесс, Wolfram Research добавила функционал, который проставляет к коду на языке Wolfram Language аннотации на предпочтительном для вас языке. Мы постоянно развиваем это направление и стараемся добавить максимально возможное количество языков. На данный момент уже имеется поддержка японского, китайского традиционного и упрощенного, корейского, испанского, русского, украинского, польского, немецкого, французского и португальского.

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

Аннотации к коду

Снова возвращаясь к своему студенчеству: если бы у меня был код демонстрации “Major Multinational Languages”, — пример с сайта Wolfram Demonstrations Project — я смогла бы увидеть этот код, аннотированный на немецком. Аннотации никак не изменяют код и не ограничивают его функциональность. Он по-прежнему вычисляемый и может редактироваться, а аннотации к нему изменяются на лету:

As such, there’s really no “standard” benchmark that will inform you about the best technology to use for your application. Only your requirements, your data, and your infrastructure can tell you what you need to know.

Для начала немного философии. NoSql окружает и от этого никуда не убежать (хотя не очень то и хотелось). Оставим вопросы о глубинных причинах за рамками данного текста, отметим лишь, что этот тренд отражается не только в появлении новых NoSql решений и развитии старых. Еще одна грань — смешение противоположностей, а именно поддержка хранения schema-less данных в традиционных реляционных базах. В этой серой области на стыке реляционной модели хранения данных и всего остального кроется головокружительное количество возможностей. Но, как и всегда, нужно уметь найти баланс, который подходит именно для ваших данных. Это бывает трудно, в первую очередь из-за того, что приходится сравнивать мало сравнимые вещи, например, производительность NoSql решения с традиционной базой данных. В этой небольшой заметке будет предложена такая попытка и приведено сравнение производительности работы с jsonb в PostgreSQL с json в Mysql и с bson в Mongodb.

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

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

Нам понадобится:

1. Установить на все компьютеры класса ОС Linux. Дистрибьютив выбирайте на свой вкус.
2. Установить на все ученические компьютеры пакеты: openbox, tint2, pcmanfm, gxkb, x11vnc (сервер и клиент), vlc
3. Кроме этого на учительском компьютере необходимо установить программу RuleUser, подробнее о ней будет рассказано ниже.
4. Создать на ученических компьютерах пользователя guest.
5. Установить и настроить на всех компьютерах пакет sshd.
6. Скопировать приложенные конфигурационные файлы на ученические и учительский компьютеры.

Примечание. В этом примере компьютер учителя имеет ip адрес: 192.168.1.100/24. Ученические компьютеры имеют адреса, начиная с 192.168.1.101/24.

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

Вместо этого можно воспользоваться любым современным языком, имеющим библиотеку для работы с Win32 OLE. Например, JavaScript (Win32 OLE поддерживает Node.JS) или Ruby (нужная библиотека входит в набор стандартных библиотек языка).

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

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

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



В первом случае поиск занимает A?ⁿAⁿ времени, во втором — Aⁿ.

Степени обозначают повторяемость строк, то есть A?³A³ — это то же самое, что и A?A?A?AAA. Графики отражают время, требуемое для поиска через регулярные выражения.

Обратите внимание, что в Perl для поиска строки из 29 символов требуется более 60 секунд. А при втором методе — 20 микросекунд. Это не ошибка. При поиске 29-символьной строки Thompson NFA работает примерно в миллион раз быстрее. Если нужно найти 100-символьную строку, то Thompson NFA справится менее чем за 200 микросекунд, а Perl понадобится более 10¹⁵ лет. Причём он взят лишь для примера, во многих других языках наблюдается та же картина — в Python, PHP, Ruby и т. д. Ниже мы рассмотрим этот вопрос более детально.

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

Возникает логичный вопрос: а почему бы в Perl не использовать метод Thompson NFA? Это возможно и следует делать, и об этом пойдёт далее речь.

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

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

И вот, когда встала перед нами задача весьма плотного обмена сообщениями с ГОСТовой электронной подписью с одной из таких систем, то предложенный вариант решения в виде сетевого SOAP-сервиса, подписывающего запросы (и ответы) мне не понравился от слова «совсем» (оборачивать SOAP в SOAP — это какой-то кошмар в квадрате). Наступили длинные майские выходные, а когда они закончились — у меня было решение получше…

Github выпустил сервер непрерывной интеграции проектов Janky, сделанный на базе Jenkins под управлением CoffeeScript-бота Hubot. Фактически, Janky — это просто интерфейс для работы с Jenkins через скрипты и команды Hubot.

Разработка ПО методом непрерывной интеграции (continuous integration, CI) предусматривает выполнение частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. Например, сборка из репозитория может проводиться каждую ночь по расписанию, с автоматическим прогоном тестов, так что каждое утро разработчики видят результаты тестирования. Такой метод приучает и программистов работать эффективнее, в итеративном режиме с более коротким циклом.

Понятно, что Github как нельзя лучше подходит для работы в режиме непрерывной интеграции. Система Janky заточена на использование Github, в том числе она создаёт соответствующие web-hook’и, а также может ограничивать доступ для сотрудников организации на Github.

Сервер Janky сделан на основе известной системы Jenkins (Hudson). Использование бота Hubot придаёт Janky особый шарм, управление сервером осуществляется с помощью простых команд.

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

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

Задача

Нужно, чтобы пользователи периодически по определенному условию получали email-ы. Например: Пользователь зарегистрировался 5 дней назад.

К сожалению, очень часто приходится слышать упреки, что ReactOS работает только в виртуальных машинах и компьютерах 15-летней давности. Спешим опровергнуть это расхожее мнение. Вашему вниманию предлагается видео, записанное одним из тестеров, с демонстрацией работы ReactOS на брендовом компьютере Dell Inspiron 530s.





Вскоре мы вновь вернемся к теме техники под маркой «Dell» с еще одной не менее интересной новостью.

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

Итак, приступим.

Создаем хэш из массива

Проще простого. Ставим команду Hash перед любым массивом и получаем готовые пары ключ/значение:

Hash['key1', 'value1', 'key2', 'value2']

# => {"key1"=>"value1", "key2"=>"value2"}

В один прекрасный день у тебя в доме начинается капитальный ремонт систем водоснабжения и водоотведения. Рабочие снимают старые стояки подачи воды и канализации, и на несколько дней ты становишься чуть-чуть космонавтом — обтирание влажными салфетками вместо душа, ёмкости питьевой, технической и отработанной технической воды, ассенизационная ёмкость с хлоркой от запаха и прочие неудобства. К счастью, более чем полувековая история космических полётов хранит достаточно историй для отвлечения и поднятия настроения. В самом деле, любой ремонт меркнет перед неудобствами, выпавшими на долю, например, Фрэнка Бормана и Джима Лоувелла на «Джемини-VII».

Почти каждому, у кого есть сервера с привязанными к ним доменами, так или иначе приходится решать вопрос с почтой, как минимум с доступностью адресов вида webmaster/postmaster/abuse@domain.
Кто-то учит M4 и настраивает встроенный sendmail, кто-то использует сторонние сервисы ( например от Google ), кто-то — поднимает стандартную связку postfix+courier-imap+mysql ( ну или аналоги ).

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

Prerequirements

При написании этого руководства я предполагал, что пользователь способен взаимодействовать с *nix-системами посредством консоли, умеет устанавливать пакеты своего дистрибутива и владеет как минимум одним текстовым редактором для редактирования конфигов. В качестве примера я буду устанавливать пакеты на Arch Linux, поскольку это мой домашний дистрибутив.

...Skype — это дьявольски хитрая программа, написанная бесспорно талантливыми людьми..._{Крис Касперски}

Доброго времени суток!

Skype сейчас я встречаю чаще на компьютерах чем другие IM клиенты, мне он практически заменил icq, вся рабочая переписка ведется в skype, но речь пойдет не о том, что лучше или популярней. Часто бывает так, что участвуешь сразу в нескольких чатах где количество участников превышает 10, что собственно и приводит к тому, что на рабочем столе и в трее постоянно обновляется количество новых сообщений, а также уведомления в виде всплывающих сообщений, а теперь представьте что у вас 3 окна чата с друзьями, 1 с вашим боссом, другой с девушкой — все это в сумме начинает запутывать, отвлекать и порой раздражать. Хотелось бы расставить приоритеты…

Раньше я чаще всего настраивал «политику» уведомлений только через глобальные настройки программы
Случилось так, что я узнал, что в каждом окне чата skype возможно использование команд, например /alertsoff отключит уведомления для конкретного окна чата, соответственно /alertson включит их обратно.
Поискав немного я наткнулся на некое how-to, оказывается у skype чата довольно много текстовых команд, подобие IRC команд. Далее я постарался попробовать все возможные из них на двух имеющихся у меня платформах, как оказалось не все и не везде работает… Прошу под кат.

TheRole — гем для организации ролевого распределения на RoR сайте (с панелью управления)



  

tl;dr

Еще один (1001-ый) способ обеспечить разграничение прав в web-приложении. Концепт данного решения был довольно давно реализован на PHP, и позже был переписан на ruby. Ввиду простоты реализации описанный подход может быть применим в любом MVC фреймворке вроде Rails, Laravel и.т.д.

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

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

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

«Почему бы просто не взять и использовать Heroku?», спросите вы.
Прежде всего, я могу запустить Docker и Ansible на любой машине, с любым хостинг провайдером. Во вторых, я предпочитаю гибкость, удобству. Я могу, таким же образом, запускать все что угодно, не только web приложения. Ну и напоследок, потому что я эксперементатор в душе, я получаю удовольствие от понимания того как оно все вместе работает. Фундаментальная основа Heroku это Linux контейнер. Та же технология лежит и в основе Docker'a. На самом деле, одним из девизов Docker'a является «Контейнеризация это новая виртуализация»

Сегодня этим постом мы открываем цикл еженедельных публикаций учебных материалов Технопарка. Если кто-то ещё не знает, Технопарк — это совместный образовательный проект Mail.Ru Group и МГТУ им. Н. Э. Баумана. На данный момент здесь проходит обучение по 20 IT-дисциплинам 91 наиболее талантливый студент. Технопарк существует с 18 ноября 2011 года, а первые счастливчики приступили к занятиям в декабре 2011 года.

Обучение в Технопарке совершенно бесплатное, оно проходит после занятий в университете. Стать участниками проекта могут студенты 3-5 курсов. Хотя для 2 и 6 курсов можем сделать исключение. Обучение длится 2 года, оно разбито на 4 семестра, в каждом из которых проходят по 3-4 предмета. Первый блок первого семестра посвящён всему, что связано с web-технологиями, от истории возникновения до программирования и безопасности web-приложений.

Лекция 1. Введение

На вводном занятии вы познакомитесь с краткой историей развития интернета, основными трендами в развитии web-приложений, облачных сервисов и мобильных приложений. Также на лекции разобрано устройство и работа несложного web-приложения, обсуждены такие фундаментальные понятия, как система адресации в интернете, домены, HTML-страницы и протокол HTTP. Напоследок кратко рассказано о CGI-скриптах, их назначении и особенностях работы.