Showing posts with label javascript. Show all posts
Showing posts with label javascript. Show all posts

Tuesday, July 15, 2014

OdessaJS 2014


5-6 липня я був запрошений на OdessaJS для того, щоб зробити доклад про побудову enterprise-level application використовуючи AngularJS. Сам доклад можно подивитися тут: http://slides.olostan.name/twinfield_neoui/twinfield_neoui.html#1

Сама конференція вразила мене своєю “молодіжностю” - було дуже багато молоді. Як серед відвідувачів, так і спікерів. Організатори - Артем Тритяк та Юлія Черняк зробили все, щоб з скучної по своїй суті девелоперскої коференції зробити драйвову веселу тусовку. Дуже багато спілкування було саме поза-доповідями. Люди кодили просто у коридорах.

Як відомо, будь яка конференція - це 50% доповіді, та 50% - це спілкування на афтерпаті. І тут організаторам вдалось зробити все на вищому рівні: афтерпаті після першого дня продовжувалась майже до початку наступного - до 7 ранку на березі моря.

Але і технічна частина була просто чудова: було все - від широкого кола фронт-енд фреймворків, до сурового node.js бекенда. Важко було вибрати на яку саме доповідь піти.

І завершили все “круглим столом” з доповідачами, на якому була можливіть поділитися life-hack’ами з тими, хто тільки починає свою кар’єру девелопера.

Я впевнен, що івент вдався! І наступний OdessaJS буде абсолютним must-visit івентом!

Sunday, November 24, 2013

Child process balancer for Node.JS: Building block of Message Driven Architecture

This article is devoted to "child-balancer" - project that I've published recently to GitHub.

The Idea

Idea of this project raised when I'd a small task that required a serious CPU-heavy calculations. Server, on which this script should run had 16 Xeon CPUs, so there were some space to use.

Friday, August 29, 2008

GWT 1.5 Released

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

 

Итак, позволю себе сделать вольный перевод списка того, что изменилось с небольшими комментариями (оригинал):

Поддержка Java 1.5 и расширенная эмуляция JRE

  1. Теперь можно спокойно использовать “генерики”. И не только для более комфортной работы на клиентской стороне, но и для реализации более “тесного” RPC между клиентом и сервером (теперь можно возвращать клиенту List<MyClass> не беспокоясь о @gwt.typeArgs)
  2. Синтаксический сахарок: for-each loops, autoboxing, static import, enum
  3. Переработана архитектура подсистем (RPC, image bundles, benchmarking, интернационализация). Так же стало допустимо использование “левых” аннотаций, что позволяет повторное использование кода для других систем.
  4. Добавлена реализация разных вспомогательных классов, к которым так привыкли ява-девелоперы (StringBuilder, TreeMap, LinkedHashMap)
  5. Теперь Assertion-ы можно отключить (фактически появилась возможность делать более “релиз” версию).

 

Производительность и связь с JavaScript

  1. Компилятор более тщательно проводит “инлайнинг” функций – т.е. вместо вызова функции, код функции вставляется прямо в то место, откуда был бы вызов.
  2. Дерево переработано полностью. В результате на ИЕ прирост скорости работы от 5 до 10 раз.
  3. Добавлены типы JavaScript overlay. Это позволяет интегрировать уже написанные JavaScript библиотеки без дополнительных издержек. А так же более “прямую” конвертацию JSON данные в GWT объекты.
  4. Система “линкеров” позволяет генерировать различные варианты окончательных сборок для разных контейнеров, которые могут выполнять JavaScript (привет Google Gadgets, Filefox расширения, Greasemonkey скрипты, Gears но и … Flex и Android)

Красивые виджеты, лучшая поддержка DOM, доступность, и bi-di.

  1. Переделали демку
  2. Добавили дефолтные “темы” (раньше были только в примерах)
  3. Добавили функционал для обеспечения “доступности” (WAI-ARIA) и вывод “наоборот” (для арабских локалей например)
  4. Новый DOM package покрывает полностью спецификацию W3C – т.е. можно использовать “нативные” элементы вместо виджетов для простоты реализации.

 

