В этой статье я хочу расказать о настройке Jenkins'а и практически любой IDE от Jetbrains для так называемого Pre-Tested Commit. Pre-Tested Commit — это процесс тестирования изменённого кода перед комитом, в котором разработчик на основе локальных изменений формирует diff, загружает его в Jenkins и проверяет что билд проекта с его изменениями проходит успешно. После этого разработчик фиксирует изменения в репозитории.

Введение

После продолжительного перерыва мне пришлось вернуться к программированию на C++. После C# очень не хватало ключевого слова var и возможностей построения запросов linq. Однако как оказалось прогресс не стоит на месте и за время моего отсутствия вышла новая версия С++11, имеющая новые интересные возможности, к тому же реализованная в большинстве компиляторов. Я занимался кросс-платформенным проектом и меня интересовали компиляторы GCC для Linux, Visual Studio и mingw для мира Windows. Попытка найти linq-like библиотеку не увенчались успехом, все, что я находил, было нежизнеспособной поделкой на коленке. Смирившись, я бросил поиски, однако в апреле 2012 вышла обнадеживающая статья LINQ to Objects на языке C++, в которой описывалась библиотека, которая мне подходила. Попробовав ее в деле и разобравшись в ее устройстве, я был разочарован неэффективностью, но некоторые идеи я подчерпнул. Оставалось одно – написать такую же, только с блэк-джеком, что я и сделал github.com/drbasic/CppLinq, заодно разобравшись автоматическим выводом типа (auto) и лямбда выражениями.

Проектировалась библиотека так, что бы с помощью fluent-синтаксиса и лямбда выражений пользователь мог построить граф преобразований. Эти графы можно копировать, достраивать, объединять, т.е. реализовать поведение максимально близкое к прообразу Linq to Objects из мира C#. Функционал библиотеки, недолго думая, я позаимствовал из C#, добавив, явный left join и full join. Важным ограничением библиотеки является перемещение по графу преобразования не копий, а указателей на элементы исходной последовательности. Это позволяет эффективно обходиться со сложными элементами коллекций, ведь теперь не происходит накладных расходов на копирование, но исходная последовательность из-за этого не должна быть «виртуальной». Т.е. к началу работы у каждого элемента исходной последовательности должен быть уникальный адрес и элементы не должны перемещаться в памяти во время работы linq-преобразований. В общем, для этого подходят массивы, контейнеры Qt, все стандартные контейнеры, кроме std::bitset. Сложности возникли лишь с константными последовательностями, которые так и не доделал, так как мне они были не особо нужны. Библиотека проверена и успешно компилируется Visual Studio 2010 и 2012, gcc 4.8, mingw 4.8. Проще всего совладать оказалось с компилятором Microsoft, сделать счастливыми gcc было куда сложнее, причем с внутренней ошибкой бывало падали все компиляторы, порой даже без вразумительных криков.

Привет, коллеги.
Хочу в этом топике выложить инструкцию, как быстро прикрутить Thrift, к своим поделкам.
Thrift — технология для организации межпроцессного взаимодействия между компонентами системы. Была разработана где то в недрах Facebook. Посути это кросс-языковой фреймворк для создания RPC сервисов, на бинарном протоколе. С помощью этого решения можно «подружить» компоненты написанные на разных языках C#, C++, Delphi, Erlang, Go, Java, PHP, Python, Ruby, итд. Описание сигнатур сервисов и данных осуществляется с помощью специального IDL — языка. Технология, по своей сути, похожа на COM, но без всей этой обвязки с регистрацией компонент. Так же не будем забывать, что COM это технология только для Windows, в то время как Thrift — кросплатформенна.

Вобщем решил поэкспериментировать, попробовать вынести часть нагруженной-вычислительной логики из Java в С++, в надежде что нативный С++ код будет немного производительней, и за одно опробовать Thrift RPC, в надежде что это быстрее чем REST.
Как и положено, без бубнов и граблей не обошлось!

Давным-давно, когда трава была зеленее, а деревья выше, жил-был тролль, по имени Xenocephal. Жил он, в принципе, во многих местах, но мне повезло встретить его на одном форуме, где я, в то время, набирался ума-разума. Я уже не вспомню топика, в котором протекала беседа, но суть ее сводилась к тому, что Xenocephal пытался убедить всех окружающих, что Lisp (с его макросами) — всему голова, а C++, с его шаблонами, жалкое подобие левой руки. Также утверждалось, что наметапрограммировать в нем что-то сложнее набившего оскомину факториала не представляется возможным.

