О чем эта статья. Я хочу поделиться опытом разработки мобильного приложения на phonegap. В итоге получился целый програмный комплекс с RESTfull сервером, клиентами, да еще хостится на PaaS. Поэтому я опишу отдельно архитектуру клиентского приложения (html5 single page app, завернутое в phonegap), серверного (nodejs с swagger-node-express + node-orm2), и как разместить все это на openshift PaaS.

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

Browserhacks

Название говорит самое за себя. Данный ресурс — хранилище всевозможных хаков к существующим браузерам. Увидев этот сайт, сам Paul Irish мудро произнес: "Holy shit amazing".

5 замечательных изобретений от David DeSandro (Twitter, H5BP)

Masonry — в переводе «каменная кладка» — идеальное решение для создания Grid Layout. Качественная «замена» для неутвержденной Flexbox спецификации. Простой синтаксис дает возможность без труда создавать Pinterest/Surfingbird подобные макеты. Существует на нативном JavaSciprt и как jQuery плагин.

Isotope — «изысканный jQuery плагин для магических лэйаутов. Позволяет с легкостью фильтровать, сортировать и придавать динамичность макету».

imagesLoaded.js — определяет когда изображения были загружены. Включает в себя 4 события: always, done, fail, progress. Простой в использовании.

Draggabilly — аналог jQuery UI Draggable на нативном JavaScript в лучших традициях автора кода. Работает с touch интерфейсом.
Close Pixelate — «пикселизация» изображений в Canvas аля потаённые места в некоторых работах жанра НЮ.

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

Практически каждый день я пользуюсь почтой Gmail, но вот недавно заметил, что если сделать скриншот экрана (www.take-a-screenshot.org), то простым нажатием Ctrl + V этот скриншот можно скопировать прямо в текст письма Gmail. Это работает везде, но естественно кроме IE. Заинтересовавшись вопросом как это происходит нагуглил следующий пост на Stackoverflow. Под сильным впечатлением от возможностей HTML5 clipboardData решил сделать простенький портал, где без всяких Desktop приложений любой юзер может загрузить скриншот просто скопировав его.

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

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

Привет Хабр! Примерно год назад я представил вашему вниманию первую версию open-source библиотеки FileAPI, предназначенную для работы с файлами на клиенте и последующей загрузки на сервер.

За это время был пройден долгий путь. Библиотека заработала 670+ звезд и 90+ форков. С помощью github-сообщества удалось исправить множество «детских» проблем и внести ряд улучшений. Было закрыто более 100 тасков, и благодаря Илье Лебедеву сделана загрузка файлов по частям. Сегодня я с гордостью хочу представить вам FileAPI 2.0.

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

Ан нет. Не зря Steve упоминает в самом начала своей заметки о событии onload / onreadystatechange для скриптов. Используя их, мы можем однозначно привязать некоторый код к окончанию загрузки конкретного модуля. Дело за малым: нам нужно определить этот самый код каким-либо образом.

Решение первое: дерево загрузки

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

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

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

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

Основы

Мы начнём с несложного обзора модульного подхода, хорошо известного с тех пор, как Эрик Миралья (Eric Miraglia) из YUI впервые об этом написал. Если вам уже знаком модульный подход, переходите сразу к «Продвинутым техникам».

Анонимные замыкания

Хочу представить вам функцию-конструктор классов createClass.
Чем хорош этот конструктор:
1. Сам код выглядит более читабельным и понятным
2. Поддержка множественного наследования
3. Поддержка абстрактных методов
4. Наследование статических методов и свойств класса
5. Умный метод instanceOf (проверяет по всей цепочке классов)

3. Прототипное наследование

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

Далее в игру вступает наследование. Оно лучше разделяет понятия, когда объекты наделяются своими методами на основе методов других объектов.

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

Речь пойдёт о далёком 2005 году, когда только-только вышла Civilization4 от Sid Meier. К тому времени я плотно висел в Civilization3, прошёл её раз дцать на самых разных картах, и тут вышла долгожданная четвёрка. Это были годы P3-512Mb для mid-end и P4-1Gb в hi-end. Только топовые конфиги в те годы имели два гига памяти на борту.

Civilization 4 вышла с графикой уровня года 2002-2003го, что в принципе нормально для мэинстрима тех времён, особенно учитывая что это пошаговая стратегия, а не шутер. Но жрала с течением игры до 900Mb оперативки, что приводило к жуткому свопу, особенно на больших картах, особенно к концу игры, особенно на ноутбуках. Народ недоумевал, я тоже. Учитывая, что в те же годы вышел Far Cry с куда более красивой графикой, и который вполне игрался на максимуме даже с 512Mb на борту, такое поведение Civilization 4 выглядело крайне странным. Захотелось разобраться и покарать…

Предисловие от переводчика.  В постскриптуме к моей вчерашней блогозаписи я указал, что AppJS — это не единственное такое средство, которое позволяет создавать приложения с GUI (графическим интерфейсом пользователя) при помощи вебоподобных методов разработки на языках HTML, CSS и JavaScript с использованием движка Node.js. Естественной иллюстрацией к этому постскриптуму является нижеследующий перевод гитхабовской страницы проекта node-webkit. И сразу скажу: я предвижу заранее, что непредвзятый взгляд ваш сочтёт node-webkit ещё более удобным и развитым средством, чем AppJS.

---

Введение

node-webkit — среда для запуска приложений, основанная на Chromium и Node.js. При помощи node-webkit можно создавать традиционные графические приложения посредством HTML и JavaScript. Также node-webkit позволяет вызывать модули Node.js прямо из DOM и тем обеспечивает новый способ создания таких приложений и употребления веботехнологий в них.

node-webkit создан и разрабатывается в Интеловском Центре технологий с открытым исходным кодом (Intel Open Source Technology Center).

Введение в node-webkit (слайды).

Достоинства

• Приложения создаются при помощи современных HTML5, CSS3, JS и WebGL.
   
• Полная поддержка API Node.js и созданных другими разработчиками модулей.
   
• Вызов API Node.js без потерь в производительности.
   
• Лёгкость упаковки и распространения приложений.

Прямо сегодня (19 августа) интеловский Центр технологий с открытым исходным кодом выдал на-горá очередную версию движка node-webkit. Движок этот, как и прежде, интересен тем, что умеет открывать браузероподобные окна (на основе кода Chromium) и употреблять в них API Node.js — так что он обеспечивает нетрудное создание GUI-приложений методами веборазработки (на языках JavaScript, HTML, CSS, WebGL и т. д.) под операционные системы Windows, Mac OS X и Linux.

Новая версия получила номер 0.7.1 и содержит движок Node версии 0.10.12, как нетрудно видеть в тестовом окне:



Код тестового окна я сегодня открыл на Гитхабе, так что желающие могут с ним ознакомиться и убедиться воочию, что начальные (helloworldные) шаги программирования для node-webkit ничуть не сложнее обычной веборазработки, усиленной возможностями API Node.

Менее месяца тому назад (24 июля) я обозрел одну из предыдущих версий node-webkit (версию 0.6.3). С тех пор прошло не много времени, однако в node-webkit появился ряд небезынтересных новшеств:

Статья устарела. В новой документации содержится самая актуальная информация из этого поста. См. bindNode и on.

Приветствую всех читателей и писателей хабра.

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

• Введение
• Наследование
• MK.Object
• MK.Array
• Matreshka.js v0.1
• Matreshka.js v0.2
• Реализация TodoMVC

Код для привлечения внимания:

mk.on( 'change:x', function() {
	alert( 'x is changed to ' + this.x );
});
mk.x = 2; // alerts "x is changed to 2"

И это работает в… IE8.

Что такое Матрешка?

Матрешка, как фреймворк
Компактный размер и легкая в изучении архитектура даёт возможность строить крупные расширяемые приложения. Этим сегодня никого не удивишь, но я постараюсь.
Матрешка, как библиотека
Если фичи, предоставляемые Матрешкой вам понравятся, то не обязательно менять свой код. Матрешкой можно пользоваться, как набором классов с интересными методами.
Матрешка, как платформа для создания собственного фреймворка
Матрешка — расширяемый фреймворк общего назначения, который не позиционируется, как MVC, MVVM или %your_design_pattern% фреймворк, поэтому программист имеет возможность реализовать собственную архитектуру, которая будет уметь желаемый набор шаблонов проектирования.

Зачем?

Мне часом надоело думать о представлении и о том, чтоб его менять написанным мной кодом. Все костыли синхронизации данных и представления в Javascript вызывают у меня негативные чувства, и амбициозной, направленной в будущее, целью Матрешки является возможность полностью забыть о том, что у нас есть UI, оперируя только данными. Конечно же, решить эту задачу невозможно на 100%, но мы, программисты, должны выжимать максимум из данных нам инструментам, дабы сделать код чище, короче и гибче. Пора встряхнуть свой код и стать злым.

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

UPD: игра вышла.

Привет!

Тут такая история. Я заметил, что в какой-то момент стал отмечать для себя важные вещи для развития ребёнка. Например, у меня в детстве был сначала модульный конструктор с мотором, колёсами, батарейками и так далее, а потом – модульный же радиоконструктор. Эти два предмета очень сильно повлияли на то, чем я потом интересовался в будущем.

Ещё пример – в детстве надо обязательно сходить в политехнический и археологический музеи Москвы. Или, например, запомнились такие штуки: первая хорошая НФ, подаренная в 8 лет; дед, научивший меня чертёжному почерку за 15 минут; шахматы каждые выходные; огромная коробка Лего и так далее. И таких событий – тысячи.

У меня просьба. Давайте накидаем важные и интересные вещи, которые можно и нужно сделать с ребёнком до примерно 10 лет. Наверняка ведь у вас есть такие «чекпоинты», которые запомнились.

Есть javascript код:

1. var A = function () {};
2. A.prototype.b = 100;
3. var a = new A();
4. A.prototype.c = 101;
5. a.c = -100;
6. A.prototype = {};
7. A.prototype.b = 536;
8. /* 1 */ console.log(a.__proto__.constructor.prototype.b === 536);
9. var b = new A();
10. /* 2 */ console.log(a.__proto__.__proto__.constructor === a.__proto__.constructor.prototype.constructor);
11. /* 3 */ console.log(b instanceof A);
12. /* 4 */ console.log(!(a instanceof Object));

Вопрос. Что возвратят выражения 1-4 и почему?

Затрудняетесь ответить?
Тогда вам стоит пройти под кат ;-) (Далее 600 Кб больших изображений)

Нельзя не упомянуть опубликованные ранее статьи по этой теме — введение в Cocoapods и краткое резюме по созданию своего «pod»'а.
Последняя указанная статья дала толчок в нужном направлении, но не хватало знаний для полного понимания поданной информации. Цель данной статьи — максимально подробно описать процесс создания и использования своего собственного CocoaPod'а, далее для краткости — «pod». Ну и упорядочить свои познания в данной области.

Все мы знаем множество преимуществ использования AJAX: пользователям не нужно ждать загрузку новой страницы, действия выполняются в фоновом режиме, в результате чего можно обеспечить гораздо более динамичный user experience. Идеи вроде бы просты, но создать сложное AJAX веб приложение достаточно тяжело. Я создал свой блог на основе AJAX, у меня есть несколько советов и я хочу поделиться с вами своим опытом. Надеюсь я помогу вам избавиться от некоторых проблем в будущем!