Оглавление

1. Уравнения динамики

Введение

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

Интро

Это краткий перевод основных тезисов из брошюры «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 для работы с отдельной собакой

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

Транзакций на шине PCI достаточно много, в данном топике будет описаны только следующие:

• Конфигурационные транзакции
• Транзакции ввода/вывода
• Транзакции обращения к памяти

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

Первым движком, интерпретирующим js-код стал SpiderMonkey, который был представлен в браузере Netscape 2.0 в 1995 г. Миф о его быстром создании хорошо задокументирован. У Брендана Айка было всего 10 дней на дизайн языка и построение компилятора. Javascript был успешен с самого начала, и к августу того же кода Майкрософт уже встроила свою версию JScript в Internet Explorer 3.0. К концу 1996 язык был принят в комиссию для формальной стандартизации, и уже в июне следующего года обрел официальный стандарт ECMA-262. С тех пор поддержка JS стала обязательно для каждого браузера, и каждый крупный производитель начал строить свой движок для поддержки JS. В течение долгих лет эти движки развивались, заменяли друг друга, переименовывались, и становились основой для следующих движков. Отследить все созданные версии — задача не для слабых духом.

Сегодня мы поговорим про разработанную нами утилиту, которая оптимизирует тестирование PHP-кода с помощью PHPUnit и TeamCity. При этом нужно понимать, что наш проект — это не только веб-сайт, но и мобильные приложения, wap-сайт, Facebook-приложение и много чего ещё, а разработка ведется не только на PHP, но и на C, C++, HTML5 и т.д.

Методы, которые мы описываем, прекрасно адаптируются под любой язык, любую систему тестирования и любое окружение. Поэтому наш опыт может оказаться полезным не только разработчикам веб-сайтов на PHP, но и представителям других областей разработки. Кроме того, в ближайшем будущем мы планируем перевести нашу систему в Open Source ― без обязательной привязки к TeamCity и PHPUnit ― наверняка она кому-нибудь пригодится.

С распространением распределенных систем управления версиями (DVCS), таких как Git и Mercurial, я все чаще вижу дискуссии на тему правильного использования ветвления(брэнч) и слияния(мердж), и о том, как это укладывается в идею непрерывной интеграции (CI). В данном вопросе есть определенная неясность, особенно когда речь заходит о feature branching (ветвь на функциональность) и ее соответствие идеям CI.

Простой (изолированный) Feature Branch

Основная идея feature branch заключается в создании нового брэнча, когда вы начинаете работать над какой-то функциональностью. В DVCS вы делаете это в своем собственном репозитории, но те же принципы работают и в централизованных VCS.

Я проиллюстрирую свои мысли следующим рядом диаграмм. В них основная линия разработки (trunk) отмечена синим, и двое разработчиков, отмеченные зеленым и фиолетовым (Reverend Green и Professor Plum).

Разработчики, использующие Bundle Transformer, часто спрашивают у меня: «Какой минимизатор обладает самой высокой степенью сжатия?». В принципе, в сентябре прошлого года в своей статье «Вышел Bundle Transformer 1.6.2 или что изменилось за полгода?» я уже проводил сравнение минимизаторов по степени сжатия кода, но это сравнение было поверхностным и не было подкреплено цифрами.

В этой краткой статье мы проведем сравнение наиболее популярных алгоритмов минимизации CSS- и JS-кода на примере адаптеров-минимизаторов из Bundle Transformer. В качестве исходных файлов будут использоваться файлы bootstrap.css и bootstrap.js из Twitter Bootstrap версии 2.3.2. Измерять размеры файлов мы будем с помощью YSlow.

На момент написания этой статьи в 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 года про «старые» модули.

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

Введение

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

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

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

Текст рассчитан на начинающих пользователей, поэтому объясняются и иллюстрируются порой простейшие вещи.

Давно хотел написать на эту тему. Первым толчком послужила статья Miško Hevery "Static Methods are Death to Testability". Я написал ответную статью, но так и не опубликовал ее. А вот недавно увидел нечто, что можно назвать «Классо-Ориентированное Программирование». Это освежило мой интерес к теме и вот результат.

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