Хотелось бы тоже написать о своем опыте обучения в Японии, а именно в Киотском Университете. Сразу оговорюсь, что обучение не было связано с IT, происходило это 8 лет назад, но возможно кому-то пригодиться мой опыт. Это будет вводная статья о этапе подготовки документов и прохождения отбора. Надеюсь тот, кто ездил по этой программе недавно, сможет дополнить более свежей информацией. Раньше уже был пост от об учебе в Aizu от cherepaha, так что часть информации будет пересекаться.

Как все начиналось.

Земля остыла, вымерли динозавры и в один солнечный весенний вечер, решил я посетить презентацию программ обучения в различных зарубежных странах. Организовывалось это представителями различных посольств и происходило все в Петербурге. Так я узнал о стипендии Monbukagakusho и программе стажер-исследователь поддерживаемой правительством Японии (Ministry of Education, Culture, Sports, Science and Technology). Всегда была мечта уехать в далекую экзотическую страну, также хотелось просто попробовать подать документы на обучение за границей. Я решил попробовать.

Дайте-ка угадаю: вы согласны с тем, что писать тесты — это хорошо. Это повышает надежность системы, ускоряет разработку, проект с хорошим тестовым покрытием поддерживать легко и приятно, а TDD — это вообще почти идеал процесса разработки. Но не у вас в проекте. То есть, оно клёво, но, к сожалению, сейчас столько работы — просто завал. Куча задач, одних только критических багов — два десятка, плюс надо срочно дописать этот модуль и еще написать письмо заказчику… Так что тесты, наверное, будем прикручивать уже в конце, если время останется. Или в следующем проекте. Нет, ну там точно полегче будет. Скорее всего.

Как, узнали ситуацию?

Так вот — чушь всё это. Сфера ИТ — бесконечна, как вселенная, куча работы будет всегда. Можно или начать писать тесты прямо сейчас, или не сделать этого никогда. Я тут набросал короткий план, как начать это делать за 10 шагов, по шагу в день, по 10 минут на шаг. И когда я говорю «10 минут» я имею в виду не «3 с половиной часа» и не «ну сколько-то времени, лучше побольше», а именно 600 секунд. Если у вас нету в день 600 секунд свободного времени — срочно меняйте проект, работу, профессию, страну проживания (нужное подчеркнуть), потому что это не жизнь, а каторга какая-то. Поехали.

Мотивация

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

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

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

Сегодня я хочу поделиться с вами моим вольным переводом статьи, написанной Сергеем Повзнером (Sergey Povzner). Сергей ведёт блог bongizmo.com и занимается разработкой туристических гидов под общим названием Citybot.

В то время как Android продолжает свой невероятный рост, всё больше и больше программистов начинают разрабатывать приложения на этой платформе. Если ты начинаешь свой путь сегодня, то ты определенно — счастливчик. За последние годы Android значительно повзрослел и избавился от множества детских болезней. Информации по платформе более чем достаточно. Я же расскажу о самых важных ресурсах.

Статья будет полезна как новичкам, так и опытным разработчикам. Это гид по миру Android-разработки.

Что такое хороший язык программирования? Какими качествами и характеристиками он должен обладать? Ответ дать сложно. Вот одно из возможных определений: хороший ЯП должен хорошо решать возложенные на него задачи. Ведь ЯП — лишь инструмент в руках программиста. А инструмент обязан помогать нам в работе. В конце концов, это же и есть причина его создания. Разные ЯП стараются решать разные проблемы (с переменным успехом). Цель, которая ставилась при проектировании Clojure — сделать написанные нами программы простыми. И, как следствие, ускорить их создание, тестирование. А главное, уменьшить время на их понимание, изменение и сопровождение.

Кто-то называет прокрастинацию «чумой 21 века», но наверняка это не так. Это психологическое состояние свойственно не только нам, людям «нового времени», наверняка от нее страдали и многие наши предки. Предлагаю ознакомиться с ее видами и способами борьбы с ней на ярких и узнаваемых примерах.