Человеческая память для меня загадка. Являясь обладателем слабой памяти с детства, вечно забываю о некоторых нюансах окружающего меня мира. Тем не менее, эти данные должны быть под рукой. И когда не хватает блокнота, на помощь приходят текстовые файлы. Один из таких файлов содержит небольшую сборку повседневных и обыденных команд Maximа.

Я думаю, всем из нас известна данная система компьютерной алгебры. Она не является конкурентом Wolfram Mathematica, но она обладает именно тем функционалом, который я требую от математического софта. Если говорить проще и доступнее — считать можно на всём, от палочек до суперкомпьютеров, и далеко не всегда задачи инженерной практики целиком переносятся с бумаги в программный код. Одним из примеров, который я честно говоря, еле-еле застал, является сегодня забытая поделка нашего конверсионного производства — цельнометаллический бытовой вакуумный гражданский термос, который выпускался ранее ещё в СССР на Урале. Чтобы наладить его производство институт, в котором я учусь, де-факто вручную на счётных машинках высчитал все необходимые параметры рабочего оборудования. Поэтому лицензия на Mathematica — не показатель и не ценз пригодности к практике. Считать, повторюсь, можно на всём.

От слов к делу. Ниже разбиты на категории те моменты в документации Maxima, которые желательно знать для начинающего пользователя данной СКА.

CoffeeScript поистине удивительный язык, который позволяет взглянуть на JavaScript с совершенно иной и намного более притягательной стороны. Давным давно, когда я только начинал заниматься фронт-эндом — меня буквально силками заставляли писать именно на нём (корпоративный стандарт), сейчас же я не могу писать на языке оригинала.

За время (уже более двух лет), проведённое за штурвалом этого препроцессора, накопилось довольно много «хотелок», которые желалось бы увидеть в JS (благо есть опыт общения с другими языками), некоторые из которых мне удалось претворить в жизнь, местами коряво, но как есть — CoffeeScript позволяет почти что придумывать свои конструкции. Об этих «хотелках» я и хочу поведать в статье, прошу под кат.

Привет! Меня зовут Валерий Зайцев, я клиентсайд-разработчик проекта Таргет Mail.ru. В нашем проекте мы используем небезызвестную библиотеку Backbone.js, и, конечно же, нам стало чего-то не хватать. Поразмыслив над возможными решениями наших проблем, я решил написать свое дополнение к Backbone.js, как говорится с блэкджеком и… О нем я и хочу рассказать в этой статье.

Ribs.js — библиотека, расширяющая возможности Backbone. И прелесть в том, что именно расширяет, а не изменяет. Вы можете использовать ваш любимый Backbone, как и прежде, но по необходимости задействовать новые возможности:

• вложенные атрибуты: работа с атрибутами модели любой вложенности;
• вычисляемые атрибуты: добавление в модель атрибутов, которые автоматически пересчитываются при изменении зависимостей (других атрибутов модели);
• биндинги: динамическая связь между атрибутами модели и DOM-элементами.

Рассмотрим эти возможности подробнее.

«Кто нам мешает, тот нам поможет»
к/ф «Кавказская пленница»

Преамбула

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

С другими техническими параметрами все более-менее понятно и очевидно. Например, размеры экрана при желании можно измерить рулеткой или линейкой. Разрешение экрана и размер пикселя тоже можно «пощупать», разглядывая экран с близкого расстояния. Многие параметры (например, яркость и контрастность экрана, глубина черного, равномерность засветки, отображение градиентов, резкость, углы обзора, гамма и так далее) можно проверить с помощью специальных тестовых программ начиная от простейших утилиток типа «Nokia Test», и до программ для комплексной настройки, проверки и сравнения, например «LCD Vs_mon».