• это не дает никаких преимуществ по сравнению с процедурным программированием
• не стоит отказываться от объектов
• наличие статических членов класса != смерть тестам

Хотя эта статья про PHP, концепции применимы и к другим языкам.

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

Вас ждет много анализа и немного частных производных. Код прилагается.
Прошу под кат!

Откуда пошла дурацкая привычка сохранять счета, бухгалтерские и финансовые документы в формате MS Excel? Зачем хранить и передавать документы, предназначенные для печати в формате электронной таблицы, если есть специальный формат PDF? Однако, во всех бухгалтерских программах документы в первую очередь обязательно экспортируются в MS Excel и уже потом предлагаются альтернативные способы сохранения документов. От сюда и возникла задача: пусть бухгалтер сохраняет свои документы как хочет, но клиент должен получить их в формате PDF и обязательно точно в том образе, который бухгалтер сваял в шаблоне MS Excel.
В качестве бухгалтерской программы мы использовали бесплатную ВС: Бухгалтерию. (По правде сказать из этой программы можно сразу сохранять документы в PDF, но раз сказали excel, значит – excel.)
Бухгалтер выгружает XLS-файл в определенный каталог на диске, откуда мы должны его забрать, перевести в PDF и сохранить в другой каталог. Все это должно быть реализовано в виде веб-сервиса, то есть клиент должен увидеть и иметь возможность скачать свои pdf-документы в «Личном кабинете» на сайте.

Пути решения:

Первое, что захотелось сделать, – это отыскать готовую библиотеку для PHP или Perl и прямо «на лету» конвертировать файлы.
Такие библиотеки для работы с форматом Excel действительно нашлись, например: PHPExcel, PHPExcelReader, Spreadsheet::ParseExcel и др.
Эти библиотеки действительно хорошо работают, но делают именно то, для чего предназначены: выискивают данные в электронной таблице Excel и оперируют с ними.
Нам же нужно совсем иное – получить экселевскую таблицу в виде как для печати, со всеми картинками с печатями и подписями, с форматами шрифтов, и ячеек.

Второй вариант решения — виртуальный принтер. Суть его в том, что мы открываем файл в подходящей программе и отправляем его на печать, но не на настоящий принтер, а – на виртуальный, который вместо бумаги сохранит в файл, сначала в постскрипт формате ps, а потом сделает из него файл PDF.
Поскольку система ко всему еще и должна функционировать как веб-сервис, я выбрал в качестве платформы Linux с Apache. А в качестве программы, которая умеет открывать все файлы MS Office – бесплатный OpenOffice.org 3.4

Итак, что делаем:

Устанавливаем OpenOffice. В руководстве по по установке конвертера PyODConverter предлагают устанавливать версию OpenOffice.org 2.4 обязательно -headless, но я просто установил OpenOffice.org 3.4 из репозитория и все получилось.
После установки я попробовал запустить программу, но система отказалась, захотев еще Java Runtime Environment. А нужен ли он? Оказалось, что нет. И запускать OpenOffice целиком, чтобы отправить файл на виртуальный принтер вовсе ни к чему. У программы есть прекрасный конвертер в pdf, который легко вызвать из командной строки.

Делается это так:

В ряду ихтиандров водонепроницаемых моделей Sony Xperia 2013 года прибыло: вслед за 5-дюймовым Sony Xperia Z в строй встал 4,6" Sony Xperia ZR. От своих предшественников модель отличается улучшенными характеристиками водозащиты: уровень IP55/IP58 позволяет Xperia ZR выдерживать пребывание в пресной воде на глубине до 1,5 м в течение 30 минут. А аппаратная кнопка включения камеры позволяет без труда фотографировать или снимать под водой HD-видео. Режим серийной съемки позволяет делать снимки со скоростью 10 кадров в секунду.

Введение

На днях, свершилось событие, которое Я и думаю еще немало людей ждали. Авторы Yii Framework выкатили превью-версию.

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

