poniedziałek, 24 października 2016

RevDeBug

In last Thursday I have pleasure to take part in Warwaw .NET User Group and hear about new logging tool named "RevDeBug".

RevDeBug is a .net tool, that can be joined to any .net solution at compile time and after compiled into .net solution it collect information about call stack. It's not "error call stack" that we know from standard exception stacktrace. It collects any information, about how code was executed so we can watch how aplication works line by line like we usually do it in debuger. But this time, this code is from production/uat/whatever server.

For me it is quite interesting tool. Maybe I will use it in future in production when I find some very tricky error. 

Cons: 
- logs can be really huge, in example 1GB of logs can be taken in 15-20 minutes (or maybe even less)
- performance - every logging tool working live on production lowers performance of our application

https://www.revdebug.com/ -> project web site

Session about RevDeBug in English (from .net Leipzig Meetup)







niedziela, 14 sierpnia 2016

HTML 5 Local Storage vs Cookies

While I was solving Weekly Javascript Chalange Task 3 I ask my self a quite interesting question. What is a difference between Local Storage and Cookies?
Somebody already asked that question on SO:  http://stackoverflow.com/questions/3220660/local-storage-vs-cookies ,and there is a very good answer:

Cookies and local storage serve different purposes. Cookies are primarily for reading server-side, local storage can only be read client-side. So the question is, in your app, who needs this data — the client or the server?
If it's your client (your JavaScript), then by all means switch. You're wasting bandwidth by sending all the data in each HTTP header.
If it's your server, local storage isn't so useful because you'd have to forward the data along somehow (with Ajax or hidden form fields or something). This might be okay if the server only needs a small subset of the total data for each request.
You'll want to leave your session cookie as a cookie either way though.
As per the technical difference, and also my understanding:
  1. Apart from being an old way of saving data, Cookies give you a limit of 4096 bytes (4095, actually) - its per cookie. Local Storage is as big as 5MB per domain - SO Question also mentions it
  2. localStorage is an implementation of the Storage Interface. It stores data with no expiration date, and gets cleared only through JavaScript, or clearing the Browser Cache / Locally Stored Data - unlike cookie expiry.

 Why I mention about it? For two reasons:
a) I use this blog as my notepad, that I sometimes visit
b) this question have a great "interview question" potential



sobota, 13 sierpnia 2016

Weekly JavaScript Challenge

This note is to promote some great event that I have found in internet.

Michał Miszczyszyn is one of polish javascript community leader and he starts new weekly javascript chalange. It works, that Michał ones a week create new javascript task, and any competitor can join and try to solve that task. After that time (about one week) Michał takes responses and makes code review.
When he finish code reviews he put task review on his blog.

What a great oportunity for learning new language with code review. Seems great. What you think about it?

I think, that I try to solve some challenges in my free time, but not guarantee that they where will appear regular.

Links:
Michał blog: https://typeofweb.com
Michał blog posts about chalange: https://typeofweb.com/tag/weekly-javascript-challenge/
facebook group where we can find news about new challenge: https://www.facebook.com/groups/1131907053499522/
First task event: https://www.facebook.com/events/997187053723327/
My solutions on github: https://github.com/zchpit/WeeklyJavaScriptChallenge
My solution for task 1 in jsFindle: https://jsfiddle.net/vknqwnb8/15/

niedziela, 31 lipca 2016

Review of tools for PDF generate in .net

 This is my first blog post in English, so fill free to add your comment if any part is incomprehensible.

We have many pdf libraries that we can use, but none of them are perfect and all of them have some advantages and disadvantages. Here is my little experience with generating PDF file in .net framework with generating reports both, in a browser on demand and large numbers in bash/console by night.

Crystal_Reports - big, commercial library develop by big company
Pros: 
- can be really fast
Cons: 
- ugly (at least not pretty) reports
- works on my machine issue (your report can be seen different in different machine, in example on server what can be frustrating when troubleshooting). 