…и многое другое :)

 

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

Monday, December 10, 2007

Microsoft Volta - Microsoft's answer to GWT?

Сегодня наткнулся на довольно таки интересный проект от Microsoft - Volta. В описании много слов, но основное "The compiler creates cross-browser JavaScript for the client tier, web services for the server tier, and communication, serialization, synchronization, security, and other boilerplate code to tie the tiers together". Ничего не напоминает? Ах да, это же концепция старого доброго GWT.

После более детального ознакомления с документацией я всё больше и больше находил схожие концепции GWT и Volta.

Итак, Microsoft таки решилась дать ответ Google. Я пока не сильно вникал в подробности реализации и кодинга, но не смотря на схожесть концепции, различия таки есть. И довольно существенные - Volta имеет более сильную привязку к серверной составляющей, в то время, как код, генерируемый GWT может быть запущен с любым бэк-ендом (Java/PHP/ASP.NET/...) или вообще без сервера.

Что-ж. Ответ есть. Значит будем смотреть-пробовать. Время, как всегда, рассудит.



UPDATE: Посмтрел на самое типа простое демо-приложение Quickstart (ВНИМАНИЕ: Читайте UPDATE2 до открытия ссылки). С помощью HTTP Explorer'а отследил то, какие запросы идут на сервер и какие ответы и ужаснулся. Нет, это совсем не смешно. Вот что получислоь: трейс запроса. Если для загрузки такого маленького приложения пришлось сделать 133 запроса и получить около 2.2мб данных, то такой фреймворк требует ещё очень большой доработки. Бета-версия моего посиковика на GWT (lab.look.org.ua) занимает около 140кб в сумме (с картинками и стилями) и к серверу отсылается аж 6 запросов (или 16 с картинками и стилями). И это на GWT 1.3 (в GWT 1.4, как говорят, уменьшился генерируемый код на 15-20%). Итак, если Volta не будет оптимизирована, то чтоб использовать её надо будет очень хорошие сервера, хорошие каналы и хорошие клиентские машины. В то время, как GWT проводит довольно активную работу над оптимизацией размера кода, уменьшению количества запросов и т.д. Посмотрим, сможет ли Microsoft догнать GWT по этим параметрам, или будет как всегда выигрывать рекламой и маркетингом, а не эффективностью и производительностью?

UPDATE2: Многие знакомые жалуются, что у примеры прилоежний Volta вешают и крашат броузера (FF2, IE6, IE7). У меня FireFox хоть и на пару минут задумался, но потом отвис, хотя IE крашанулся полностью (проц АМД Х2 4600, 2гиг памяти). Так что предупреждение всем: если много открытых закладок и боитесь потерять, лучше или не открывайте их или открывайте в другом инстансе броузера или другим броузером.

UPDATE3: Вот ещё некоторые ссылки по теме:

Tuesday, June 26, 2007

GWT: Changing locale using cookies

Продолжая работу над своим проектом портирования функционала поисковой системы Look'а на GWT (lab.look.org.ua), я дошел до и18нации. В GWT, как известно, есть довольно хорошо продуманные средства для хорошей локализации. Но мне захотелось, чтоб текущий выбор языка хранился в куках, а не в переменной. В общем, решение получилось довольно простое.

1. Выбор языка и сохранение в cookie.

Этим занимается вот такой виджет:

package client.widgets;

import com.google.gwt.user.client.ui.*;
import com.google.gwt.user.client.Window;
import com.google.gwt.user.client.Cookies;

import java.util.Date;

