<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Espeo Software &#187; Blog</title>
	<atom:link href="http://www.espeo.pl/kategoria/blog/feed" rel="self" type="application/rss+xml" />
	<link>http://www.espeo.pl</link>
	<description>Oprogramowanie na zamówienie - aplikacje inter/intranetowe, desktop, mobilne. Wykorzystujemy technologię Java, Java EE, Flex, Grails</description>
	<lastBuildDate>Fri, 11 May 2012 15:11:22 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>Wielowątkowość w JavaScript</title>
		<link>http://www.espeo.pl/2012/03/20/wielowatkowosc-w-javascript-2</link>
		<comments>http://www.espeo.pl/2012/03/20/wielowatkowosc-w-javascript-2#comments</comments>
		<pubDate>Tue, 20 Mar 2012 11:05:58 +0000</pubDate>
		<dc:creator>khasinski</dc:creator>
				<category><![CDATA[Blog]]></category>
		<category><![CDATA[technologia]]></category>

		<guid isPermaLink="false">http://www.espeo.pl/?p=4604</guid>
		<description><![CDATA[Interaktywne aplikacje internetowe wymagają coraz więcej od przeglądarek. Dane, które wcześniej przetwarzał back-end, są przetwarzane po stronie front-endu, żeby przyspieszyć warstwę prezentacji, stworzyć wersję off-line aplikacji oraz rozsądnie podzielic pracę pomiędzy serwer i klienty. Przetwarzanie po stronie przeglądarki powoduje jednak liczne problemy, z których spora część jest bezpośrednią konsekwencją używania tego samego wątku do wyświetlania elementów strony, przetwarzania zdarzeń i wykonywania obliczeń w JS. Rozwiązaniem mogą być Web Workers, mechanizm wielowątkowości w HTML5. Pozwalają one wydzielić część funkcjonalności do osobnego procesu, co przyspiesza aplikację zarówno od strony użytkownika (interfejs nie jest blokowany przez obliczenia), jak i od strony faktycznej prędkości obliczeń (wykorzystanie wielu procesorów i/lub rdzeni). Same Web Workers posiadają jednak szereg ograniczeń: Nie mają dostęp do DOM; Obiekty związane z lokacją są dostępne jedynie w trybie read-only; Mogą komunikować się jedynie przez zdarzenia; Nie mają wbudowanego fallbacku, więc zadaniem programisty jest sprawdzić ich dostępność w starych przeglądarkach. Prezentacja na temat HTML5 Web Workers]]></description>
		<wfw:commentRss>http://www.espeo.pl/2012/03/20/wielowatkowosc-w-javascript-2/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Firmowe szkolenie z Grails</title>
		<link>http://www.espeo.pl/2012/02/27/firmowe-szkolenie-z-grails</link>
		<comments>http://www.espeo.pl/2012/02/27/firmowe-szkolenie-z-grails#comments</comments>
		<pubDate>Mon, 27 Feb 2012 15:14:49 +0000</pubDate>
		<dc:creator>Krzysztof Konwisarz</dc:creator>
				<category><![CDATA[Blog]]></category>
		<category><![CDATA[news]]></category>
		<category><![CDATA[grails]]></category>
		<category><![CDATA[szkolenie]]></category>
		<category><![CDATA[wprowadzenie]]></category>

		<guid isPermaLink="false">http://www.espeo.pl/?p=4529</guid>
		<description><![CDATA[Ostatni wtorek dla części z kolegów z firmy nie był zwykłym wtorkiem. Zamiast, normalnym trybem, uczestniczyć w swoich projektach, wyrwano ich na całodniowe szkolenie z Grails, które miałem przyjemność przeprowadzić. Cel był prosty &#8211; przekazać możliwie dużo wiedzy i doświadczeń z pracy z frameworkiem w czasie ośmiu godzin. Plan: ograniczyć wykład do minimum i przejść do tworzenia kodu jak najszybciej. W końcu to nie studia &#8211; zbyt mała sala, żeby się spokojnie przespać bez wiedzy prowadzącego. Balansowanie pomiędzy tym, o czym powiedzieć na dzień dobry, co zasygnalizować w praniu, a co pozostawić do ewentualnego dopytania z pewnością można poprawić. Ostatecznie chyba i tak zbyt wiele w całości było mojego gadania :) Wystartowaliśmy z Grailsowymi ogólnikami i błyskawicznym wprowadzeniem do Groovy, przeszliśmy przez warstwy frameworka, nie zapominając o większych funkcjonalnościach i udogodnieniach. Trzeba było w końcu pokazać, że tutaj praca z XMLem i JSONem czy technologie takie jak Spring Web Flow są na wyciągnięcie ręki. Wszystko to odbywało się przy tworzeniu małej aplikacji. Napisaliśmy kilka akcji kontrolerów, metod serwisów, tagów, widoków i testów. Na koniec zdążyliśmy jeszcze sprząc ze sobą dwa pluginy, aby otrzymać Quartzowego joba wysyłającego maile (czyli na dobrą sprawę funkcjonalność, którą oferuje osobny plugin). Szkolenie i przygotowanie do niego były też okazją, aby w końcu przetestować nowe Grailsy, obecnie w wersji 2.0.1. Nie był to może pełny sprawdzian bojowy, a jedynie deweloperskie manewry &#8211; tym niemniej, kilka wrażeń jest. Nowe testy wydają się czystsze i nie sprawiały problemów w prostych przykładach. Spockowe drukowanie błędów i znacznie ładniejsze i czytelniejsze raporty także delikatnie plusują. Natomiast nowa konsola i przeładowywanie klas zawodzą w pokładanych w nich nadziejach. W praktyce nie obywa się bez częstych restartów tomcata, a &#8216;rozgrzewanie&#8217; JVM ostatecznie wiele nie daje, gdy i tak trzeba wyjść z konsoli, bo aplikacja działa niestabilnie. Moje wrażenia po szkoleniu były pozytywne, ale nie mnie oceniać ;) Guys?]]></description>
		<wfw:commentRss>http://www.espeo.pl/2012/02/27/firmowe-szkolenie-z-grails/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Authentication in AngularJS (or similar) based application.</title>
		<link>http://www.espeo.pl/2012/02/26/authentication-in-angularjs-application</link>
		<comments>http://www.espeo.pl/2012/02/26/authentication-in-angularjs-application#comments</comments>
		<pubDate>Sun, 26 Feb 2012 18:16:02 +0000</pubDate>
		<dc:creator>Witold Szczerba</dc:creator>
				<category><![CDATA[Blog]]></category>
		<category><![CDATA[english]]></category>
		<category><![CDATA[technologia]]></category>
		<category><![CDATA[AngularJS]]></category>
		<category><![CDATA[javascript]]></category>

		<guid isPermaLink="false">http://www.espeo.pl/?p=4475</guid>
		<description><![CDATA[Hello again, today I would like to write a little bit about how am I handling authentication in an application front-end running inside web browser, using AngularJS. Traditional server &#8216;login form&#8217;? Well&#8230; no, thank you. At the beginning, I did not realize that traditional and commonly used form based authentication does not suit my client-side application. The major problem lies in a key difference between traditional &#8211; server-side, and client-side applications. In server-side applications, no one else but server itself knows user state and intentions, whereas in client-side applications this is no longer true. Let&#8217;s take a look at a sample server-side web application flow of events: user asks for a web page: something.com, server generates markup and sends it back, user chooses to visit a secured sub-page: something.com/secured, server figures out that user does need to authenticate itself, so it: remembers what user asked for, responds with a login form (or a redirect to) instead of a requested content, once user sends credentials back to the server, it serves what user initially asked for, user keeps visiting secured pages and filling secured forms until their authorization expires (for whatever reason), server once again responses with a login form and once user provides credentials, server redirects them back whenever they wanted to go. Same application, but different flow: user asks for: something.com/secured/formXyz, server sends a login form, user logs in, fills a long and complicated form, but they are doing it so long that theirs session expires, user submits a form, but since the session is not valid anymore, login screen appears, once user logs in, server can process the submitted form, no need to re-enter everything again. Now let&#8217;s see how it is in client-side application, running inside a web browser: user types somewhere.com in an address bar, browser sends a &#8220;Content-Type: text/html&#8221; request, server sends back a page with client-side application code, code starts to execute and asks for user name (e.g. it wants to display user name in the upper right corner), so next request is issued, e.g.: &#8220;Content-Type: application/json&#8221; traditional login form does not make sense here, as browser is not requesting a web page, but some data instead. Something is not right here. OK, so let&#8217;s try other way around: user asks for somewhere.com entire site is hidden behind a login form authentication mechanism, so instead of an application, user is presented a form, so they can provide credentials, once user submits, the originally requested page is provided, so as it was before: application loads, issues a new data request (application/json) for user name and receives it back, everything is nice so far&#8230; but let&#8217;s assume that our session expires (for whatever reason) while we are in the middle of a long and complicated form&#8230; Guess what? We are exactly in the same place as before: our application is up and running, but our session is not valid any more and form based authentication is useless at this point. Or isn&#8217;t it? Let&#8217;s try to adapt. Using AngularJS, we can simply write an http interceptor. Such a interceptor can check every response and once it detects a login form, we can&#8230; well&#8230; We can redirect ourselves to a login page, but this is a complicated task, because server does not know where we are at the moment (or to be more precise: what is our state, what were we doing). Remember, client-side application is client-side, how is server supposed to figure out what to do next, after we logged in? From server-side point of view we are sitting on one page all the time. We can be smarter: we can bring an IFRAME to life, it will show login form. But this is also complicated: we have to figure out somehow what is happening inside such an IFRAME. How to detect successful login? Is it easy? Hard? Not that hard but tricky? Of course everything is doable, but after investigation, I did something else. Very simple and clean, but requires server side adjustments. Solution: client-side login form when server answers: status 401. My solution assumes the following server side behaviour: for every /resources/* call, if user is not authorized, response a 401 status. Otherwise, when user is authorized or when not a /resources/* request, send what client asked for. No login forms, but we still need some login URL, so our application can send login and password there. Plain-old cookie based sessions? Why not, they work for me, web browsers and application servers handle them automatically by default. AngularJS has a $http service. It allows custom interceptors to be plugged in: Nice thing is that from &#8216;response&#8217; parameter we can rebuild the request. To fully understand how the $http interceptor works, we need to understand $q. The goal is to be able to: capture 401 response, save the request parameters, so in the future we can reconstruct original request, create and return new object representing server&#8217;s future answer (instead of returning the original failed response), broadcast that login is required, so application can react, in particular login form can appear, listen to login successful events, so we can gather all the saved request parameters, resend them again and trigger all the &#8216;future&#8217; objects (returned previously). Nice thing about the solution above is that when you request something, but server responds with status 401, you do not have (and you cannot) handle this. Interceptor will handle this for you. You will eventually receive the response. It will come as nothing had happened, just a little bit later (unless user won&#8217;t provide valid credentials). OK, so here is a bit of code. I wanted to provide a working example with a login window, using jsfiddle.net, but have to postpone it. It is getting a little bit late now, so I am finishing this entry here. I hope you like it :)]]></description>
		<wfw:commentRss>http://www.espeo.pl/2012/02/26/authentication-in-angularjs-application/feed</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>AngularJS is going to be released soon!</title>
		<link>http://www.espeo.pl/2012/02/07/angularjs-is-going-to-be-released-soon</link>
		<comments>http://www.espeo.pl/2012/02/07/angularjs-is-going-to-be-released-soon#comments</comments>
		<pubDate>Mon, 06 Feb 2012 23:04:30 +0000</pubDate>
		<dc:creator>Witold Szczerba</dc:creator>
				<category><![CDATA[Blog]]></category>
		<category><![CDATA[english]]></category>
		<category><![CDATA[technologia]]></category>
		<category><![CDATA[AngularJS]]></category>
		<category><![CDATA[javascript]]></category>

		<guid isPermaLink="false">http://www.espeo.pl/?p=4360</guid>
		<description><![CDATA[Last year, I was working, with my friend, on a prototype of an application using AngularJS. The AngularJS project&#8217;s goal is, in few words, to make a web browser a full-featured application environment. Miško Hevery (do I have to introduce him?), AngularJS project founder describes the project like this: What HTML would have been had it been designed for web apps. At that time, Angular team was developing 0.9 branch. That was my first attempt to create a real client-side application working in browser environment. Web Server is providing only application code (including static markup templates) and data. There is no server-side HTML generation. That was just a prototype of an application, unfortunately the project never fired up. Too bad, but I do not regret, because I gained a new experience. One year passed. During that period, I was following the AngularJS project almost non stop. I really like the way it is growing, together with great community. Right now (beginning of February, 2012) the AngularJS team is working on the final 0.10.x release, which according to the schedule, is going to be the release candidate of the long-awaited version 1.0. Since few weeks, I am a tech-leading brand new project at Espeo Software. AngularJS plus Java back-end (my prototype used Java EE 6, but the one picked for this project is backed by Spring Framework 3.1). I think it is nice opportunity to share some tips (or tricks?) with you. I do not have any agenda, but in my next blog entry, I would like to cover authentication and authorization. I will describe how am I dealing with it on the server and client-side. Stay tuned :)]]></description>
		<wfw:commentRss>http://www.espeo.pl/2012/02/07/angularjs-is-going-to-be-released-soon/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>