SQL_Server_Reporting_Services - big library that comes with commercial licence for MS SQL Server
Pros:
- quite pretty
- have many in common with office / excel, so you BI can help you in building reports
- can use custom fonts
Cons:
Local Mode:
- have memory leaks (you will see it when you try generate PDF in large numbers)
- more complicated reports can be really slow (reporting services team upgrading reporting services from .net 3.5 to 4.0 made bug with grouping rows in table).
- don't have justify text 
- you can't "copy/paste" document from MS Word
Server Mode:
- sometimes there are issue with authentication and priviliges
- you can't use collection of your objects as data source (it was a reason why I choose Local Mode).
- don't have justify text 
- you can't "copy/paste" document from MS Word

Wkhtmltopdf - open source library made by google for converting html into pdf
Pros:
- quite fast
Cons:
- graph from jQuery library are medium quality (in magnification you can see pixels)
- few options for editing text

MS Word Interop - native MS Word API for CRUD operations in word documents
Pros:
- best MS Word document projection
Cons:
- slow
- need to have MS Office Word installed on working machine
- requires a little work and workarounds when we want to use it from task scheduler ( http://stackoverflow.com/questions/1006923/automating-office-via-windows-service-on-server-2008/1680214#1680214 )
- requires a much more work when we want to use it from IIS 

Telerik - Kendo-UI - commercial library to creating great html, and export it to pdf
Pros:
- quite pretty
- write html and just export it into pdf
Cons:
- have trouble with custom fonts 
- pdf generation could be faster 

sobota, 2 lipca 2016

ELMAH

ELMAH, czyli Error Logging Modules And Handlers (ELMAH) - jest to biblioteka/moduł dostępny za darmo służący do zarządzania oraz monitorowania błędów w oprogramowaniu. Moduł ten oparty jest na śledzeniu zdarzeń i można go podpiąć do istniejącej aplikacji bez zmiany ani jednej linii kodu (zmiany wykonujemy tylko w konfiguracji). Główne zadania ELMAH-a, to obsługa, zarządzanie, monitorowanie, eskalacja błędów, ze szczególnym uwzględnieniem błędów nieobsłużonych.

Główne zalety/funkcjonalności ELMAHA:
- prostota konfiguracji
- prosty interfejs webowy pokazujący szczegółowe dane
- odkładanie błędów do bazy danych / plików xml / etc
- przechwytywanie i logowanie nieobsłużonych błędów
- wysyłanie maili i notyfikacji w momencie wystąpienia błędów
- logowanie wszystkich lub tylko wybranych typów błędów
- darmowa biblioteka
- możliwość logowania w sposób "tradycyjny" z poziomu C#
( ErrorSignal.FromCurrentContext().Raise(e); )


Z tego tez powodu uważam, że warto się przyjrzeć tej bibliotece bliżej.

Linki:
- http://code.google.com/p/elmah/
- http://www.asp.net/web-forms/overview/older-versions-getting-started/deploying-web-site-projects/logging-error-details-with-elmah-cs

 

niedziela, 20 marca 2016

konferencja meet.js summit (#meetjs16)

O konferencji "Meet.js Summit 2016" dowiedziałem się dosyć niedawno, czyli na około tydź. przed konferencją. W tamtym czasie, biletów już nie było, jednak dzięki odrobinie szczęścia oraz życzliwości jednego z użytkowników portalu wykop.pl udało mi się zdobyć wejściówkę na tą konferencję (jednemu z uczestników coś wypadło i oddał wejściówkę, aby się nie zmarnowała). Tym oto zrządzeniem losu udało mi się pójść na tą, jakże wspaniałą konferencję, poświęconą językowi javasctipt.

Najpierw pokrótce opiszę kilka prezentacji, na których byłem, a nast. kilka uwag ogólnych na temat konferencji.

Katarzyna Jastrzębska - "Web projects with ClojureScript" -> Kasia pokazała nowy język, będący mieszanką Clojure oraz Javascriptu (te języki można mieszać ze sobą w składni, m.in. w taki sposób następuje odwołanie do obiektów drzewa DOM). Moje pierwsze wrażenie na temat ClojureScript jest takie, że nie zastosował bym go w moich, korporacyjnych projektach. Powodem jest zbyt słabo typowana składnia. Kasia jako przykład dynamiki języka, pokazała instrukcję "if", która nie jest wyrażeniem języka, a jedynie funkcją odpowiednio zmutowaną, aby pełniła taką rolę (sam język nie posiada instrukcji "if"). Jest przez to bardzo elastyczny. Niestety, ale w korporacjach utrzymanie istniejącego kodu trwa wiele lat, zespoły programistyczne zmieniają się często, a przez to miałem m.in. okazję utrzymywać kod jako piąty programista. Oczywiście każdy poprzednik miał swój sposób pisania kodu, swoje dobre praktyki oraz swoje niedbałości. Jak do tego dojdzie jeszcze pisanie "if-a" na 20 różnych sposobów, to w takim kodzie po kilku latach może być naprawdę niezły "mindfuck".
Pozwólcie, że zacytuję klasyka:
define TRUE FALSE
//Happy debugging suckers
Jeżeli natomiast chodzi o uwagi do prelegenta, to miałbym 3 drobne uwagi:
- więcej pewności siebie ;-)
- na slajdach, które pokazują tą samą metodę w 2 językach jednak fajnie by było, gdyby ta metoda posiadała tą samą nazwę, oraz te same parametry
- przy pokazywani praktycznych przykładów, dobrze jest wcześniej przygotować sobie snippety z kodem (wtedy wszystko odbywa się jakby płynniej)
- ale ogólnie to pozytywna prezentacja
- dziękuję za kubek scalaz ;-)

Grzegorz Koronowski - "Angular & JS lessons learned" -> całkiem fajna prezentacja nt. praktycznych przykładów korzystania z angular.js. Osobiście nie korzystałem z angulara na produkcji, natomiast kolega, który siedział obok mnie, nad jednym z pokazywanych przykładów (nr. 2 lub nr. 3), spędził sporo czasu w pracy, a na koniec doszedł niezależnie do podobnych wniosków, co autor. Ja się zastanawiałem nad przykładem nr.4, tj. czy nie prościej było by zwobić zwykły "target _blank", ale później sobie pomyślałem, że autor zapewne do nowego okna chciał przekazywać stan aplikacji lub jej parametry w sposób "ukryty", oraz obudować tą logikę w jakiś sprytny mechanizm. Takie też później padło pytanie, a odpowiedź mniej więcej pokrywała się z moimi przypuszczeniami. Ogólnie fajna i na pewno przydatna prezentacja. Taka życia.
Drobna uwaga do prelegenta: w wolnej chwili można ciut bardziej podszlifować język angielski. Jest dobrze, ale mogło by być jeszcze lepiej ;-)

Łukasz Fiszer - "Npm scripts as an automated tool" -> fajny talk. Łukasz przedstawiał sposoby automatyzacji tasków, oraz sporo porównywał do obecnie stosowanych narzędzi, tj. gulp i grunt. Że często próbuje się z nich zrobić "szwajcarski scyzoryk" i stosować nawet w tych miejscach, w których nie powinno się tego robić. Łukasz wspomniał też o tym, że na rynku popularne są dwa narzędzia o niekompatybilnych ze sobą plikach wsadowych, dlatego on pokazuje trzecie rozwiązanie. Z drugiej strony, podczas swojej prezentacji był bardzo przekonujący.

Robert Kawecki - "Reliable Node.js application for a reactive world" -> dosyć dobra prezentacja o tym, co jest ostatnio "trendy" w świecie backendu, czyli CQRS + EventStore + DDD, na przykładzie konkretnego, działającego produktu, stworzonej przez stosunkowo młodą firmę. A to wszystko w świecie javascriptu. Jak ktoś chce poznać obecne trendy na konkretnym, działającym (i wdrożonym produkcyjnie) przykładzie, w dodatku przedstawioną w bardzo prostej i przystępnej formie, to koniecznie powinien obejrzeć tą prezentację. Po prostu SUPER!!!.

