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

Наверняка постоянный читатель хабра знает, что такое Kickstarter и как за один год этому сервису удалось в корне изменить развитие компьютерных игр. К январю 2013 была собрана статистика за прошлый год — в 2012 году игры, успешно закончившие кампании на KS, получили инвестиции общей суммой в 83 миллиона долларов. Помимо впечатляющей суммы интересна и тенденция: за один последний год игровой сектор получил денег в 2 раза больше, чем за все предыдущие 3 года с момента основания Kickstarter. Похожая ситуация и с другими областями — но с играми она смотрится наиболее выигрышно.

Итак, как это связано со свободным софтом и его моделью разработки? Да напрямую. Как это происходило раньше: человек находил интересный проект, присоединялся к его разработке и проводил вечера после работы, а порой и рабочее время. Энтузиазм — это прекрасно, но недостаток свободного времени скорее его отобъет, чем привьет. Особенно на начальной стадии проекта, когда дел — масса, а свободного времени всего 4 часа в день. Очевидно, что основной костяк разработчиков на начальной стадии должен работать full-time.

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

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

На днях мы открыли новый набор в Школу анализа данных. Чтобы стать её студентом, нужно ответить на вопросы в тесте, сдать экзамены и пройти собеседование. Занятия, как всегда, будут проходить в офисе Яндекса в Москве, а также в Екатеринбурге, Киеве и Минске. В Питере у ШАД есть отделение в Computer Science Center. Если вы живёте в других городах, то можете учиться у нас заочно: общаться с преподавателями по электронной почте и смотреть видеолекции. Обучение в Школе бесплатное.



В ШАД преподают ведущие российские ученые — и те, кто живет в России, и те, кто работает за рубежом. Например, теорию машинного обучения ведёт Алексей Червоненкис, профессор Лондонского университета и один из создателей отечественной школы анализа данных. Автор курса по анализу данных и научный руководитель ШАД — профессор Rutgers University Илья Мучник, который когда-то был научным руководителем Аркадия Воложа.

Первое, что мы делаем, когда у нас возникает какой-то вопрос, — обращаемся к интернету. Там есть все и даже больше. И ситуация, когда что-то не удается найти, вызывает если не раздражение, то недоумение — это точно. Создается впечатление, что если чего-то нет в Сети, то это не существует вообще. Адрес сайта сегодня — это документ, который надежней всех прочих документов подтверждает, что эта организация или персона вполне реальна. Вот такой вот парадокс нашего времени, когда твое существование в виртуальном мире делает тебя для многих гораздо реальнее и заметнее.

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

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

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

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

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

Мне, как и многим из вас, работать с bash и стандартными утилитами Linux гораздо удобнее и приятнее, чем с cmd.exe. Однако, к сожалению, порой обстоятельства складываются так, что операционную систему выбирать не приходится. Например, в моём случае корпоративным стандартом является Windows 7. К счастью есть способ сделать жизнь линуксоида в командной строке Windows комфортнее, о нём и пойдет речь ниже.

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



Всё это делает FightCode одним из лучших вариантов для новичков в подобных играх или для обучения программированию. Проект довольно молодой, и несмотря на то, что на сайте зарегистрировано почти 9000 игроков, пробиться в первую сотню рейтинга можно без особых усилий. Очень удобно организована система боёв со случайными соперниками — из всех доступных роботов автоматически выбираются те, чей рейтинг близок к вашему. Очки считаются по системе Эло — победа над более сильным противником даёт гораздо больше очков, чем над слабым.

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

Введение

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

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

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

1. Основы

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

Это статья была написана для людей, которым всегда интересно знать как работают разные вещи. Для тех разработчиков которые обычно пишут свои программы на высоком уровне, C, C++ или Java — не важно, но при этом столкнулись с необходимостью сделать что-то на низком уровне. Мы будем рассматривать низкоуровневое программирование на примере работы bootloader-а.

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

Каждый разработчик время от времени сталкивается с непонятными ошибками. Как правило, их причина неочевидна и чтобы их пофиксить, нужно детально понять, что происходит в коде. Модуль xdebug — инструмент для профессионального поиска ошибок. Когда выполнение кода доходит до точки останова, xdebug присоединяется к IDE, которая слушает порт (по умолчанию 9000). Эта схема хорошо работает на localhost. Если вы находитесь в прямой видимости удаленного сервера, то можно прописать в конфиге xdebug ваш ip, и производить отладку аналогично. Но если компьютер разработчика находится за NAT, то прямой доступ с сервера к нему невозможен.
Я давно использую xdebug на localhost, но, разобравшись с port forwarding, научился отлаживать на удаленном сервере и решил написать инструкцию, которая может быть полезной каждому разработчику, а главное — она работает.
В качестве IDE я использовал PhpStorm, браузер Chrome, ОС Ubuntu. Port forwarding без проблем работает и в windows.

Техника – это способ справиться с заданием, и у нас, разработчиков и дизайнеров фронтэнда, этих способов бывает достаточно много. При это, будучи погруженными в рутинную работу, мы порой не всегда замечаем как стремительно меняется окружающая нас сфера. В период с 2002 по 2010 годы сообщество фронтэнд-разработчиков буквально покрывалось язвами избыточного кода и ресурсов, от которых страдали и работа сайтов, и удобство их использования. Чтобы с этим справиться, мы придумали уйму хаков, трюков и уловок под кодовым названием «техника». Мы по-прежнему продолжаем выполнять поставленные перед нами задания, просто используем не самые эффективные способы.



Оборачиваясь назад, отметим, что в последние несколько лет установились новые, лучшие, стандарты и способы их применения, позволяя нам создавать более продвинутые «техники». Этот новый мир, открытый перед нами, называется «modern web». Web 2.0, которым восхищались в свое время, сегодня для нас стал запутанным и застойным. С одной стороны нет сомнений в том, что подобная судьба постигнет и то, что мы называем «modern web». С другой — пока что мы можем использовать этот термин и злоупотреблять им сколько угодно, пока понимаем, что он означает.



В 2010 появился стандарт HTML5, обеспечивающий совершенно новую, полустандартизованную веб-среду. Такие браузеры, как Opera, Firefox, Chrome и Safari приняли нововведения, и их разработчики вышли за пределы реализации стандартов и изучения интерфейса программирования приложений. Чтобы представить себе, насколько автономны эти браузеры, можно ознакомиться с отличной наглядной демонстрацией поддержки HTML5 на www.html5readiness.com.

Продолжение перевода статьи Джона Оллспоу о личных качествах ведущих разработчиков.

Зрелые разработчики не жалуются просто так

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

Небольшое предисловие

Меня всегда интересовала история появлений научных понятий. Перед изучающим новый предмет сначала встает череда безликих определений. Некоторые из них таковыми и остаются, другие привлекают внимание и со временем вырастают в полноценные объекты «картины мира». В качестве недоступного идеала такого стремления можно привести высказывание Литлвуда о Рамануджане:

каждое натуральное число было его лучшим другом

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

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

Это перевод статьи, написанной Джоном Оллспоу, который на данный момент является старшим вице-президентом технического отдела в Etsy.

Продолжение перевода здесь

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

Но в то же время, все мои знакомые преуспевающие разработчики помнят своих наставников, которые научили их тому, что значит быть „ведущим“.

К написанию сей заметки меня сподвигло то, что я устал делать развёрнутые замечания на эту тему в комментариях к статьям, где в качестве части инструкции по сборке и настройке чего-либо для конкретного дистра предлагают выполнить make install.

Суть сводится к тому, что эту команду в виде «make install» или «sudo make install» использовать в современных дистрибутивах нельзя.

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

Наблюдая за со своими знакомыми, которые недавно начали изучать программирование или перешли на Eclipse c другой IDE, я часто замечаю что они почти не используют вспомогательные инструменты среды разработки. Они либо не знают о них вообще, либо не понимают какую практическую пользу они могут принести.
Данная статья предназначена в основном для начинающих в работе с Eclipse. Но в процессе подготовки статьи я сам узнал о нескольких простых и удобных инструментах, которые за два года активной разработки ни разу не использовал.
В данной статье речь пойдет о навигации и редактировании.
Внутри скриншоты.

Данная статья написана под влиянием книги Дэвида Коупленда «Build Awesome Command-Line Application in Ruby» (купить, скачать и изучить дополнительные материалы). Большая её часть будет посвящена проектированию дизайна CLI-приложений вне зависимости от используемого языка. По ходу будут обсуждаться и вещи специфичные для ruby, но не страшно, если вы его не знаете, кода будет не слишком много. Можно считать эту статью довольно подробным обзором вышеупомянутой книги с вкраплениями собственного опыта. Книжку рекомендую!

Для начала я задам вопрос. Если посмотреть на сообщества IT-шников, можно заметить, что несмотря на обилие программ с красивым графическим интерфейсом, приложения командной строки остаются весьма популярны. Почему?
Ответов несколько. Во-первых, это красиво удобно — если вы можете описать задачу командой в командной строке, то её гораздо проще автоматизировать, чем если вам приходится анализировать передвижения мыши и клики на разные пункты меню. Во-вторых, это даёт возможность комбинировать программы невероятным числом способов, чего сложно добиться с помощью графических интерфейсов.
В значительной степени философия Unix базируется на том принципе, что множество маленьких утилит, каждая из которых умеет делать свою конкретную задачу — это лучше, чем одна многофункциональная программа-универсал. И это одна из причин успеха Unix-систем в мире IT-шников.
Наверное, каждый понимает, что обычного пользователя вряд ли удастся сманить от GUI к CLI, давайте сосредоточимся на нас, «компьютерщиках» и конкретизируем наши пожелания к CLI-приложениям.

Я хочу предложить вам поломать голову вечерок-другой над интересными задачками, на регулярные выражения, которые Callum Macrae выкладывает на своем сайте на GitHub каждый Вторник.

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

Тесты используют JavaScript Regex движок вашего браузера, который обладает всеми основными возможностями PCRE.  Подробнее можно посмотреть тут (англ.) , в колонке ECMA в таблице.

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

UPD: В регулярных выражениях ECMAScript нету ретроспективных проверок.