/**
* Created by Olostan
* Date: 24.06.2007 23:37:00
*/
public class LangSelection extends Composite {
private static native void RefreshWindow() /*-{
$wnd.location.reload();
}-*/;
private class LangImage extends Image implements ClickListener {
final String code;
public LangImage(String code) {
super();
this.code = code;
this.setUrl("images/flags/"+code+".gif");
this.addClickListener(this);
this.setStyleName("lang-image");
}

public void onClick(Widget sender) {
Date date = new Date();
if (!code.equals("en")) {
Cookies.setCookie("locale",code, new Date(date.getTime()+60*60*60*60));
} else {
Cookies.setCookie("locale","",new Date(date.getTime()-1000));
}
RefreshWindow();
}
}
String[] lang = new String[] { "en","uk","ru" };
public LangSelection() {
HorizontalPanel panel = new HorizontalPanel();
for(int c=0;c<lang.length;c++) {
LangImage img = new LangImage(lang[c]);
panel.add(img);
}
initWidget(panel);
setStyleName("lang-widget");
}
}

 


Тут самый важный код  - это тело метода onClick. Он именно записывает выбранный язык в Cookies и делает рефреш странички.


2. Установка языка при загрузке модуля


Тут пришлось применить вот такой интересный трюк: в исходном html файле в блоке head добавляется вот такой код:

<head>
<title>MyModule title</title>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<script type="text/javascript">
function getCookie(name) {
var dc = document.cookie;
var prefix = name + "=";
var begin = dc.indexOf("; " + prefix);
if (begin == -1) {
begin = dc.indexOf(prefix);
if (begin != 0) return null;
} else {
begin += 2;
}
var end = document.cookie.indexOf(";", begin);
if (end == -1) {
end = dc.length;
}
return unescape(dc.substring(begin + prefix.length, end));
}
var locale=getCookie("locale");
if (locale!="") {
document.writeln("<meta name=\"gwt:property\" content=\"locale="+locale+"\"> ");
}
</script>
<meta name='gwt:module' content='MyModule'>
<link rel=stylesheet href="MyModule.css">
</head>

 


(тут попрошу прощение за потерянный origin кода на яваскрипте чтения значения cookie).


Таким образом при загрузке модуля будет установленна нужный язык.


Пример того, как оно работает можно посмотреть вот тут: lab.look.org.ua

Tuesday, June 19, 2007

Storing revision information using Windows Script Hosting

Вот возникла задача в ASP.NET приложении отображать номер ревизии, дату когда происходил билд. Не знаю, возможно есть и более простые решения, но так, как я их не нашёл, решил написать простенький JScript код, который будет выполняться WScript'ом как prebuild-евент проекте.

Вот какой скриптик получился:

var ws = new ActiveXObject("Wscript.Shell");
var path = "";
if (WScript.Arguments.length == 1) {
path = WScript.Arguments(0);
}
var fso = new ActiveXObject("Scripting.FileSystemObject");
var oSvn = ws.Exec("svn info");
while (oSvn.Status == 0)
{
WScript.Sleep(100);
}
var vers = oSvn.StdOut.ReadAll();
var regex = new RegExp("Revision: (\\d+)","m");
var revArr = regex.exec(vers);
if (revArr==null) {
WScript.Echo("No revision found!");
} else {
rev = revArr[1];
var templateFile = fso.OpenTextFile(path+"ProductVersion.cs.template", 1);
var template = templateFile.ReadAll();
var regex2 = new RegExp("\\$Revision\\$","gm");
template = template.replace(regex2,rev);
var regex_date = new RegExp("\\$Date\\$","gm");
var date = new Date();
template = template.replace(regex_date,date.toGMTString());
var result = fso.CreateTextFile(path+"ProductVersion.cs", true);
result.Write(template);
result.Close();
}

Он фактически на основе темплейта ProductVersion.cs.template создаёт файлик ProductVersion.cs, в котором заменяються $Revision$ текущей ревизией, а $Date$ датой.


Тут разве что стоит отметить два "но":



  1. Скрипт должен запускаться в том месте, где доступна информация о ревизии (+ рядом должен лежать файлик темплейта). По этому, следует перед вызовом скрипта (через wscript/cscript) в prebuild добавить cd $(ProjectDir)
  2. Так, как проект ASP.NET 2.0 не имеет prebuild/postbuild евентов (во всяком случае я не нашёл), нужно иметь другой проект, который будет экспортить инфу о ревизии.

Кстати, почему-то подумалось: решение чем-то похоже на решение с "генераторами", про которое я недавно писал.