Łukasz Korowicki - "Style Guide Driven Development - Episode IV - New Hope for Front-end" -> ta prezentacja, to taki przekrój przez dostępne obecnie na rynku sposoby tworzenia różnej maści "css-ów", czyli LESS, SASS. W sumie nie jestem grafikiem, więc się nie wypowiem nt. szczegółów.

Adrian Makowski & Adam Chwitkowski - "Creating easy going code" -> bardzo fajna prezentacja. Oboje panowie wybrali po kilka prostych zasad, zarówno z front-endu, jak i back-endu, których przestrzeganie bardzo ułatwia życie. Z front-endu było m.in. oocss, bem, itcss, natomiast z back-endu były 2 literki z SOLID oraz "composition over inheritence" (interfejsy > dziedziczenie) wraz z praktycznymi przykładami "bad code vs good code" + tdd. Rady odnośnie backendu znałem od dawna, za to najwyższy czas, zainteresować się tym, co oznaczają wymienione skróty z frontendu. Bardzo fajna i przydatna prezentacja.

Artur Szott - "React enlightenment - my 10 month Journey with React.js" -> z tego co pamiętam, to Artur pokazywał w swojej prezentacji, że sam React.js na początku może być nieco przytłaczający dla kogoś z zewnątrz, oraz pokazywał od czego można zacząć, czyli od ".jsx" natomiast testować z wykorzystaniem mocha i chai. Tak teraz sprawdzam i... nie mam więcej notatek na temat tej prezentacji, czyli raczej taki intro talk dla zupełnie początkujących w świecie react-a.

Zbyszek Tenerowicz - "Gettin your Node.js app production redy" -> od jakiegoś czasu, bawię się w domu kursem Node.js z nodeschool.io i ten talk był idealnie adresowany do mnie, ponieważ autor wychodzi z założenie, że jego widownia tyle co skończyła kurs na nodeschool.io albo inny, czyli zna podst. node.js i chciała by zrobić krok dalej, czyli umieścić swoje rozwiązanie na produkcji. Zbyszek pokazuje zaróno narzędzia z jakimi poleca się zapoznać, tj. pm2 (process manager),  podejścia programistyczne, jakie powinniśmy stosować w naszym node.js (aplikacja pomiędzy requestami http powinna być bezstanowa, ewentualnie kiedy już naprawdę jesteśmy zmuszeni utrzymywać stan pomiędzy requestami, to wtedy korzystamy z redis). Wszystko powinniśmy wykonywać asynchronicznie, polubić się z TypeScryptem, zapoznać się z poziomami logowania, podpiąć pod istniejące syst. monitorowania w firmie, o ile takie są (kiepski syst. monitorowania, na który ktoś patrzy full time, jest dużo lepszy niż dobry syst. monitorowania, na który sami będziemy patrzeli od czasu do czasu). Kolejne narzędzia / biblioteki, do monitorowania stanu aplikacji: Nsp chceck, node secure project, requireSafe (oraz komenda javascriptowa process.memoryUsage().rss wykonywana z wewnątrz naszego kodu). I na koniec linki, czyli absolutny "must watch", czyli netflix -> nodejs-in-flames, ponieważ lepiej wiedzieć co nas spotka w życiu wcześniej i od samego pocz. mieć przyg. plan naprawczy. Super talk. Jak dla osoby, która sama sobie po nocach koduje w node.js, a docelowo chcę zrobić jakiś własny "pet project", w którym node.js wykorzystam, to ten talk był dla mnie super.
p.s. uwaga na wycieki pamięci, ponieważ node.js ma limit 1.5gb danych (jak proces node.js będzie zajmował więcej pamięci, to się wywali).

Michał Załęcki - "Reactive JavaScript" -> ta prezentacja, to opis tego, czym są "reactive extensions", jaka była droga ewolucji w javascripcie, czyli callbacks -> promises -> asynnc/await -> react extensions (i dlaczego aktualnie warto stos. właśnie reactive extensions i w czym one są lepsze, np. dużo bardziej czytelna składnia niż async/await). Było też o zastosowaniu kilku wzorcach projektowych (m.in. obserwator), oraz programowania funkcyjnego w javascript. Całkiem przyjemny talk poglądowy, dlaczego warto korzystać z reactive extensions. Całkiem miło i przyjemnie spędzony czas.

