Мы постоянно используем Cloud-native технологии, и запускаем системы в контейнерах на платформе Kubernetes. Эта технология отлично подходит для оркестрации контейнерных нагрузок благодаря гибкости и установке виртуальных машин прямо на железо (bare metal). Когда-то Kubernetes подходил только для простых рабочих нагрузок без сохранения состояния, теперь там стало возможным хранить базы данных, обучать машины и развертывать сложные приложения.

Введение

“Der Mensch ist doch ein Augentier – schöne Dinge wünsch ich mir.”

(Цитата из песни «Morgenstern» группы «Rammstein». Примерный перевод: «Но человек – глазастый зверь, – мне нужно множество красивых вещей».)

Это – обучающий материал (tutorial) по языку программирования Nim. Предполагается, что вы знакомы с базовыми концепциями программирования, такими как переменные, типы или команды, но глубокие знания не обязательны. Большое количество примеров по сложным нюансам языка, вы можете найти в официальном руководстве. Все примеры кода в этом документе следуют руководству по стилю языка Nim.

Это 5-я статья цикла по разработке, управляемой моделями. В предыдущих статьях мы уже разобрались с метамоделями, валидацией моделей, некоторыми нотациями для моделей (диаграммы и таблицы). Всё это было в рамках пространства моделирования MOF. Сегодня мы построим мост в пространство моделирования EBNF – познакомимся с текстовой нотацией для MOF-моделей.

В этой статье мы рассмотрим два способа поиска с помощью регулярных выражений. Один широко распространён и используется в стандартных интерпретаторах многих языков. Второй мало где применяется, в основном в реализациях 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? Это возможно и следует делать, и об этом пойдёт далее речь.

Честно говоря, эту статью я пишу даже больше для себя — чтобы как то систематизировать информацию по внутреннему языку программирования ABAP/4 системы SAP R/3 в одном месте. Тем не менее, я буду очень рад, если кому то ещё она окажется полезной и сэкономит время. Сразу оговорюсь, что статья ориентирована на новичков, которые только начинают изучать ABAP/4 (коим, в некоторой мере, я и сам являюсь).

Сейчас я работаю над senjin/gglsl — библиотекой для программирования шейдеров с помощью Groovy, о которой недавно писал.

Здесь я опишу три подхода к анализу AST (abstract syntax tree), все на примерах под-задач, вытекающих одна из другой и связанных общим контекстом: рекурсивные функции, паттерн Visitor, и паттерн-матчинг.
Паттерн-матчинг реализован на Java и доступен на GitHub.

Вы несколько лет писали свой проект и теперь хотите привлечь пользователей? У меня есть простой, как холостяцкая яичница с беконом, рецепт специально для вас.

Для приготовления простого сайта вам понадобится:

• репозиторий на GitHub — 1 штука
• готовый html шаблон, для придания приятного вида — 1 штука
• кусочек свежего компилирущегося C++ кода — минимум 1 строка кода
• готовые javascript соусы из магазина — ~500Kb
• картинки и анимашки по вкусу

Меняйте любые компоненты, экспериментируйте и готовьте свои сайты для любимого языка!

или «Прекратите характеризовать хранилища данных как CP или AP»

Джеф Ходжес в своем прекрасном посте «Заметки о распределенных системах для новичков» рекомендует использовать САР теорему для критики найденных решений. Многие, похоже, восприняли этот совет слишком близко к сердцу, описывая свои системы как «СР» (согласованность данных, но без постоянной доступности при сетевой распределенности), «АР» (доступность без согласованного состояния при сетевой распределенности), или иногда «СА» (означает «Я всё ещё не читал статью Коды (Coda Hale) почти 5-летней давности»).

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

(Да, я понимаю всю иронию написания целой статьи по теме того, о чём призываю не писать других вообще. Но, как минимум, у меня будет ссылка, которую я смогу давать интересующимся, когда меня будут спрашивать, почему я не одобряю обсуждение САР теоремы. Также, я хочу извиниться, если статья вам покажется слишком напыщенной, но эта напыщенность опирается на множество ссылок.)

САР использует слишком узкое определение

Если вы хотите ссылаться на САР как на теорему (а не на расплывчатый концепт в маркетинговых материалах к вашей базе данных), вы должны быть точны. Математика требует точности. Доказательство сохраняется только если вы вкладывается в слова, то же самое значение, что было использовано при доказательстве. И оно опирается на очень точные определения:

Около шестнадцати лет назад вышла первая версия Hotspot – реализация JVM, впоследствии ставшая стандартной виртуальной машиной, поставляемой в комплекте JRE от Sun.

Основным отличием этой реализации стал JIT-компилятор, благодаря которому заявления про медленную Джаву во-многих случаях стали совсем несостоятельными.
Сейчас почти все интерпретируемые платформы, такие как CLR, Python, Ruby, Perl, и даже замечательный язык программирования R, обзавелись своими реализациями JIT-трансляторов.

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

Таким образом вам может быть интересно под катом, если:

• Вы принципиально не понимаете, что такое JIT-компилятор, или у вас есть легкое непонимание, чем такой подход существенно лучше интерпретации.
• Вы хотели бы написать простой JIT для своего интерпретируемого языка.
• Вы преподаете курс «Языки программирования и компиляторы», и не против сделать практическое задание для студентов еще интересней.
• Вам интересно, как нарисована эта картинка.

Признак плохого дизайна №1:
Наличие объекта-«бога» с именем, содержащим «Manager», «Processor» или «API»

Ведущий iOS-разработчик Redmadrobot Егор BepTep Тафланиди — о том, как добиться стройного архитектурного дизайна мобильного приложения, используя классические шаблоны проектирования и логическое разделение исходного кода на модули.

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

Functional Reactive Programming

Благодаря фреймворку ReactiveCocoa, новая парадигма программирования все чаще используется среди iOS разработчиков.

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

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

• loose coupling — потоки события позволяют уменьшить связанность между различными частями кода;
• explicit state — состояние программы определяется набором событий, и поэтому им становится легко управлять.

В качестве альтернативы реактивному подходу рекомендую посмотреть на Futures. Есть как минимум два интересных фреймворка: PromiseKit и CollapsingFutures

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

В этой статье я расскажу о том, как мы автоматизируем тестирование наших приложений (ICQ и Агент Mail.Ru), поделюсь нашими наработками в этой области и упомяну о проблемах, с которыми мы сталкиваемся.

В этой статье я хочу немного поговорить об авторском праве и свободных лицензиях на ПО. Текст является результатом самостоятельного выбора лицензий и их применения к своим проектам.

Статья будет полезна тем, кто хочет:

— в общих чертах понять, что такое авторское право (но лучше обратиться к юристу);
— подобрать свободную лицензию для своего проекта;
— разобраться, что нужно писать в шапке файла исходного кода.

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

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

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

Относительно недавно у Google AdSense появился новый способ выплаты, а именно — перевод средств на валютный счет в USD. Пока данный способ является экспериментальным и устанавливается по запросу в службу поддержки. Так уж получилось, что я стала участником эксперимента и расскажу о своем опыте перевода денег от гугл напрямую на ИП в России.

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



Сегодня, я хочу рассказать о том как сделать свое хобби по разработке Android-приложений пусть небольшим, но официальным бизнесом. О том, как легально получать деньги, заработанные на Google Play, о «страшном» валютном контроле и «таинственном» паспорте сделки.

Публикую пьесу «Бэббидж» из своего сборника «Бэббидж и остальные» (2010).
Пьеса биографическая, основана на документальных материалах Ю.Л. Полунова, И.А. Апокина и др. Ранее в Сети не публиковалась, по крайней мере официально. Написана в качестве произведения традиционного литературного жанра, поэтому довольно объемная: предполагаемое время прочтения 20-25 минут.

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



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

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

Традиционно, для тех кто не любит много буков, краткие (более-менее) тезисы:

• Будучи долгое время лидером на рынке, Нокиа сильно расслабилась и загадила свою внутреннюю инфраструктуру бюрократией, чрезмерным аутсорсингом и огромным количеством бесполезной «менеджерской прослойки».
• Будучи долгое время лидером, Нокиа просрала потратила много денег на ненужные операционные расходы, поглощения никому не нужных фирм и на невменяемую модель аутсорсинга.
• Полностью оторвавшись от реальности с уходом Йормы Оллилла, Нокиа, под управлением гениального юриста CEO Олли-Пекки Каласвуо, потратила кучу денег и усилий на создание бесполезной и неконкурентоспособной сервисной инфраструктуры Ovi. В результате этого, помимо денег, Нокиа потеряла уйму полезного времени, которое можно и нужно было потратить на развитие основного бизнеса — телефонов, софта и т.д.
• Бюрократия и непотопляемая менеджерская прослойка в Нокиа, последовательно мигрировала из одного передового проекта в другой, в составе одних и тех же групп лиц, самореплицируясь в виде кучи формальных дебилопроцессов комитетов и управленческих групп, немного перетасовываемых с учетом специфики. В итоге именно эта бюрократия убила и Symbian, и Ovi, и MeeGo и остальные попытки догнать уходящий поезд своими силами.
• Борьба с бюрократией и прослойкой в Нокиа зашла в полный тупик.
• У великого CEO Элопа просто не было другого выхода кроме как прибить всю старую, неповоротливую и прогнившую организацию, путем создания альянса с Майкрософтом и переходом на Windows Phone. Тем самым все старые процессы, компетенции, технологии и самое главное — люди резко стали, что называется, «не в тему». И следовательно тем самым можно было под благовидным предлогом прибить этот табун менеджеров, бесконечно рисующих фэнтезийные роадмапы с единорогами и перекладывающих бумаги с левого края стола на правый.
• Новая Нокиа, после 2011 года и старая Нокиа до 2011 года – это две РАЗНЫЕ организации. Их объединяет только общее название и операционка S40 для телефонов Asha.
• Горящая платформа, это не Symbian и не MeeGo. Горящая платформа, это то состояние в которое Нокиа загнали годы расслабленного лидерства и тупоголовые амбиции предыдущего CEO – Олли-Пекки Каласвуо с кликой подкаркивающих вице-президентов.
• С бюрократией и бизнес процессами, имеющимися на 2010 год, Нокиа не спас бы ни Андроид, ни половина населения Бангалора, пишущих на Qt под MeeGo. Даже если бы Apple бесплатно передал Нокиа iOS и все сервисы, то они бы выродились руками всяких Requirement Managerов в типичные Нокийские дизайн-химеры и в итоге загнулись через какое-то время.
• То, что сделал великий CEO Элоп – было единственно возможным разумным решением, дающим хоть какие-то шансы на выживание. Вопрос «каким образом он это сделал?», остается открытым, равно как и вопрос «поможет ли это Нокиа?» в итоге. Не следует забывать, что нынешняя Нокиа — это совершенно новая организация, поэтому глупо предполагать, что она разом вернет себе лидерство. Как и всем новым организациям ей придется за это лидерство долго бороться.
• Без ошибок и побед Нокиа никогда не было бы ни Андроида, ни Айфона. И Google и Apple тщательно проанализировали достоинства и недостатки более старших конкурентов перед тем как шагнуть вперед.

Все это в деталях — под катом. Предупреждаю что клевых картинок там нет. Сплошное графоманство и ёрничанье.

Этот пост будет полезен всем, кто хотя бы иногда что-то готовит сам, а также помогает или мешает это делать другим.
Из него можно узнать, что это за гаджет — мультиварка, какие у нее технические возможности и невозможности, внутренность, наружность, достоинства (много) и недостатки (тоже много). Расскажу кое-что и о маленьких мультиварочных хитростях, а также позволю себе общее лирическое отступление о программировании на кухне.
Цель поста — рассказать про мультиварки, как класс объектов, не выделяя особо его представителей, но, чтобы не вести разговор о сферической мультиварке в вакууме, сделаю основным примером разбора мою модель — Panasonic SR-TMJ181.
Те, у кого нет мультиварки узнают, нужна ли она им, но и те, у кого она есть, надеюсь, без новых знаний не останутся.

Давно подметил, что среди многих своих коллег по цеху присутствует некоторая подозрительность и даже в некотором роде неприязнь к Core Data, причем некоторые к фреймворку даже и не притрагивались. Чего уж там, и я в начале своего пути освоения новой платформы относился к нему предвзято, пойдя на поводу у подобных комментариев. Но не стоит поддаваться предрассудкам и мифам, не потрогав продукт самостоятельно. Тем из нас, кто пошел «против системы», но еще не постиг инструмент полностью, я и посвящаю эту статью. На основе небольшого примера, основанного на реальной задаче разработки мобильного клиента нашей социальной сети Мой Мир, я хочу рассказать о некоторых «подводных» камнях и заострить внимание начинающего разработчика на важных моментах оптимизации использования Core Data. Предполагается, что читающий уже имеет представление, для чего нужны основные элементы Core Data (NSManagedObjectContext, NSPersistentStoreCoordinator и т.д.) и хотя бы поверхностно ознакомлен с API.

Наш кейс: необходимо разработать приложение, позволяющее хранить и структурировать большой объем фотографий с различной метаинформацией о них. Для этого нам потребуется Core Data… и все.