Я знаю про Backbone.js и про Knockout.js
Просто иногда хочется чего-то простого.
В этой публикации я поставил перед собой несколько целей:
Дальше много кода…
Читать полностью »
Добрый день дамы и господа,
На хабре есть не так много статей на тему GWT (Google Web Toolkit) и в большинстве своем написаны они в ключе «какая это бяка, ничего не умеет, ничего не понятно». Кроме того, как показывает мой опыт, большинство программистов о GWT вообще ничего не слышали, а те кто слышал, думают, что больше чем на „Hello World“он не способен. Я постараюсь показать вам, что с помощью этого замечательного Фреймворка можно делать такие вещи, которые большинству JavaScript программистам просто не по зубам.
Перед началом небольшое отступление, т.к. вопрос «а зачем?» обязательно прозвучит. Этот сайт я написал на GWT, т.к. у меня и выбора то не было. С HTML,CSS, PHP и JavaScriptом я знаком(был) весьма поверхностно( как собственно и большинство Java-программистов), а вот идея и желание были. А потому использовал я что имел и получилось вроде весьма не плохо.
Посмотрите на этот сайт. Да это не шедевр, но он показывает, что GWT может все, что может JavaScript и даже больше. Почему больше? Ответ на этот вопрос полностью совпадает с ответом на вопрос: «почему С++ может больше чем Assembler?». На эту тему я предлагаю подискутировать в комментариях. А мы возвращаемся к GWT. Нет ничего лучше( мое стойкое убеждение), чем объяснять что либо на примере, а посему я предлагаю вам препарировать этот сайт.
Я закончил разработку бета-версии своего оптимизатора загрузки JavaScript — jWidget SDK.
github.com/enepomnyaschih/jwsdk/wiki
jWidget SDK — это небольшой скрипт, сборщик (прекомпилятор) вашего JavaScript. Это обертка вокруг YUICompressor, которая автоматизирует сборку проекта и дает очень гибкую конфигурацию. Инструмент совместим с любой архитектурой сервера, со всеми JavaScript-фреймворками. Инструмент бесплатный, с открытым исходным кодом и имеет лицензию LGPL.
Инструмент успешно протестирован на нескольких коммерческих проектах с разной серверной архитектурой. В том числе (не имею права дать ссылки):
— Чистый веб-сервис на Java + AJAX + JS. Особенность приложения: весь-весь-весь контент рендерится динамически через JavaScript, и приложение грузится почти мгновенно благодаря браузерному кэшированию
— Один шахматный клиент на jQuery, встроенный в сайт на Zend Framework
— Клиент одного приложения на Adobe Air
Привет всем. Сегодня я поведаю о своей разработке для Google Chrome и Pivotal Tracker — PIRO. Начнем по порядку.
PivotalTracker — сервис для управления софтверными проектами по «гибким» методологиям. Более подробно можно узнать из этой статьи на Хабре. Сам по себе трекер отличный, но при работе с ним у меня возникали определенные проблемы:
Немного поразмыслил, я закатал рукава и начал писать свое решение для PivotalTracker. В ходе работы я показывал его людям, они подключались и помогали мне в его реализации. Поэтому в конце проекта его решили сделать Open Source :)
Может, для гуру javascript данная статья будет не интересна, а вот для начинающих разработчиков, наверняка — полезна.
Сразу оговорюсь, что в статье будет использоваться только чистый javascript без подключения сторонних фреймворков (например jquery).
Писать javascript в декларативном стиле гораздо удобнее:
Итак, приступим.
Tinyicon это небольшая библиотека для манипуляции с favicon сайта для передачи информации о новых событиях. Для браузеров не поддерживающих canvas счетчик отображается в title страницы.
При реализации модели для манипуляции с данными в MongoDB, я пришел к выводу, что нужно как то избежать проблем с вложенностью асинхронных вызовов. Я не знал о существовании Step для Node.js и решил создать свой велосипед. Чем и хотел бы с Вами поделиться, уважаемые Хабро пользователи.
Для того чтобы решить проблему вызовов и дальнейшей передачи информации, следующему в очереди вызову, родился модуль AQueue (реализация последовательной очереди асинхронных вызовов). В реализации данного модуля, лежит принцип, применяемый в реализации промежуточного слоя роутинга в Express.js (к примеру для проверкиЧитать полностью »
Речь пойдёт о проблеме кроссбраузерного представления многострочных данных в javascript. Это могло не быть проблемой, если бы Firefox умел работать с функциями так же, как другие браузеры. Единый кроссбраузерный способ представления так и не найден, несмотря на 2-дневные усилия. Если бы он был, его, наверное, уже стали применять на сайте userscripts.org. Пока что имеется раздельный способ представления: один — для юзерскриптов Firefox, другой — для всех остальных. Также, для Scriptish существует возможность чтения формата метаданных (директив), что не охватывает произвольного формата, но решает задачу, чаще всего встречающуюся в юзерскриптах. Не рассматриваем решение сЧитать полностью »
Очень часто мне встречаются сайты которые отвратительно выглядят на iPhone4, и дело даже не в том, что большинство из них не адаптированы под маленький экран, а в том, что разработчики не учитывают новый тип экранов. На иконки не хочется смотреть, на кнопки не хочется нажимать, а от картинок вообще хочется… закрыть сайт. То, что призвано завлечь пользователя на сайт, вникнуть в его суть, а не покинуть его тут же — теперь работает совершенно наоборот. Но пользователи iPhone в целом привыкли к такой ситуации, т.к. телефон не может заменить полноценного браузинга.
Однако, совсем недавно AppleЧитать полностью »