Z prelekcji, na których nie byłem, za to widzę wielkie ochy i achy na twitterze, to Staś Małolepszy - "The future od Javascript is now. How to make the most of it?". Jak tylko pojawią się nagrania z konferencji w necie (prelekcje były nagrywane), to chętnie ją sobie obejrzę.

Uwagi ogólne do organizatorów? Super konferencja, dobra lokalizacja, wyżywienie, mega super prelekcje. Naprawdę mega konferencja. Czy czegoś mi brakowało albo co można by było zmienić? Brakowało mi dwóch rzeczy. W sumie pierdoły, ale mogę o nich wspomnieć:
- osoby z dzwonkiem, która by przypominała, że właśnie rozpoczęła się prezentacja na jednej z sali. Na korytarzu zawsze było kilka osób, był szum, ciągle coś się działo, więc bardzo łatwo można było przegapić czas rozpoczęcia prezentacji, co skutkowało tym, że drzwi do sali były otwarte trochę dłużej niż powinny (nawet 10-15 min od rozpoczęcia prelekcji) i siedząc w ostatnich rzędach było słychać szum dochodzący z korytarza.
- na jednej z konferencji zauważyłem fajny bajer, tj. 3 kolorowe karteczki (zielony, żółty, czerwony), które były dostępne podczas wychodzenia z prezentacji a wychodzący z prezentacji uczestnicy wrzucali je półmiska, dając tym samym łatwo widoczny "feedback".

Ale tak to super. Mega konferencja i jestem bardzo zadowolony, że mogłem wziąć w niej udział. Jakościowo to stała MEGA, co zresztą widać w opisach konkretnych prezentacji. Zdecydowanie polecam.



czwartek, 17 marca 2016

Node.js

Ost. czasy bardzo popularnym językiem jest javascript. Ten język istnieje od dosyć dawna, jednak przez wiele lat traktowny był "po macoszemu". Ost. kilka lat, to jednak zdecydowany "boom" na ten konkretny język. Ilość bibliotek i frameworków jaka powstaje jest wprost niesamowita.
Javascript przez wiele lat kojarzony był głównie z frontendem, czyli tą częścią strony www, która wykonuje się bezpośrednio w przeglądarce internetowej. Teraz jednak javascript dorobił się porządnego rozwiązania serwerowego, zgodnie z ideologią "jeden język programowania - wszędzie". Typ rozwiązaniem serwerowym jest Node.js

Krótki wpis, co to jest npm (node package manager), jak i samo nodejs można znaleźć na blogu Gutka link, więc nie będę się tutaj powtarzał, szczególnie, że Gutek opisał to fajnie, zgrabnie itp (ohy i ahy).

Ja z mojej strony polecił bym zacząć się z tym bawić, od robienia tutoriali z nodeschool.io/.Samemu skończyłem już część Core-ową i aktualnie robię wersję rozszerzoną i jak na razie mi się to podoba. A, że warto spróbować i dać nodejs szansę, to warto spojrzeć choćby na przykładowy serwer wystawiający json-y, jaki można postawić z wykorzystaniem biblioteki "express".

var portNumber = process.argv[2];
var url = require('url');
var express = require('express');
var app = express();

app.get('/api/parsetime', function(req, res){
  var parsedUrl = url.parse(req.url, true);
  var date = new Date(parsedUrl.query.iso);

  res.json({ hour: date.getHours(), minute: date.getMinutes(), second: date.getSeconds()  })
});
app.get('/api/unixtime', function(req, res){
  var parsedUrl = url.parse(req.url, true);
  var date = new Date(parsedUrl.query.iso);

  res.json({ unixtime: date.getTime() })
});

app.listen(portNumber);

Wygląda znajomo?
Prawie, jak w we wspaniałym nancyfx.org.
Dodatkowo, fajnie rzeczy można wyczarować operując na strumieniach danych (nieco inaczej się operuje niż w c#) oraz tworzyć z nich "wężyki" Method chaining.

Całkiem interesująca technologia.