Но, к сожалению, время отклика LCD экрана так просто посмотреть и «пощупать» не получается, и остается ориентироваться на значения, указываемые изготовителем в паспорте или рекламном буклете. Но тут тоже все довольно запутано. Существуют разные понятия времени отклика: GtG (grey to grey, от серого к серому), BtW (black to white, от черного к белому), BtB или BWB (black-white-black, с чёрного на белый и обратно). К тому же каждый изготовитель измеряет время отклика монитора по собственной методике, некоторые из них для уменьшения времени отклика используют технологию разгона Overdrive, и поэтому прямое сравнение мониторов или телевизоров разных марок друг с другом может быть некорректным.

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

Можно ли как-то это сделать?

В принципе конечно можно, но…

8 апреля 2014 года в мире высоких технологий случилось страшное — Microsoft наконец официально прекратила поддержку своей самой популярной операционной системы Windows XP. Операционная система осталась без заплаток для угроз нулевого дня, миллионы пользователей оказались в опасности заражения вирусами. Тем не менее, далеко не все спешат переходить на новые версии как этого желает софтверный гигант — кому-то жалко денег, кто-то привык к до боли знакомому интерфейсу и нескучной обоине с зелеными холмами. Намного серьезнее все обстоит в корпоративной среде, где на Windows XP работают тысячи машин, обновление которых выльется в миллионные траты и непредвиденные проблемы с годами отточенным корпоративным софтом.

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

Зачастую вроде бы простые задачи верстки требуют сложной структуры HTML-разметки и использования CSS-трюков. Центрирование элементов или выравнивание контента может быть очень утомительным. Одна из таких задач — это выравнивание элементов верхней части сайта так, чтобы логотип был слева, а пункты меню — справа. Можно использовать float и position:absolute, а для выравнивания по вертикали — добавлять margin и padding разным элементам. Вроде бы ничего сложного. Но если сайт должен корректно отображаться и на мобильных устройствах, возникает много проблем.



Ниже описан лаконичный способ решения этой проблемы.

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

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

Привлечение клиентов

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

Вольный перевод статьи Якуба Линовски — «A Good User Interface».

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

Уровень подготовки веб-мастера: любой

В Интернете немало сайтов, содержание которых доступно на нескольких языках, и таких ресурсов становится все больше. Тем не менее, создание многоязычного веб-сайта – это не просто перевод или локализация (L10N). Здесь необходимо принимать во внимание множество других аспектов, каждый из которых относится к интернационализации (I18N). В Справке Google вы можете найти информацию о том, как оптимизировать для Google Поиска мультирегиональные и многоязычные сайты, а в этой статье мы хотим поделиться несколькими советами по созданию ресурсов для многоязычной аудитории.

1. Создавайте многоязычные страницы с помощью разметки, а не таблиц стилей

Язык и направленность текста тесно связаны с содержанием страницы. В этой связи старайтесь всегда использовать разметку, а не таблицы стилей. Задавайте язык и направление текста (по крайней мере для материалов в html) с помощью псевдоклассов lang и dir:

<html lang="ar" dir="rtl">

Мы не советуем применять оригинальные решения, такие как специальные классы или идентификаторы.
Полагаться на таблицы стилей не стоит: пользовательские агенты могут игнорировать такие свойства, как направление или двунаправленный текст Unicode. Для XML ситуация прямо противоположна: поскольку XML не поддерживает специальную разметку для интернационализации, в этом случае рекомендуется использовать таблицы стилей.

Интро

Это краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя из компании Apigee Labs. Apigee занимается разработкой различных API-сервисов и консталтингом. Кстати, среди клиентов этой компании засветились такие гиганты, как Best Buy, Cisco, Dell и Ebay.

В тексте попадаются комментарии переводчика, они выделены курсивом.

Собираем API-интерфейсы, которые понравятся другим разработчикам

Понятные URL для вызовов API

Первый принцип хорошего REST-дизайна — делать вещи понятно и просто. Начинать стоит с основных URL адресов для ваших вызовов API.

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

/dogs для работы со списком собак
/dogs/12345 для работы с отдельной собакой

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

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

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

