JavaScript *

Увидел на тематическом сайте, посвящённом сериалу My Little Pony код на Turbo Pascal, использующий старинный модуль Graph и рисующий нескольких персонажей.

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

Финальная версия

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

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

Чистый JavaScript.

Пишите всё приложение полностью на чистом JavaScript. Все API, доступны на клиенте и на сервере — в том числе API базы данных! — Так что один код может легко работать на клиенте и на сервере.

Живые обновления страниц.

Просто напишите ваши шаблоны. Они автоматически обновляются при изменении данных. Meteor поддерживает любой язык шаблонов.

Чистая, мощная синхронизация данных.

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

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

Поскольку времени для реализации было достаточно, и долгое время таится желание написать хоть что-то, что может помочь другим разработчикам. Оформил все это дело в совсем малюсенький и простой plugin для jquery. Надеюсь, теперь этот код могут прочесть не только я и мой кот Борис, если же это и вовсе кому-то поможет в работе то я совсем не против использования его в ваших проектах, изменения копирования редактирования и т.д.

Методы создания классов на JavaScript уже не раз обсуждались по всему рунету и на хабре в том числе, я решил найти немного иной подход к созданию классов, приближенный к реальным классам. Одно важное отличие от других реализаций описанных во многих статьях, это возможность создавать аксессоры (setter's/getter's). Которые будут работать не только в современных браузерах, но и в долгоживущем IE ниже 9-ой версии. Об этом читайте ниже.

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

Хочу поделиться с хабросообществом javascript-библиотекой fc.tape. Её назначение — управление анимацией спрайта, представляющего собой склеенные кадры.
Демо

Доброго времени суток!



В полку Open Source прибыло! Мы (@kulakowka, k12th, dhomich и я) рады представить вашему вниманию перевод официальной документации по Backbone.JS — каркасу для создания RIA приложений на JavaScript, автором которого является Jeremy Askenas — создатель CoffeeScript.

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

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

И было бы это неудивительно, если бы разработчики были совсем глупые. Но нет же, разработчики наизусть знали «Understanding and Solving Internet Explorer Leak Patterns». Циклические ссылки разрывали, замыкания не использовали, к событиям относились с должным почтением и удалять обработчики не забывали. Да вот только от утечек это не спасло.

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

При использовании асинхронных функций в классах часто возникает проблема, когда в теле функции невозможно обратиться к объекту класса, вызывающему функцию. Это хорошо видно на примере с аяксом (с использованием jQuery):

function Loader()
{
    this.load = function()
    {
        $.ajax({
            url: '/test.php',
            success: function(data, textStatus, jqXHR) {
                // здесь уже никак нельзя обратиться к объекту класса
                console.log(this); // this содержит внутренний объект jQuery,
                                   // вызывающий функцию success
            }
        });
    }
}
(new Loader()).load();

Зачем?

Вопрос “Зачем?” — самый главный при принятии любого решения. В нашем случае причин было несколько.

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

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

Но в Mail.Ru Group есть целая команда высококвалифицированных людей, знающих JS, способных самостоятельно написать инструмент, а самое главное — они же им и будут пользоваться.

Во-вторых, задачи. Возьмем проект Почта@Mail.ru. Мы не можем отказаться от шаблонизации на сервере – нам нужна быстрая загрузка при первом входе. Мы не можем отказаться от шаблонизации на клиенте – люди должны видеть высокую скорость реакции на их действия, а значит, обязателен AJAX и шаблонизация на клиенте.

Проблема очевидна: два набора совершенно разных шаблонов на сервере и на клиенте. А самое обидное, что решают они одну и ту же задачу. Дублирование логики нас просто измотало.

v8 — это интерпретатор JavaScript, а значит, мы можем получить один шаблон, который работает как на сервере, так и на клиенте.

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

Это небольшая история страданий, боли, взлетов и падений в попытках ускорить работу RaphaelJS на больших и сложных SVG. Если вы страдаете от подобных проблем, то не стоит ждать в конце этой статьи серебряной пули, но, надеюсь, что про наш путь поиска решения будет интересно прочитать всем.

