Вступление

Уже около двух лет я участвую в OpenSource проекте SourceAnalyzer, и вот появилась необходимость написать парсер для языка Python, который должен уметь строить граф вызовов (Call Graph) и граф зависимостей классов (Class Graph Dependency). Если точнее, граф строится с помощью других инструментов, а парсер должен лишь подготовить для этих инструментов данные.

Процесс работы над парсером был довольно занятным и мне бы хотелось поделиться с вами приобретенным опытом, а также поведать о некоторых подводных камнях, которые встретились на этапе разработки.

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

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

В данном обзоре я опишу свои впечатления от тестирования 7 онлайн-сервисов для локализации ПО и сравню их по основным показателям (см. таблицу в конце статьи).

Нам неоднократно поступали предложения о тестировании мультиварок, но до определенного времени мы от них отказывались — ну что такого можно рассказать о мультиварке. Однако, предложения продолжали поступать, и примерно после 5-6 письма редакция Box Overview задумалась, и решили сделать не просто тест одной мультиварки, а глобальное тест-сравнение 8 мультиварок нижнего ценового сегмента от разных брендов.



В нашем тесте участвуют 8 мультиварок от компаний Vitek (VT-4209), Kitfort (KT-201), Scarlett (SL-MC411S01), Polaris (PMC 0527D), Rolsen (RMC-5500D), Redmond (RMC-250), Philips (HD2173) и Panasonic (SR-MHS181).

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

Всем привет! Недавно вышел перевод статьи о том, как TJ Holowaychuk прощался с Node.js, решив двигаться в сторону Go. В конце статьи была ссылка на посвящённый сравнению и критике языка Go пост Уилла Ягера, который просили перевести — собственно, с результатами перевода я и предлагаю ознакомиться. Я пытался более-менее сохранить как многословный стиль изложения, присущий автору, так и оригинальную разбивку на предложения и параграфы.
Буду очень рад любым конструктивным замечаниям и предложениям по переводу, опечаткам и/или оформлению, но очень прошу помнить, что точка зрения переводчика может не совпадать с позицией автора переведённой статьи.

Многие пробовали играть во Flappy Bird. Редко кому удается пролететь за 50 труб, очень немногие долетают до сотни-двух. Некоторые пробовали создать бота, в том числе на хабре. Удивительно, но даже у самого успешного бота, которого можно найти на просторах интернета, результаты не очень-то впечатляют – что-то около 160 очков. Возникает вопрос, а можно ли вообще играть во Flappy Bird бесконечно долго? Или всегда с некоторой, пусть и небольшой, вероятностью может встретиться последовательность препятствий, которую даже опытный игрок/идеальный бот не сможет преодолеть?

И тут на помощь приходит математика. Давайте найдем выигрышную стратегию для Flappy Bird.

Ценник должен быть с печатью или подписью. Он является документом и обязательно должен быть на товаре. Если вы видите что-то с ценником (неважно, где и как оно стоит), вы имеете право купить его по цене на нём.

Пример: вам говорят, что товар по акции кончился. Вы видите один в витрине в герметичном ящике под потолком, но с ценником. Вам не имеют права отказать в его продаже.

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

Решил собрать сервисы, которые могут быть полезны веб-разработчикам и дизайнерам. Буду рад, если кто-то найдет для себя полезный сервис. Осторожно, под катом куча картинок!

Коллеги,

а помните была такая статья-перевод на Хабре Чек-лист разработчика языка программирования Колина Макмиллена о проблемах новых языков программирования? Статья просто изумительная! Если не читали — обязательно посмотрите.

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

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

Мне со школьных времен был интересен алгоритм вывода аналитических производных и упрощения выражений. Данная задача была актуальна впоследствии и в вузе. Тогда-то я реализовал ее, только получилось все не так, как хотелось: вместо кода IL у меня просто генерировался C# код в текстовом виде, сборки не выгружались, ну и к тому же не было возможности вывода производных в аналитическом виде. Однако потом я решил все-таки реализовать такую библиотеку, так как интерес остался. Стоит отметить, что таких библиотек в интернете большое количество, но нигде я не нашел именно этапа компиляции выражений в IL код, т.е. по сути везде выполняется интерпретация, которая не столь эффективна, в отличие от компиляции. Ну и к тому же я это разрабатывал чисто для себя, для изучения новых технологий, особо не надеясь, что результат моих трудов может где-нибудь потребоваться. Для нетерпеливых: исходники, программа.

Используемые программы и библиотеки

1. GOLD Parsing System — IDE для написания грамматик и генерации кода лексеров и парсеров под различные языки (C, C#, Java, JavaScript, Objective-C, Perl, Python, Ruby и др.). Основана на LALR парсинге.
2. Visual Studio 2010
3. GOLD.Engine — сборка под .NET, подключаемая для взаимодействия со сгенерированными таблицами.
4. NUnit — Открытая среда юнит-тестирования приложений для .NET.
5. ILSpy — OpenSource дизассемблер под .NET.

Этапы, на которые я разбил весь процесс:

1. Построение дерева выражения
2. Вычисление аналитической производной
3. Упрощение (симплификация) выражения
4. Обработка рациональных дробей
5. Компиляция выражения

Рад сообщить, что вышел перевод отличнейшего учебника Дасгупты, Пападимитриу, Вазирани «Алгоритмы», над которым я работал последние несколько лет. В книге многие алгоритмы объяснены гораздо короче и проще, чем в других учебниках: с одной стороны, без излишнего формализа, с другой — без потери математической строгости. Откройте книгу на каком-нибудь известном вам алгоритме и убедитесь в этом. =)

В общем, угощайтесь: печатный вариант перевода, электронный вариант перевода (PDF), печатный вариант оригинала, электронный вариант оригинала (PDF).

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

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

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

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

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

Это первая из двух статей, рассказывающая о тестировании с помощью gremlins.js и grunt-gremlins. Первая статья — перевод официальной документации gremlins.js. Вторая — опыт внедрения gremlins.js в реальный проект при помощи grunt-gremlins.

Gremlins.js это monkey testing библиотека написанная на JavaScript, для Node.js и браузеров. С ее помощью проверяется надежность веб-приложений под полчищем гремлинов.

Kate: What are they, Billy?
Billy Peltzer: They're gremlins, Kate, just like Mr. Futterman said.

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

В статье будет рассказано, как с помощью гема YARDможно написать грамотную документацию к рельс проектам и автоматически сгенерировать документ, где эта документация будет представлена в презентативном виде. Пример документации можно посмотреть в коде сайта ВалиИзРашки.

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

Пользуясь случаем, хотим сообщить новость: сегодня состоялось открытие Технопарка — нашего образовательного проекта, о котором мы уже не раз писали на Хабре (например, тут, тут и тут). Теперь у технопарковцев есть свое собственное помещение. Изначально Технопарк задуман как место, где талантливые студенты МГТУ им. Баумана могут получить дополнительное образование в сфере веб-разработки, дизайна и программирования, а также окунуться в работу над реальными проектами высокой сложности. В общем, у Технопарка сегодня знаменательный день, и поэтому первый выпуск в рубрике «Переводы» мы решили посвятить образовательным ресурсам для веб-разработчиков и веб-дизайнеров. Ведь пока такие Технопарки не распространились по всей стране, разработчикам зачастую приходится заниматься исключительно самообразованием.

На момент написания этой статьи в JavaScript еще не существовало официальной модульной системы и все эмулировали модули как могли.

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

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

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

Думаю многие из вас читали прекрасную статью Addy Osmani Writing Modular JavaScript With AMD, CommonJS & ES Harmony, которая стала одной из глав его книги Learning JavaScript Design Patterns в этой статье рассказывается про «современные» JavaScript модули или же читали достаточно старую статью JavaScript Module Pattern: In-Depth 2010 года про «старые» модули.

Я не буду переводить эти статьи и не буду делать из них солянку. В своей статья я хочу рассказать о моем модульном пути. О том как я проделал путь от «старых» модулей к «новым» и что использую сейчас и почему.

Введение

Все, кто так или иначе связан с .NET программированием знает, что уже в следующую версию Visual Studio будет встроен новый язык программирования — F#, который позиционируется как функциональный, чем сразу, так уж повелось, вызывает подозрения в бесполезности. Для того, чтобы показать, что F# — куда больше, чем просто ФЯП (хотя и просто ФЯП — это очень немало), я и написал все нижеследующее.
Эта статья, несмотря на изрядную длину, не претендует на то, чтобы полностью описать всю функциональность языка. Это всего лишь краткий обзор, призванный продемонстрировать широкий спектр возможностей, каждая из которых заслуживает отдельной статьи, и даже не одной.
Кроме того, написав такой пространный пост, я хотел сделать задел на будущее, чтобы в дальнейшем мне не отвлекаться на незначительные вещи базового уровня. Конечно, сразу головой в пруд — это действенно, но и какой-никакой фундамент не помешает.
А уже в следующий раз я приведу пример на волнующую тему пригодности F# для обычной профессиональной программистской деятельности.
И еще раз, под катом действительно МНОГО текста. И не говорите потом, что я вас не предупреждал. =)

Возможно, многие из читателей задавались вопросом, как людям удаётся собирать кубик Рубика 3×3 за 7 секунд. Если даже предположить, что рекордсмену сильно повезло, то таблица мирового рейтинга по среднему из пяти результатов уже не оставляет сомнений: если больше 80 человек в среднем укладываются в 12 секунд, очевидно они что-то знают. В этом кратком обзоре я постараюсь приоткрыть секреты скоростной сборки. Сразу оговорюсь, что после прочтения этой статьи вы не станете чемпионами: здесь приведены только основные моменты и ссылки на более подробную информацию. Кроме того, даже после изучения метода полностью вам потребуются долгие тренировки для достижения хороших результатов. Зато вы получите неплохое представление о том, как это делается, и при желании будете знать, куда двигаться дальше. Я думаю, при достаточной усидчивости после нескольких месяцев тренировок многие смогут достичь среднего результата в районе 30 секунд.

Я работаю в команде семантического веба в Яндексе. Мы занимаемся тем, что создаем продукты на основе семантической разметки, делаем свои расширения и участвуем в развитии стандарта Schema.org.

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



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

Микроразметка состоит из словаря и синтаксиса.

Python — красивый и местами загадочный язык. И даже зная его весьма неплохо, рано или поздно находишь для себя нечто такое, что раньше не использовал. Этот пост отражает некоторые детали языка, на которые многие не обращают внимание. Сразу скажу: многие примеры являются непрактичными, но, оттого, не менее интересными. Так же, многие примеры демонстрируют unpythonic стиль, но я и не претендую на новые стандарты — я просто хочу показать, что можно делать вот так.

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

Я последние четыре года проработал на банки. Один год на Credit Suisse, офшорно из России с командировками в Лондонский офис, и 3 года – на Citigroup, живя в Нью-Йорке. И вот что я вам скажу: IT в банках – это интеллектуальное гетто, со всеми своими минусами и…минусами. Там встречаются очень умные ребята, крутые команды, но их значительно меньше чем в среднем по индустрии, а основная же масса работников – это зомби, производящие очень плохой код и затем костыли и припарки к нему.

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