Авторы задумались: может быть британские политики просто не верят британским учёным? Тогда они решили объявить беспрецедентную акцию сбора мнений (Call For Evidence) о текущем состоянии дел. Высказаться могли все желающие, как корпорации-гиганты, так и лично любой простой гражданин. Предлагалось ответить на вопрос: "надо ли что-то изменить (и если надо, что именно) в системе интеллектуальной собственности Британии, чтобы она способствовала инновациям и экономическому росту?"

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

Если ответить одним словом: плохо. Копирайт идёт не туда, и требуется срочно предпринять ряд действий, первым из которых предлагается ввести «Копирайт Хаб». Это будет не просто реестр всех произведений, а универсальная всемирная система торговли копирайтом. Первая версия хаба должна заработать уже в июле 2013 года.

В этой короткой заметке я хотел бы систематизировать (а именно, расположить в иерархию) многие популярные принципы проектирования программных приложений (test-driven development, ООП, SOLID и т. д.), а также рассмотреть следствия из этой иерархии.

В частности, такая иерархия (я надеюсь) позволит лучше расставлять приоритеты в разработке и профессиональном росте, лучше понимать старые технологии и быстрее изучать новые. При появлении новой парадигмы разработки (a la test-driven development) вы сможете быстро включить ее в эту иерархию и, следовательно, быстрее понять, из каких принципов исходили создатели парадигмы и как правильно ее использовать. Новичкам в программировании статья может быть полезна как обзор существующих принципов.

И в качестве самого базового я полагаю разумным считать принцип «управления сложностью/минимизации технической сложности» МакКоннела. А самыми важными срествами минимизации сложности являются модульность и абстракция.

Даже если вы никогда в жизни не думали, что занимаетесь тестированием, вы это делаете. Вы собираете свое приложение, нажимаете кнопку и проверяете, соответствует ли полученный результат вашим ожиданиям. Достаточно часто в приложении можно встретить формочки с кнопкой “Test it” или классы с названием TestController или MyServiceTestClient.



То что вы делаете, называется интеграционным тестированием. Современные приложения достаточно сложны и содержат множество зависимостей. Интеграционное тестирование проверяет, что несколько компонентов системы работают вместе правильно.

Оно выполняет свою задачу, но сложно для автоматизации. Как правило, тесты требуют, чтобы вся или почти вся система была развернута и сконфигурирована на машине, на которой они выполняются. Предположим, что вы разрабатываете web-приложение с UI и веб-сервисами. Минимальная комплектация, которая вам потребуется: браузер, веб-сервер, правильно настроенные веб-сервисы и база данных. На практике все еще сложнее. Разворачивать всё это на билд-сервере и всех машинах разработчиков?

В последнее время в рунете появляется статей про технологию аукциона в реальном времени – Real-time Bidding (RTB). Пока эта тема больше обсуждается на специализированных ресурсах, поэтому я буду одним из первых, кто расскажет о ней на Хабре. Это подлинная, в том числе и технологическая инновация на рынке интернет-рекламы, с которой пора знакомить с ней тех, на кого она собственно нацелена: рекламодателей, покупающих рекламу в интернете, и площадки, зарабатывающие на продаже медийной рекламы и трафика (Habrahabr.ru, например :).

По прогнозам, расценки на медийную рекламу в интернете в 2013 году вырастут на 14 процентов, в то время как в среднем реклама подорожает на 10 процентов. Медийная реклама обгонит и другие инструменты интернет-рекламы – к примеру, контекстная реклама вырастет всего на 13%. На мой взгляд, драйвером этого роста станет именно RTB.

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

6 декабря 2012 г. Google прекратил регистрацию новых аккаунтов для бесплатной версии Google Apps.

У клиентов нашей компании постоянно возникает потребность в электронной почте, обслуживающей их сайты.
Раньше мы настраивали им Google Apps, но после 6 декабря, изучив предлагаемые на рынке решения, решили, что настала пора строить собственную почтовую систему.

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

• масштабируемость (неограниченное количество обслуживаемых доменов, общий объем почтовых ящиков 100 терабайт и больше);
• отказоустойчивость (все промежуточные сервисы должны быть продублированы);
• расширяемость (добавление новых узлов в систему должно быть легким и простым).