Увидел баннер предстоящей конференции o JS на тостере. Глаз привычно зацепился и зуд в одном месте дал знать — что-то не так, что-то мимолётное и неявное :)

Собссно — сабж:


Пруф: http://www.w3.org/wiki/Objects_in_JavaScript: One thing to watch out for, though: it's a very common mistake to put a comma after the last item in the object literal’s list of properties (...). Only put commas between properties — an extra comma at the end will cause errors.

Envision.js библиотека для создания быстрых динамических и интерактивных визуализаций данных на HTML5.


Возможности:

1) Визуализация в реальном времени.
2) Временная шкала
3) Визуализация валют ( как на яндексе прям )
4) Поддержка Ajax в интерактиве.
5) Можно побаловаться фракталами.

Документация — одна из самых важных составляющих любого проекта, особенно если этот проект с открытым кодом, который будут читать другие люди. Чтобы сделать мир opensource чуточку лучше, я попытался собрать свои знания в области организации модулей nodejs проектов и сделать такой инструмент как Makedoc!. Ремарка для адептов ruby: это почти то же, что и rdoc.info для руби.

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

В кратце шаблон использования такой: идем на jsdoc.info/[githubusername]/[projectname] и видим готовую документацию по проекту. Либо идем на jsdoc.info/[githubusername] и получаем список проектов для которых можно сгенерировать документацию.

За деталями реализации прошу под кат.

PhantomJS — это сборка движка WebKit без графического интерфейса, позволяющая в режиме консоли загружать веб-страницу, выполнять JavaScript, полноценно работать с DOM, Canvas и SVG. Одним из главных заявленных применений PhantomJS является автоматизированное функциональное тестирование пользовательского интерфейса. PhantomJS имеет интеграцию с различными фреймворками для тестирования JavaScript и веб-страниц. Посмотрим, что можно сделать на базе стандартного функционала PhantomJS, чтобы протестировать отдельный компонент и целое приложение, написанное на ExtJS/Sencha. В этой статье я приведу некоторую простейшую заготовку для тестировочного фреймворка, иллюстрирующую подход к тестированию кода, основанного на сторонней JavaScript-библиотеке. Весь код, представленный в статье, доступен на GitHub.

Что будем писать

В прошлой статье мы писали простенький эмулятор терминала на PHP. Я думаю, теперь время написать что-нибудь более серьезное, на вебсокетах. Какой язык использовать для работы с вебсокетами..? Питон..? Руби..? JavaScript..? Нет! Раз уж зарелизился Go 1, давайте на нём и напишем ;). Я постараюсь не повторяться и не писать сюда целиком код. Я приведу лишь интересные, на моей взгляд, фрагменты.

Демо

Спасибо пользователю Aleks_ja за возможность посмотреть эмулятор терминала в действии (нужен браузер с последней версией вебсокетов — например это Firefox 11 или последний Chrome). С первого раза оно может не подключиться, если демон не успеет стартовать за 100 мс — попробуйте сначала обновить страницу.



Исходный код веб-терминала доступен на гитхабе. Компилировать вебсокет-демон необходимо самостоятельно (командой go build) — это небольшая мера защиты от тех, кто любит «повзламывать» хостеров ;).

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

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

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

В этот раз мне пришла такая идея: заменить эту картинку кодом. Здесь видится несколько вариантов. Первый — это dom-анимация. Второй — это canvas-анимация.

25 марта на Гитхабе в репозиториях компании LearnBoost, широко известной в сообществе Node.js благодаря проектам Socket.io, mongoose, cluster, появился небольшой модуль console-trace. Это маленькое, но полезное дополнение функции console.log(), которое раньше было доступно только в консолях браузеров — вывод имени файла и номера строки, из которой вызвана console.log().

Привет!

Откровенно говоря, я не знаю, один ли я в своей беде, но за долгое время использования Google Reader в качестве RSS-читалки, мне изрядно надоела непропорциональная ширина кнопки «Подписаться» и всплывающего по её нажатии блока. Казалось бы, всё это фигня, но глаз мозолит очень сильно.

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

Короче говоря, вот она, проблема: