Byliście kiedyś na CodeRetreat? Bardzo fajna impreza, której ideą jest pisanie kodu w możliwe najlepszy sposób. Na koniec dnia nie trzeba dostarczyć produktu, przede wszystkim trzeba poznać nowe sposoby na rozwiązywanie tego samego problemu. Oczywiście w trakcie trwania imprezy, żeby nie było za nudno, mistrz ceremonii rzuca pod nogi kolejne kłody: krótkie metody, brak ifów, brak czegoś innego, itp-itd, fajna sprawa która powoduje, że uczestnik ciągle poszukuje, a przez to poznaje nowe różne rozwiązania. Często okazuje się, że ograniczenia które były wprowadzana, wymuszały chwilę rozmyślenia jak napisać kawałek kodu inaczej, a to powodowało dużo lepszy kod. Do czego zmierzam? Otóż po pierwsze primo, już za nie długo odbędzie się kolejna już edycja Global Day of Coderetreat we Wrocławiu, po drugie primo: takie ograniczenia z code retreat można wprowadzić sobie w życie także w pracy w normalnym projekcie. Otóż na każde rozpoczęcie sprintu lub tygodnia, można ustalić reguły: np. w tym tygodniu decydujemy się, że metody nie mogą przekroczyć np. siedmiu linijek, albo nie używamy typów prostych, wersja dla profesjonalnych graczy: nie używamy if’ów, etc. Dlaczego? W ten oto prosty sposób, możemy nie jako wymusić na swoich kolegach pisanie lepszego kodu, nie trzeba im wtedy mówić, o SOLID, czy dobrych praktykach, czy czymś innym, po prostu ustalacie wspólnie, że to i tamto i przez tydzień macie taką “grę”, potem retrospekcja i nowe reguły, nowe doświadczenia, nowy tydzień i nowe reguły i znowu retrospekcja – aż wszyscy zrozumieją jak pisać dobrze. Tym sposobem i sprint przyjemniejszy i kod lepszy. Takie moje luźne myśli na kolejny tydzień.
krótki wpis
EmptyResult na zły sposób
Programując internety gdy wysyła się jakieś żądanie na serwer nie można założyć, że poleceni się po prostu wykona. Operacja void nie istnieje. Tzn można, ale to zła praktyka, można przecież wysłać żądanie i nie sprawdzić czy w ogóle doszło ono na serwer. Ale nie o to chodzi, mój przypadek polegał na tym, że wysyłać na serwer żądanie i chciałem tylko sprawdzić czy serwer to dostał czy nie. W moim przypadku wynik w ogóle nie był ważny. Naiwnie pomyślałem sobie, że wystarczy zwrócić (oczywiście w .net asp mvc) new EmptyResult() a na kliencie sprawdzić czy długość wyniku jest zero. Jak można się domyślić nie było by tego wpisu gdyby rzeczywistość nagięła się do mojego wyobrażenia.
Otóż pozytywny wynik operacji oraz długość wyniku była by zero gdybym wysłał request i ustawił dataType na script lub html. Ale nie w moim przypadku ja chciałem json. I co? Otóż biblioteka, która wrapowala żądania też była sprytna i czasem wysyłała żądanie json a czasem xml. I teraz operacja czasem działała gorzej a czasem jeszcze gorzej. Nie wiem czemu ubzdurałem sobie że EmptyResult coś zwróci i nie powinienem sprawdzić statusu odpowiedzi, zamiast zawartości PUSTEGO WYNIKU.
Ale jeśli jesteście ciekawi co odpowiada serwer na różne żądanie popatrzcie na ten przykładowy kod:
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: Consolas, “Courier New”, Courier, Monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #a31515; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
1: public class BlogController : Controller
2: {
3: [HttpGet]
4: public ActionResult Index()
5: {
6: return this.View("Index");
7: }
8:
9: [HttpGet]
10: public ActionResult CallMeToGetSuccessEmptyResult()
11: {
12: return new EmptyResult();
13: }
14: }
Następnie widok:
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: Consolas, “Courier New”, Courier, Monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #a31515; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
1:
2: <script src="~/Scripts/jquery-1.10.2.js"></script>
3: <div class="row">
4: @Html.ActionLink("By xml", "CallMeToGetSuccessEmptyResult", "Blog", null, new { @class = "btn btn-default test-button", id = "demo-xml", data_type_of_data = "xml", data_anchor_id = "#demo-container-xml" })
5: @Html.ActionLink("By json", "CallMeToGetSuccessEmptyResult", "Blog", null, new { @class = "btn btn-default test-button", id = "demo-json", data_type_of_data = "json", data_anchor_id = "#demo-container-json" })
6: @Html.ActionLink("By script", "CallMeToGetSuccessEmptyResult", "Blog", null, new { @class = "btn btn-default test-button", id = "demo-script", data_type_of_data = "script", data_anchor_id = "#demo-container-script" })
7: @Html.ActionLink("By html", "CallMeToGetSuccessEmptyResult", "Blog", null, new { @class = "btn btn-default test-button", id = "demo-html", data_type_of_data = "html", data_anchor_id = "#demo-container-html" })
8: </div>
9:
10: <div class="row">
11:
12: <div class="col-md-3">XML<div id="demo-container-xml"></div></div>
13: <div class="col-md-3">JSON<div id="demo-container-json"></div></div>
14: <div class="col-md-3">SCRIPT<div id="demo-container-script"></div></div>
15: <div class="col-md-3">HTML<div id="demo-container-html"></div></div>
16: </div>
17:
18: <script type="text/javascript">
19:
20: var showJson = function(data, status, anchor) {
21: $(anchor).html('');
22: var htmlToSet = "status: " + status + "<br/>";
23: if (data != null) {
24: htmlToSet += "data lenght: " + data.length;
25: } else {
26: htmlToSet += "data is null";
27: }
28: $(anchor).html( htmlToSet );
29: };
30:
31: var demoResult = function(e) {
32: e.preventDefault();
33: var href = $(e.target);
34: var data_type = href.data("type-of-data");
35: var anchor = href.data("anchor-id");
36: var ajaxOptions = {
37: url: '@Url.Action("CallMeToGetSuccessEmptyResult", "Blog")',
38: dataType: data_type,
39: success: function(data, status) {
40: showJson(data, status, anchor);
41: },
42: error:function(data, status) {
43: showJson(data, status, anchor);
44: }
45: };
46:
47: $.ajax(ajaxOptions);
48: };
49:
50: $(document).ready(function() {
51: $(".test-button").on("click", demoResult);
52: });
53:
54: </script>
I teraz na obrazu wyniki działania aplikaji:
Czyli nie zawsze EmptyResult to tylko “”, czasem to także parseerror gdy oczekujemy json. Na przyszłość polecam zastanowić się co się powinno sprawdzić, gdy nie chcemy nic sprawdzać. Oraz jak chce to sprawdzić.
Jak zawsze, chętnie popełnię kolejne błędy za was w następnym odcinku.
Redirect to anchor w asp mvc
Od jakiegoś czasu pracuje za prawdziwe złoto jako sieciowy programista, dawno nikt nie wymagał aby po przekierowaniu wrócić do jakiegoś specyficznego kawałka strony. Zawsze kończyło się przekierowaniem do pełnej. Zapomniałem już o takiej funkcjonalność, no prawie zapomniałem. Otóż klepiąc sobie coś tam w domu, chciałem po zrobieniu POSTa wrócić gdzieś na dół strony, akcja nie korzysta ze zdobyczy technologi jaką jest AJAX, więc strona się przeładowywuje. Pozostało mi tylko skorzystanie z elementu html, który posiada znacznik id oraz nawigacja do strony z podaniem tego znacznika w url. Znacznik podaje się po znaczku ‘#’. Kompilator nie chciał tego przyjąć do wiadomości, gdy próbowałem zrobić this.RedirectToAction(“Index”,”Home”,new{#=”comments”}); nie działało.
Na szczęście internety dają radę także i tym razem super hero w postaci stack overflow ułatwił życie.
Uwaga podaję odpowiedź:
this.Redirect(Url.RouteUrl(new { controller = “Home”, action = “Index”}) + “#comments”);
To tyle w tym krótkim odcinku. Jutro znowu do pracy.
A jak Pan klei stringi?
Człowiek idzie na rozmowę o pracę i pytają go o różne rzeczy, najczęściej pytają o to czego i tak nie będzie korzystać w tej pracy. Np, ile piłek golfowych mieści się w autobusie, czy ile jest okien w wąchocku, chociaż w takimi rzeczami lubi się parać HR. Nasi pytają o wzorce, gdzie najczęściej pada odpowiedź singleton i/lub fabryka. Wcześniej może zapytają o różnicę pomiędzy value type i reference type i kolejny klasyk to konkatenacja stringów. Każdy kto był chociaż na jednej rozmowie odpowie StringBuilder.
Jak często zdarza się wam łączyć taką ilość stringów, że tworzycie StringBuildera, żeby rzeczywiście było szybciej?. Ja chyba nigdy nie byłem (albo już nie pamiętam) w takiej sytuacji, ale zawsze mnie o to pytają. Po jednej z takich rozmów zacząłem rozmyślać co robię w takich sytuacjach, gdy mam kilka stringów do sklejenia, czy korzystam z łączenia stringów i o matko alokuje tworze ich kilka w pamięci raz na kilka sekund czy może tworze owego magicznego wszech potężnego Buildera, aby uratował mnie przy klejeniu “Ala ma 1 kota, koloru szarego“. Uświadomiłem sobie, że praktycznie zawsze korzystam ze string.Format. I co teraz? A jeśli on jest źle zaimplementowany i chłopaki z mikrosoftu kleją stringi jak przedszkolaki? Nie mogłem spać po nocy i musiałem sprawdzić. Dot peek na ratunek, sprawdziłem i jest pięknie, jestem uratowany, jest bohater, w środku siedzi StringBuilder i robi swoje. Także jeśli jesteście ciekawi co jest szybsze czy string.Format czy nowy StringBuilder to sprawdźcie sami. Ja w każdym bądź razie od teraz będę na rozmowach mówić, że korzystam ze string.Format().
Tyle, ot taki krótki wpis.
Code coverage bywa zdradliwy
Od kilku dni wdrażam w życie dopisanie testów do strony nad którą pracuje, bo lepiej późno niż wcale. W zabawie tej korzystam z dodatkowego narzędzia jakim jest ncrunch. Trochę więcej o nim na blogach Paweł i Arek Bardzo ciekawa sprawa, ale warto mieć dobry sprzęt, aby w pełni korzystać ze wszystkich funkcjonalności. Mi do gustu przypadła funkcjonalność mierzenia pokrycia kodu testami. Pomyślałem sobie – “spoko“, nie będę się musiał martwić, czy mam wszystko przetestowane – i właśnie o tej pułapce parę słów. Załóżmy taki kod, który będzie zmanipulowany na potrzeby przykładu:
public class UnderTest
{
private int someInternalVariable;
public void Foo(int a)
{
if (a == 1 || a == 3)
{
this.someInternalVariable = a;
}
}
}
A następnie taki test, który sprawdza czy zmienna została przypisana
[TestFixture]
public class Test
{
[Test]
public void T001()
{
var sut = new UnderTest();
sut.Foo(5);
Assert.AreEqual(0, sut.SomeVariable);
}
[Test]
public void T001_With_Params()
{
var sut = new UnderTest();
sut.Foo(1);
Assert.AreEqual(1, sut.SomeVariable);
}
}
Patrząc teraz na metryki, wynik cieszy oko i aż prosi żeby pochwalić się światu, że testy mamy w jednym palcu, architektura u nas to kozak, bo właśnie wykręciliśmy 100% pokrycia kodu. Aaale potem kątem oka dostrzegamy pułapkę! O nie, a co z przypadkiem gdy a będzie 3, przecież nie mamy takiego testu – jak to możliwe, skoro cyferki mówią 100%, a serce mówi że brakuje. No tak dzieci, bo musicie pamiętać, że code coverage bywa zdradliwy i nigdy, przenigdy nie powinno się tylko na nim opierać wyników naszego testowania. . A to że kusi, to że menagierowie mówią i chcą żeby było przynajmniej 100/80/60/x procent to wiecie, oni są pragnienie, to my jesteśmy oranżada.