Начали с выбора хранилища под письма...

На самом деле выбор был небольшой:

• dovecot/cyrus с хранением в файловой системе через maildir/mailbox;
• dbmail с хранением в базе данных.

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

• доступ к ящикам через IMAP, POP3;
• sieve-скрипты для сортировки почты;
• прием почты через smtp и lmtp протоколы;
• администрирование через cli и SQL-запросы.

В последнее время, RubyMotion становится все более популярным инструментом для разработки под iOS. После близкого знакомства с ним становится понятно, почему Ruby гораздо более привлекательный для этих целей язык, чем Objective-C.

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



Представим ситуацию. Есть не очень опытный проект-менеджер. На нем висит большой проект и три дизайнера, которые готовые над этим проектом поработать. Позвольте их представить — Вася, Лена и Петя (слева направо на картинке). Немного повысим уровень сложности нашим ребятам. Пусть все они находятся в разных городах, то есть за соседними столами не сидят, на пятничные попойки обеды вместе не ходят и иначе как через мессенджеры и почту связаться не могут. Проект большой и запланирован не на один месяц. Заказчик любит часто изменять свои решения или придумывать новые фичи.

Посмотрим как они выкрутятся?

Написать расширение для google chrome несложно. Но при написании первого раширения могут возникнуть (и возникают) вопросы. Большинство мануалов по написанию первого расширения расчитаны на использования манифеста первой версии, поддержка которого в скором будущем прекратится.

В этой статье будет рассмотрено:

• Как составлять манифест v.2
• Как работать с удаленными ресурсами
• Как работать с cookies
• Как работать с local storage
• Как работать с уведомлениями

Для борьбы со спамом Майкрософт предложила ввести «электронные марки», которые нужно покупать у провайдера своей почты, чтобы отправить e-mail. Конечно, такой подход резко сократил бы поток спама, но фраеров, желающих перейти на полностью платную почту, когда существуют тысячи бесплатных способов отправить e-mail — не нашлось, и не найдется в обозримом будущем. Кроме того, предложенный компанией подход не гарантировал того, что перешедшие на предложенную почтовую систему будут ограждены от спама, он лишь гарантировал, как и обычная почтовая система, что спамеры заплатят своему провайдеру (почте) за отосланные письма, но как это должно утешить того, кто продолжит получать спам, хоть и в меньшем количестве?
Я предлагаю не бороться со спамом, а легализовать его, но так, чтобы все стороны получали от него выгоду: и рекламодатели, и провайдеры почты и, что самое главное, — конечный получатель. Как это сделать? Довольно просто.

Когда мы заказываем костюм в ателье или дизайн интерьера, нас не просят прийти с готовыми мерками, выбранным фасоном или цветом потолка. Профессиональные модельеры и дизайнеры задают вопросы и предлагают решения на основе наших целей.

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

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

В заказной разработке я наблюдаю 3 типа проблем, связанных с ожиданием готовых требований от клиента:

1. “Бизнес” не умеет формулировать хорошие требования, потому что не понимает процесса разработки и технологических возможностей. Спецификация содержит представление заказчика о решении проблемы, докопаться до сути которой по документу сложно.
   
   
2. “Бизнесу” не хватает времени на проработку требований. Часть вариантов использования системы, не продуманная заранее, вбрасывается в ходе разработки. Чем меньше практик, поддерживающих итеративный процесс (CI, автоматизированное тестирование, ограничение по количеству фич в работе), тем сложнее вносить изменения в требования.
   
   
3. “Бизнес” и “разработка” говорят на разных языках. Как следствие — ложное понимание требований, не проясненные предположения, вытекающие из них 'сюрпризы' в момент демонстрации. Несуществующую систему сложно описать на бумаге. Отсюда вытекают проблемы, которые можно обобщить словами заказчика: “Я не знаю точно чего хочу, но точно знаю чего не хочу”.

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

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

Ниже — обзор продуктовых техник, которые могут в этом помочь.