Доброго времени суток, уважаемые Хабраюзеры!

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

Рисунок 1 – Взаимная блокировка 1-го рода с участием сигнальной переменной.

В рамках этого поста мы рассмотрим проблемы, которые возникают при использовании сигнальных переменных, и покажем, как их можно избежать.

Если вы разрабатываете приложения для XAML-based платформ, таких как WPF, Silverlight, Windows Phone, или Windows Store, то Prism, определённо, сильно поможет вам упростить их разработку. После создания нескольких проектов с использованием Prism, я убедился в работоспособности такого подхода и решил подготовить перевод официального руководства Prism. Итак, часть первая, что же такое Prism.

Оглавление

1. Введение
2. Инициализация приложений Prism
3. Управление зависимостями между компонентами
4. Разработка модульных приложений
5. Реализация паттерна MVVM
6. Продвинутые сценарии MVVM
7. Создание пользовательского интерфейса
   
   1. Рекомендации по разработке пользовательского интерфейса
8. Навигация
   1. Навигация на основе представлений (View-Based Navigation)
9. Взаимодействие между слабо связанными компонентами

Prism является руководством, разработанным для того, чтобы помочь проектировать и создавать насыщенные, гибкие и легко поддерживаемые Windows Presentation Foundation (WPF) приложения, Silverlight Rich Internet Applications (RIAs), и программы под Windows Phone 7-8, а также Windows Store приложений. Используя паттерны проектирования, которые воплощают важные принципы архитектурного дизайна, такие как разделение ответственности (Separation of Concerns, SoC) и слабая связанность (Loose coupling), Prism помогает вам проектировать и писать приложения со слабо связанными компонентами, которые могут независимо развиваться и потом объединяться в одно целое с минимальными усилиями. Этот тип приложений известен как составные приложения.

(Заранее извините за мой русский)

MEF это новый подход разработанный Майкрософт, который позволяет загружать расширения для вашего приложения очень легко. Он позволяет обнаруживать и составлять части, которые должны быть включены в приложение, и все это во время выполнения. Вы можете расширить поведение аппликации простим добавлением новых плагинов. Managed Extensibility Framework сделает все это за вас.
«Hello MEF World!»


После успешного релиза PHP-фреймворка Phalcon 1.0, команда разработчиков продолжает работать над его развитием. В этой статья я хочу осветить наиболее интересные фичи, представленные в версии 1.1.0 BETA

• Пагинация результатов конструктора запросов (QueryBuilder)
• Сервер очередей Beanstalkd
• Шифрование
• Assets Management
• Режим Exception для ORM-валидаторов
• Роутинг по имени хоста
• Использование контроллеров в приложениях Mvc\Micro
• Послесловие
• Помогите сообществу, проголосовав за поддержку Phalcon в cPanel

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

Это топик-перевод статьи Eller's Algorithm. В ней рассказывается о способе программной генерации лабиринтов. Дальнейшее повествование идет от лица автора.

 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  
|__   |__       __ __|__   |   __|  |  |  |  |
|__   |__   |__|   __ __|   __ __      |     |
|        |  |  |     |  |__      |__|  |  |  |
|__|__|  |  |   __|   __|__   |   __|__|  |__|
|   __|  |     |__ __ __|  |  |__|  |     |  |
|  |  |  |  |__|  |__   |  |   __|__ __|  |  |
|  |__    __    __ __    __|  |   __   |  |  |
|  |  |  |  |      __|  |   __|  |  |__|  |  |
|  |     |     |__   |  |  |  |  |  |__    __|
|  |  |__|__|__ __|  |     |  |  |      __|  |
|__ __|  |  |  |__   |__|   __|     |   __ __|
|   __|  |   __|__      |__   |__|  |__    __|
|  |  |     |  |     |__|  |   __    __|   __|
|   __|  |__ __|__|      __|  |  |     |  |  |
|   __ __   |      __|__|  |__   |  |  |__|  |
|__ __ __|__ __|__ __ __ __ __|__|__|__ __ __|

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