KoziołekWeb

Na GW trwa radosna przepychanka pomiędzy pieszymi, rowerzystami i kierowcami. Czytając listy do redakcji pisane przez fanów dwóch kółek dochodzę do wniosków, które mnie bardzo smucą. Przede wszystkim rower w Polsce stał się tym czym kiedyś w internecie była Neostrada. Mieliśmy dzieci Neostrady dziś mamy do czynienia z pokoleniem Veturilo. Obie te grupy zachowują się jakby miały ADHD napędzone za pomocą metaamfetaminy. Niestety szczytny cel jakim było promowanie zdrowego trybu życia i jednocześnie odkorkowanie miast zostało pogrzebane pod górą arogancji i zwyczajnego chamstwa.

Na początek proponuję pewne proste ćwiczenia mające uzmysłowić ci drogi użytkowniku czym jest rower. Potrzebny będzie rower z licznikiem oraz jedna wizyta na siłowni albo u kogoś kto ma do dyspozycji bieżnię. Jeżeli masz prawo jazdy zachęcam też do wykorzystania samochodu.

Szybkość

Często przewijającym się argumentem za wpuszczeniem rowerów na chodniki w miejscach do tego nie przeznaczonych jest ten dotyczący szybkości. “Rowerem jeżdżę powoli”. Skoro tak to nie będziesz miał problemu z pierwszym ćwiczeniem. Najpierw udaj się na siłownię gdzie na bieżni (takiej zwyczajnej) wykonasz następujące ćwiczenia i pomiary:

• Idź przez pięć minut “normalnym tempem”. Nie za szybko, nie za wolno jak najbardziej naturalnie. Zanotuj prędkość.
• Przez kolejne pięć minut przyspiesz kroku. Teraz idziesz tak jak byś się śpieszył. Zanotuj prędkość.
• Ostatnie pięć minut poświęć na “podbieganie”. Dobierz tak prędkość by chód był już na tyle niewygodny by łatwiej było truchtać. Zanotuj prędkość.

Z mojego skromnego doświadczenia wynika, że rezultaty powinny być w okolicach 4km/h, 7km/h i 8,5km/h. Teraz wsiądź na rower i powtórz to ćwiczenie starając się zachować prędkości takie jak na bieżni. Podejrzewam, że dopiero ostatnia prędkość nie będzie powodować, że jazda jest niekomfortowa. Przy niskich prędkościach będzie ci trudno utrzymać równowagę, a i jakoś tak “dziwnie” się jedzie. Wynika to istnienia efektu żyroskopowego, który pozwala nam na utrzymanie równowagi na rowerze. Czas na drugie ćwiczenie. Będzie ono odwrotnością pierwszego. Na rowerze poruszaj się z prędkością zapewniającą komfort jazdy, następnie przyspiesz do tempa “marszowego” i zakończ całość szybką jazdą. Podejrzewam, że na bieżni nie zbliżysz się nawet do prędkości marszowej, a jeśli nawet ci się to uda to utrzymasz ją przez tylko przez krótki czas.

Na koniec trzecie ćwiczenie. Poruszając się z różnymi prędkościami spróbuj nagle zahamować albo zmienić kierunek. Jako piechur nie powinieneś mieć problemów z wyhamowaniem nawet z szybkiego marszu. Po prostu zatrzymasz się w miejscu. Rowerem droga hamowania znacząco się wydłuży (nawet jak zahamujesz “na krechę”). O zmianie kierunku nie wspominam, bo tylko na nogach jesteś wstanie zawrócić w miejscu nawet poruszając się truchtem (z hamowaniem).

Większość rowerzystów porusza się na po chodnikach z prędkościami komfortową albo “marszową”. W takim przypadku “jadę powoli” oznacza, że poruszasz się wielokrotnie szybciej niż piechur. Jazda w tempie pieszego w wielu przypadkach oznacza nerwowe ruchy kierownicą w celu utrzymania równowagi i “zygzakowanie”. To znowuż wynika z kolejnego elementu.

Potrafię jeździć

Nie potrafisz. Ja też nie potrafię. Obaj potrafimy za to wykorzystać wspomniany wcześniej efekt żyroskopowy by utrzymywać równowagę i jechać w miarę po prostej. Bardzo często obserwuję rowerzystów, którzy mają problem z jazdą w linii prostej. Nie są pijani. Po prostu nie potrafią jeździć na rowerze. Czas na kolejne proste ćwiczenie.

W tym celu udaj się na jakiś pusty parking przy centrum handlowym. Ważne jest by miejsca postojowe były wyznaczone w dobrze widoczny sposób. Wybierz w miarę długą linię dzielącą miejsca na parkingu taką ze 50 metrów, a im dłuższa tym lepsza. Postaraj przejechać całą jej długość z różnymi prędkościami, np. z poprzedniego zestawu ćwiczeń. Szybko zauważysz, że niezależnie od prędkości z jaką się poruszasz ciężko jest utrzymać ten cholerny rower na linii. No chyba, że się skupisz na jeździe… pojawi się efekt tunelowy i zapewne nie zauważysz niebezpieczeństwa. Trochę trudniejszą wersją tego ćwiczenia jest jazda po szerokim krawężniku. W tym przypadku trudność polega na tym, że masz tylko jeden kierunek ucieczki. Jeżeli koło ześlizgnie się z krawężnika i spadnie te kilka centymetrów to zapewne czeka cię gleba. Wiem co mówię, ponieważ wiele wakacyjnych godzin poświęciłem na to ćwiczenie i nie raz i nie dwa się byłem wyjebałem. Wersją prostszą jest próba zmieszczenia się w ciągu płytek chodnikowych. Niezłe są szczególnie te mniejsze trzydziestu-centymetrowe. Na kostce bauma szerokość toru to dwie, trzy szerokości kostni w zależności od sposobu ułożenia.

Ciężko prawda? Mój rower waży około 12kg, a ja około 100kg. Rowery tzw. miejskie dobijają do 16-18kg plus to co załadujesz do kosza. Im cięższy rower tym trudniej nad nim zapanować. Szczególnie jeżeli siedzi na nim osobnik ważący niewiele więcej niż ten rower. Dochodzi do tego problem bezwładności, który w połączeniu z generalnie kiepskimi hamulcami w rowerach miejskich daje efekt “szalonego bikera”.

Grzechy ciężkie rowerowe

Mam nadzieję, że ćwiczenia uświadomiły ci, że jazda rowerem nie jest ani prosta, ani łatwa, ani przyjemna. Chciałbym teraz poruszyć sprawę najcięższych przewinień popełnianych przez rowerzystów. Jest to moja lista, której skład wynika z codziennej obserwacji zachowań naszych rodzimych Easy Ridereów.

Bezmyślność i głupota

Objawia się na wiele sposobów. Przemilczę tu wybryki związane z poruszaniem się ze znacznymi prędkościami, nawet jak na rower, po chodniku. Znacznie bardziej niebezpieczne są zachowania nie rzucające się aż tak w oczy lecz równie głupie.

Po pierwsze rowerzysta dosiadający swego rumaka zaczyna zachowywać się jak kierowca. Pieszy staje się w wielu przypadkach nie tyle co zawalidrogą, a wrogiem. Niestety rowerzyści nie mają świadomości, że nawet w śród pieszych są tymi słabiej chronionymi uczestnikami ruchu. Rowerzysta zawadzając pieszego może, w najgorszym wypadku, złamać mu rękę. Sam nagle znajduje się w sytuacji kiedy kierownica obraca się o ponad 90 stopni, a on przelatuje nad nią. Miej niefart, traf w latarnię, słupek albo schody. Jak mawiał Ricewind to nie prędkość zabija, ale nagła jej utrata. Tak samo w tym przypadku. Po drugie sposób doboru trasy przez rowerzystów. W tym przypadku mamy do czynienia z myśleniem według schematów stosowanych przez pieszych. Trasa ma być najkrótsza. Nie ważne, że będzie prowadzić wzdłuż zatłoczonej ulicy przy której mamy wąski chodnik, po którym będzie jechało nasze cudowne dziecko dwóch pedałów. Nie ważne, że najprawdopodobniej będzie trzeba przeciskać się pomiędzy pieszymi. Nieważne, że jak nadłożymy 500m to będziemy mogli przejechać znacznie wygodniejszą trasą w strefie uspokojonego ruchu (czytaj jedziemy uliczkami osiedlowymi). Rower to jest naprawdę genialny wynalazek. Dla pieszego nadłożenie 500 metrów to wydłużenie podróży o kilkanaście minut. Dla rowerzysty? Nie więcej niż 5 minut. Tu z własnego doświadczenia mogę podać przykład, gdy jeździłem do pracy to różnica w odległościach pomiędzy trasą najkrótszą, a najdłuższą wynosiła około 2km. Jednocześnie różnica w czasie przejazdu nie była większa niż 2 minuty. Dlaczego? Trasa najkrótsza wręcz roiła się od przejść dla pieszych, sygnalizacji itp. spowalniaczy. Trasa najdłuższa miała w sumie tylko jeno niezbyt przyjemne miejsce w postaci wyjazdu z jakiegoś składu budowlanego gdzie kierowcy ciężarówek raczej niezbyt chętnie ustępowali pierwszeństwa. Po trzecie brak umiejętności przewidywania zachowań innych. Jakim kretynem trzeba być by pchać się pomiędzy pieszego, a drzwi od sklepu? Jak bezmyślnie trzeba jechać by nie zwracać uwagi na to, że piesi poruszają się z różnymi prędkościami i przy wzajemnym wyprzedzania migaczy nie używają. W końcu jak głupi jest kierujący, który próbuje ominąć pieszego po przesmykiem w którym na pewno się nie zmieści?

Brak znajomości przepisów i nieumiejętne zachowanie się na drodze

Paradoksalnie wielu miejskich rowerzystów to “nawróceni” samochodziarze. Większość z nich przepisy, teoretycznie, zna. I je olewa. Co zaś tyczy się nieumiejętnego zachowania na drodze to mam taką oto scenkę rodzajową. Jedzie sobie rowerzysta. Jedzie szybko i widząc, że nie utrzyma tempa na chodniku, bo robi się gęsto od pieszych, zjeżdża (prawidłowo) na jezdnię. Co się nagle dzieje? Ano nasz bohater zwalnia. Z prędkości 20+ wyhamowuje do niecałych 20 (jest to zauważalne). Staje się zawalidrogą. Zamiast kontynuować jazdę w miarę sprawny sposób zaczyna kombinować. W takiej sytuacji nie należy dziwić się kierowcom, bo poziom stresu rośnie przez takiego barana. Jeszcze czymś innym jest zachowanie na przejściach i przejazdach. Dla wielu rowerzystów istnienie przejazdu jest równoznaczne z przyzwoleniem na jazdę po przejściu. Tu piesi też mają podobne podejście. Niestety. Do tego dochodzą klasyczne grzeszki typu niedostosowanie prędkości do warunków, wyprzedzanie “na trzeciego” czy wymuszanie pierwszeństwa.

Podsumowanie

W tym roku miałem już trzy zdarzenia, które można by podciągnąć pod potrącenie przez rowerzystę (w jednym przypadku rowerzysta poleciał przez kierownicę, w dwóch pozostałych skończyło się na niegroźnej glebie). Miałem też okazję być światkiem kilkunastu innych niebezpiecznych sytuacji, których można by uniknąć jeżeli tylko rowerzyści nie uważali się za święte krowy, które mają prawo jechać po chodniku niezależnie od tego jak wygląda sytuacja na jezdni.

Dodaj do

Jak mawiał wujek Ben do Pitera Parkera vel Pająk Korsarz po spotkaniu z przedszkolakiem (kwestia braku odnóży).

To będzie wpis krótki, acz treściwy.

Rzecz pierwsza minister Nowak vs Wprost. Dziennikarz coś napisał, minister poczuł się urażony. Najął więc adwokata, który skonstruował mu taki pozew, że aż wszystkim szczena opadła. Przeprosiny w postaci 30mln PLN. Warto tu zauważyć, że opłata sądowa związana z wysokością tej kwoty jest równa 0 ponieważ minister chce przeprosin, a nie odszkodowania/zadośćuczynienia. Oczywiście dziennikarze podnieśli rejwach, że tak nie wolno i generalnie minister chce cenzury (poszło też zabezpieczenie powództwa w postaci zakazu publikacji). Ja jednak powiem tak. Tępy chuj dziennikarski, który napisał tekst o zegarkach w tak kretyński sposób powinien mieć zakaz publikacji. Nie masz dowodów nie piszesz. Masz dowody ujawniasz. A nie kurwa zgrywasz Antka.

Rzecz druga… tu będą cycki… w zbożu… Wykop. Ok Elfik32 kiedyś napisała:

Faktycznie sperma musi mieć właściwości odmładzające ponieważ ostatnio coraz częściej słyszę pytanie “a ty dziewczynko masz dowód osobisty?”

Piękne… szczególnie w trollnecie. Potem ktoś wyciągnął jej sesję zdjęciową:

mam nadzieję, że nie zabrudziliście elektroniki…

No i się bany posypały. Co zabawne posypały się ponieważ moderatorka poczuła władzę, a ogólne metody moderacji są takie, że mod może więcej. i znowuż gdyby ktoś pomyślał i nie gadał głupot to by było spokojnie…

Dodaj do

Na początek odcinek Numberphila

Panowie przedstawili ciekawy problem. Czy liczba może być chroniona przez prawo? Na pierwszy rzut oka takie rozwiązanie wydaj się irracjonalne. Szczególnie jeżeli weźmiemy pod uwagę tylko zbiór liczb naturalnych.

//offtop dla tegorocznych maturzystów – Liczba naturalna to taka fikuśna liczba, która nie ma części “po przecinku” // koniec offtopu

Załóżmy, że mamy sobie program, który ma równo 1GB tj. 8*10^9 bitów. Możemy go zapisać jako jedną liczbę rzędu wielkości 2^8000000000 – dwa do ośmiu miliardów… nie jest to znowuż taka duża liczba. No dobra jest…

Problem pojawia się jeżeli zaczniemy rozprowadzać taką liczbę w internecie… sama liczba zaczyna być chroniona przez prawo autorskie ponieważ ma wiele wspólnego z maturą z polskiego. Jak to?! Otóż o specjalnym znaczeniu tej liczby decyduje sposób jej interpretacji. Nasza liczba jeżeli zostanie potraktowana w specyficzny sposób może wykazywać pewne cechy “dzieła”. Jakie są to cechy?

• Po zapisaniu w systemie dwójkowym
• W postaci pliku o odpowiednim rozszerzeniu
• Oraz przyznaniu temu plikowi odpowiednich flag (uprawnień) w systemie operacyjnym
• Bardzo konkretnym systemie operacyjnym
• Na bardzo konkretnej architekturze procesora

Zatem jak widać nasza interpretacja musi być bardzo konkretna według bardzo ścisłego klucza… i przejebane jak napiszesz “iż” zamiast “że”.

W tym miejscu widać absurd prawa autorskiego w odniesieniu do oprogramowania. Obejmujemy ochroną liczby, co prawda duże, ale nadal liczby. W dodatku ochrona jest przyznana tylko dlatego, że istniej jakaś unikalna konfiguracja sprzętowo-systemowa pozwalająca na pewną konkretną interpretację tej liczby. Jest to pozbawione sensu postępowanie, szkodliwe i ograniczające nas w tak podstawowej kwestii jak możliwość zapisu liczb.

Dodaj do

Z powodu, bo tak:

Listing 1. Epicka klasa

/**
*   Copyright 2013 Bartek 'koziołek' Kuczyński
*
*   Licensed under the Apache License, Version 2.0 (the "License");
*   you may not use this file except in compliance with the License.
*   You may obtain a copy of the License at*
*
*       http://www.apache.org/licenses/LICENSE-2.0
*
*   Unless required by applicable law or agreed to in writing, software
*   distributed under the License is distributed on an "AS IS" BASIS,
*   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
*   See the License for the specific language governing permissions and
*   limitations under the License.
*/
package pl.koziolekweb.epic;

public abstract class Epic {

    private T t;

    private Epic(T t) {
        this.t = t;
    }

    private static class Win extends Epic {

        public Win(T t) {
            super(t);
        }

        public boolean isWin() {
            return true;
        }

        public boolean isFail() {
            return false;
        }

        public String message() {
            return "";
        }
    }

    private static class Fail extends Epic {
        private String message;

        public Fail(T t, String message) {
            super(t);
            this.message = message;
        }

        public boolean isWin() {
            return false;
        }

        public boolean isFail() {
            return true;
        }

        public String message() {
            return message;
        }
    }

    public static  Epic win(T t) {
        return new Win(t);
    }

    public static  Epic fail(T t, String message) {
        return new Fail(t, message);
    }

    public T result() {
        return t;
    }

    public abstract boolean isWin();

    public abstract boolean isFail();

    public abstract String message();
}

Dodaj do

W poprzednich wpisach poświęconych Vaadin 7 i Scali pokazałem jak można uprościć sobie życie i klepanie kodu Vaadin za pomocą Scali. Przy czym starałem się by prezentowany kod był “javopodobny” względnie nie wykorzystywał tych elementów języka Scala, które w znaczący sposób odróżniają go od czystej Javy. Dziś zaprezentuję najbardziej scalowe podejście do rozwiązania problemu rozwlekłego API Vaadin za pomocą Scali. Jak słusznie zauważył Miki zamiast wrappera można użyć mechanizmu typów domniemanych (ang. implicit conversion).

Wprowadzenie krótkie

Java jest językiem silnie typowanym tzn. że jeżeli zadeklarujemy iż dana zmienna jest typu Samochód to chciał nie chciał musimy używać tylko obiektów, które są samochodami w odniesieniu do tej zmiennej. Możemy przypisać do niej co prawda coś co samochód rozszerza, ale i tak będziemy mieli do dyspozycji tylko metody z klasy Samochód. Na drugim końcu są języki słabo typowane takie jak JavaScript, php, Ruby. W ich przypadku interpreter stara się wywnioskować “co poeta miał na myśli”. Z jednej strony jest to wygodne ponieważ zwalnia programistę z konieczności konwersji typów, co jest szczególnie widoczne w przypadku konwersji pomiędzy typami podstawowymi (czytaj tymi bez których ciężko się obyć) np. Integer <> String czy String <> Date. Jednak z drugiej strony może to doprowadzić do niezbyt przyjemnych sytuacji kiedy interpreter chce być “mondrzejszy niż ustawa przewiduje” oraz wymusza zachowanie pewnych konwencji w notacji. Scala idzie na pewien kompromis wprowadzając wyżej wspomniany mechanizm domniemania typu. W ogólności zasada jest prosta. Definiujemy sobie metodę, która przyjmuje jako parametr obiekty typu A i zwraca obiekty typu B. W trakcie kompilacji gdy kompilator trafia na wywołanie metody przyjmującej jako parametry obiekty typu B do której podano jako parametr obiekt typu A zaczyna sobie przeszukiwać świat w poszukiwaniu odpowiedniego konwertera. Jeżeli go trafi to podstawia odpowiednie wywołania. Jak nie trafi to no cóż… błąd kompilacji też błąd.

Praktyka

Na początek utwórzmy sobie obiekt, który będzie zawierał nasze konwertery. Będzie to object, bo nie potrzebujemy tu wielu instancji ani tym bardziej stanowości.

Listing 1. Obiekt MyConverters

object MyConverters {

  implicit def toClick(m: => Unit) = new Button.ClickListener {
      def buttonClick(p1: ClickEvent) {
        m
      }
    }

}

Nazewnictwo jak widać nie jest wyszukane, ale nie w tym rzecz. Choć warto by w rzeczywistości używać nazw znaczących ponieważ mechanizm kompilatora trafiając na dwie konwersje pomiędzy tymi samymi typami powie delikatnie, że ma ambiwalentne uczucia co do naszej inteligencji (wprost “patrz co robisz debilu”). Mając już przygotowany mechanizm konwertera warto go sobie zaaplikować:

Listing 2. Klasa MyVaadinUI

import com.vaadin.server.VaadinRequest
import com.vaadin.ui._

import MyConverters._

class MyVaadinUI extends UI {

  var liczby: List[Int] = List(0)

  override def init(request: VaadinRequest) {
    val layout = new VerticalLayout()
    layout.setMargin(true)
    setContent(layout)
    val liczbyLabel = new Label("0")
    val input: TextField = new TextField("Podaj liczbę")
    input.setValue("0")
    val kolejnaBtn: Button = new Button("Kolejna")
    input.setImmediate(true)

    def y: Unit = {
      liczby ::= input.getValue.toInt
      liczbyLabel setValue liczbyLabel.getValue + "+" + input.getValue
      input.setValue("")
      return input.focus()
    }
    kolejnaBtn.addClickListener(y)

    val sumaBtn = new Button("Suma")
    def x: Unit = {
      // sumowanie liczb
      val wynik: Label = new Label(liczby.foldLeft(0) {
        (a, b) => a + b
      }.toString)
      layout.addComponent(wynik)
      liczbyLabel.setValue("0")
      liczby = List(0)
    }
    sumaBtn.addClickListener(x)

    layout.addComponent(input)
    layout.addComponent(kolejnaBtn)
    layout.addComponent(liczbyLabel)
    layout.addComponent(sumaBtn)

  }
}

I w ten oto prosty i przyjemny sposób mamy elegancki kod, w którym nie ma rozwlekłych nazw czy jawnego użycia wrapperów.

Dodaj do

Vaadin jest frameworkiem dobrym. Ma jasno określone cele, wymagania oraz zapotrzebowanie na zasoby. API jest niczego sobie, a jak nam mało to zawsze możemy do pracy zaprząc GWT i frameworki JavaScriptowe. Ma jednak to API jedną straszną wadę…

// DOWCIP

W C metody nie mają nazw opisowych. W php nazwy czasami są opisowe, czasami nie, a do tego nie trzymają się konwencji w nazewniczej. W Javie metody mają nazwy opisowe, tzn. po sygnaturze wiesz mniej więcej co metoda robi. W Ruby metody mają nazwy opisowe, które mieszczą się w jednej standardowej linii.

// HAHAHA

Generalnie Java jest dość rozwlekłym językiem np. implementacja anonimowego interfejsu jest upierdliwa. Podobnie nie ma możliwości zastosowania częściowej implementacji (metody niezaimplementowane rzucają UnsupportedOperationException, ale wstawia to kompilator) bez wykorzystania wzorca Adapter (patrz adaptery w Swingu). Trochę szkoda, że Lombok tego nie wspiera, ale generalnie jest do dupy. Vaadin przeniosło jednak ten specyficzny aspekt języka na nowy poziom. Generalnie jednym z moich ulubionych rozwiązań są wewnętrzne interfejsy dla listenerów (np. Button.ClickListener). Pozwala to na wyklarowanie naszych klas i jasno rozdziela kod listenerów dla konkretnych elementów UI. Nie ma też już uniwersalnych listenerów opartych na drabince ifów sprawdzającej źródło zdarzenia. Jednocześnie jednak nazwy zaczynają być bardzo długie, a przy implementacjach anonimowych naprawdę przestaja się mieścić w standardowych 80 znakach na linię…

Tu na ratunek przychodzi Scala i jej mechanizm funkcji. W uproszczeniu jako parametr metody/konstruktora możemy przekazać funkcję, która zostanie wywołana wewnątrz tejże metody. Przypomina to trochę mechanikę wskaźników na funkcje znanych z C, gdzie można było np. ustawić jako jeden z elementów struktury wskaźnik na funkcję i już mieliśmy taką okrojoną klasę.

Poniżej przykład implementacji Button.ClickListener, która jest “w miarę krótka”.

Listing 1. Klasa UBCL.scala

class UBCL(m: =>Unit) extends Button.ClickListener{
  def buttonClick(p1: ClickEvent) {
    m
  }
}

Oraz jej zastosowanie w przykładzie z poprzedniego wpisu:

Listing 2. Klasa MyVaadinUI.scala

class MyVaadinUI extends UI {

  var liczby: List[Int] = List(0)

  override def init(request: VaadinRequest) {
    val layout = new VerticalLayout()
    layout.setMargin(true)
    setContent(layout)
    val liczbyLabel = new Label("0")
    val input: TextField = new TextField("Podaj liczbę")
    input.setValue("0")
    val kolejnaBtn: Button = new Button("Kolejna")

    kolejnaBtn.addClickListener(new UBCL({
      liczby ::= input.getValue.toInt
      liczbyLabel setValue liczbyLabel.getValue + "+" + input.getValue
      input.setValue("")
      input.focus()
    }))
    val sumaBtn = new Button("Suma")
    sumaBtn.addClickListener(new UBCL({
      // sumowanie liczb
      val wynik: Label = new Label(liczby.foldLeft(0) {
        (a, b) => a + b
      }.toString)
      layout.addComponent(wynik)
      liczbyLabel.setValue("0")
      liczby = List(0)
    }))

    layout.addComponent(input)
    layout.addComponent(kolejnaBtn)
    layout.addComponent(liczbyLabel)
    layout.addComponent(sumaBtn)

  }
}

jak widać udało się “obciąć” definiowanie metody buttonClick na rzecz użycia funkcji.

Dodaj do

Wpis będzie o rzeczach podstawowych.

Vaadin 7

Wyszło już pewien czas temu. Zmian w stosunku do poprzedniej “dużej” wersji jest dużo. Dla nas na chwilę obecną ważne jest, że nie dziedziczymy po klasie Application, a po klasie UI. Zresztą ta pierwsza klasa nadal jest obecna w API ponieważ twórcy chcą utrzymać zgodność wsteczną.

Pierwszym krokiem jest wygenerowanie sobie aplikacji w mavenie, czyli piszemy mvn archetype:generate i przeklikujemy się przez odpowiednie pola. W efekcie otrzymujemy prostą aplikację Vaadin z przyciskiem, który pokazuje labelkę.

Scala

Jak mamy już gotowy projekt Vaadin czas na dorzucenie elementu Scali. W tym celu w pom.xml dopisujemy:

Listing 1. zawartość pom.xml

    
        
            org.scala-lang
            scala-library
            2.10.1
        
    
    
           
                org.scala-tools
                maven-scala-plugin
                
                    
                        
                            compile
                            testCompile
                        
                    
                
                
                    src/main/java
                    
                        -Xms64m
                        -Xmx1024m
                    
                
            
    

Starczy. Po uruchomieniu jettego: mvn package jetty:run otrzymamy działającą aplikację.

Czas trochę pogrzebać w kodzie. Najpierw wywalamy javową klasę MyVaadinUI i zastępujemy ją klasą scalową. By nie było zbyt łatwo nasz projekt będzie to prosty kalkulator tzn. będziemy podawać w polu tekstowym kolejne liczby, które na koniec zsumujemy na scalową modłę.

Listing 2. zawartość MyVaadinUI.scala

class MyVaadinUI extends UI {

  var liczby: List[Int] = List(0)

  override def init(request: VaadinRequest) {
    val layout = new VerticalLayout()
    layout.setMargin(true)
    setContent(layout)
    val liczbyLabel = new Label("0")
    val input: TextField = new TextField("Podaj liczbę")
    val kolejnaBtn: Button = new Button("Kolejna")

    kolejnaBtn.addClickListener(new Button.ClickListener {
      def buttonClick(event: Button.ClickEvent) {
        liczby ::= input.getValue.toInt
        liczbyLabel.setValue(liczbyLabel.getValue + "+" + input.getValue)
        input.setValue("")
      }
    })
    val sumaBtn = new Button("Suma")
    sumaBtn.addClickListener(new Button.ClickListener {
      def buttonClick(event: Button.ClickEvent) {
        // sumowanie liczb
        val wynik: Label = new Label(liczby.foldLeft(0) {
          (a, b) => a + b
        }.toString)
        layout.addComponent(wynik)
        liczby = List(0)
        liczbyLabel.setValue("0")
      }
    })

    layout.addComponent(input)
    layout.addComponent(kolejnaBtn)
    layout.addComponent(liczbyLabel)
    layout.addComponent(sumaBtn)

  }
}

Tu nie ma żadnej magii.

Na koniec mała niespodzianka

Jeżeli pracujecie sobie w domu i na własny użytek to zapewne szybko zauważycie, że najbardziej bolesną zmianą w stosunku do wcześniejszej wersji pluginu Vaadin do mavena jest domyślne włączenie zadania update-widgetset w fazie package co powoduje odpalenie kompilatora GWT i tym samym znacząco wydłuża czas potrzebny na uruchomienie serwera Jetty. By pozbyć się tego problemu wystarczy przystąpić do programu myJRebel i wykupienie licencji Social za całe 0 USD. W czym tkwi haczyk? Pozwalamy ZeroTurnaround na publikowanie na naszym Twitterze albo Facebooku. IMO cena jest niewielka, a korzyści ogromne. Tu uwaga, by JRebel prawidłowo działał z mavenem i jettym trzeba pamiętać o przekompilowaniu klas w IDE (ja używam Idei i Eclipse i nie ma problemów z konfiguracją) oraz podpięciu JRebel jako agenta JVM na poziomie zmiennych systemowych JAVA_OPTS i MAVEN_OPTS. Co ciekawe maven nie korzysta z JAVA_OPTS

I to chyba na tyle

Dodaj do

Pani szatniarka nie dostała koszulki… bywa… Pogoda dopisała i do szatni nie zabłądziłem.

Słowo wstępne

W tym roku po raz kolejny dane mi było pojawić się na konferencji DevCrowd w roli prelegenta. Tak jak w poprzednich latach ekipa ze Szczecińskiego JUGa świetnie przygotowała imprezę od strony organizacyjno-technicznej. Wielkie brawa dla nich. Za to, że co roku jest coraz lepiej i za to, że im się jeszcze chce. Tak jak poprzednio ekipa w koszulkach z Czerwonym Kurczakiem zaanektowała dwie sale na Wydziale Informatyki ZUT. Po krótkiej ceremonii otwarcia pojawiła się pewna dziura dająca czas na migrację do sal.

Prawo Javy – Rafał Malujda

W tym roku postanowiłem poszwendać się po prezentacjach “miękkich”, a nie “mięsnych”. Pierwsza z nich prowadzona przez Rafała okazała się całkiem ciekawa. Na początek niewielkie zaskoczenie – Rafał jest radcą prawnym i jednocześnie pasjonatem Linuxa (m.in. działa w szczecińskim hakerspace, SzLUG-u itp. w dodatku używa Linuxa do pracy). Rzadkie to połączenie w naszych czasach. Sama prelekcja była poświęcona… no właśnie nie do końca wiem czemu. Trochę porozmawialiśmy o tym czy Java jest standardem , trochę o bijatyce Oracle z Google w temacie maszyny Dalvik i trochę o licencjach. Jak widać wszystkiego po trochu. W efekcie zakończyliśmy na omówieniu tego co przyniosło by patentowanie języków programowania. Prezentacji nie ocenię. Z dwóch powodów. Po pierwsze treści jest raczej “około” i jeżeli kogoś to interesuje to OK, jeżeli nie to nie. Po drugie, składnikiem oceny jest też ocena prelegenta. Jako, że Mysza też jest prawnikiem to wiem, że ocenianie kogoś, kogo praca polega m.in. na wygłaszaniu mów przed sądem nie ma najmniejszego sensu.

Six Sigma w projektach IT – Marta Owczarczak

W trakcie drogi na konferencję Marta stwierdziła, że trochę obawia się czy tematyka będzie pasować do profilu wydarzenia. Powiem tak, nie samym technicznym mięchem żyją programiści. Prezentacja była ciekawa. Trochę Wikipedii na początek, czyli omówienie czym jest Six Sigma dlaczego powstało i po co należy wdrażać tą metodykę. O samej metodyce powiem tyle, że w takim klasycznej deweloperce na pewno znajdzie się miejsce na może nie tyle co na tą metodykę ale na pewno na dużą część narzędzi. Druga część prezentacji dotyczyła właśnie narzędzi i tego jak je wykorzystać do poprawienia jakości procesów. Trochę excela, trochę gnuplota. Na zakończenie Marta opowiedziała jeszcze trochę o organizacji Six Sigma jako takiej. jak wygląda certyfikacja itp.

Prezentacja była naprawdę fajna. Warto pracując jako informatyk-programista poznawać narzędzia do zarządzania procesami z innych gałęzi przemysłu. Ponieważ można je adaptować do swoich potrzeb, a i nowe pomysły na oprogramowanie pojawić się mogą.

Ja

Byłem, mówiłem, tradycyjnie czekam na oceny i komentarze.

Obiad

Był całkiem smaczny. W ramach przerwy obiadowej na scenie pojawili się przedstawiciele m.in. SzJUG i fundacji Aegis, którzy opowiedzieli trochę o sobie.

Jak zwiększyć wydajność pracy? – Łukasz Kuczera

Tą prezentację można określić jednym słowem – Chaos. Łukasz chciał w ciekawej formie pokazać wiele rzeczy i przekazać ogromną ilość informacji na temat tego… no właśnie czego? Zwiększenia wydajności pracy raczej nie. Poprawy samopoczucia i zdrowia. W pewnym sensie. Środków farmaceutycznych… też. Zagrożeń płynących z jedzenia mięsa, warzyw owoców i picia piwa… też. Moim zdaniem najsłabsza prezentacja w tym roku na DevCrowd.

Loudcloud – aplikacja do wspólnego słuchania muzyki w Scali i Playframework 2 – Michał Gibowski

Pierwsza stricte mięsna prezentacja na której byłem. Po pierwsze zabolał brak mikrofonu. Prowadzącego zagłuszała muzyka z jego laptopa. Trochę szkoda. Sądziłem, że prezentacja będzie bardziej Playframeworkowa niż Scalowa. Było na odwrót. Na początek, krótki wstęp czym jest Loudcloud, jaka była motywacja do napisania itp. To poszło sprawnie. Pomysł mi się podoba i w sumie OK. Następnie Michał zaczął opisywać różne mechanizmy Scali i na tym upłynęło najwięcej czasu. Szkoda, bo szybka próba uczenia języka raczej była skazana na porażkę. Przy okazji było trochę o aktorach Akka i przykład zastosowania ich w praktyce. Na koniec krótki rzut okiem do kodu aplikacji. Prezentacja nawet fajna. Szkoda, że Michał nie skupił się na omówieniu np. tego jak działają websockety w Playframework czy też tego jak radzą sobie ze streamingiem muzyki.

Księżycowo podbudowane testowanie, czyli rzecz o sklecaniu własnej podbudowy do zautomatyzowanych testów funkcjonalnych aplikacji sieciowych – Filip Pająk

Filip jest jedynym prelegentem, z którym nie pogadałem na afterze… hm… szkoda. Prezentacja była mało mięsna. Dotyczyła tego jak w firmie, w której pracuje Filip rozwiązano problem automatyzacji testów aplikacji webowych. Było trochę o tym dlaczego czasami warto pisać własne narzędzia. Później porozmawialiśmy o problemach z Selenium. I to było chyba na tyle. Przy okazji Filip odpalił przykładowy test automatyczny sprawdzający jakiś przykład z Playframework.

Prezentacja w sumie niezła. Podobało mi się to jak została przeprowadzona. Poukładana spokojna i rzeczowa.

How secure your web framework is? – Łukasz Lenart

Jako członek fundacji Apache z prawem głosu Łukasz jest osobą, którą na pewno warto posłuchać. Opowiedział nam o tym dlaczego warto przeglądać biuletyny bezpieczeństwa używanych frameworków i rozwiązań. Na przykładzie Struts 2 zademonstrował kilka ciekawych rodzajów ataku począwszy od banalnego XSS poprzez bardziej złożone związane z mechanizmem wywoływania metod przez akcje Strutsa, a kończąc na dość hardkorowym przykładzie osadzania “lewej” strony jsp na serwerze. Przy okazji pokrótce opowiedział jak wyglądała walka z tymi podatnościami – systemy Open Source też użerają się z bugami i to jest pocieszające.

Najfajniejsza z mięsnych prezentacji.

Podsumowanie

After się udał. Impreza jak pisałem wyżej była świetnie przygotowana. Do zobaczenia za rok.

Dodaj do

Tytuł: Język programowania Scala
Autor: Grzegorz Balcerek
Rok: 2012
ISBN: 978-83-934-1100-9

Rok temu na DevCrowd w Szczecinie otrzymałem od autora kopię tej wspaniałej książki. Z autografem, czyli na bogato. Na kilka dni przed tegoroczną edycją czas by zamieścić recenzję NAJLEPSZEJ KSIĄŻKI O PROGRAMOWANIU jaka została wydana w języku polskim.

Taka ocena jest podyktowana przez kilka czynników. Po pierwsze na rynku mamy wiele dobrych książek dla programistów, ba wiele książek jest bardzo dobrych, a w zasadzie było by takimi gdyby nie spierdolone tłumaczenia. Tak, wiem… przetłumaczyć książkę to sztuka… pierdololo… skoro można sensownie przetłumaczyć wiersz to można i całkiem dobrze przetłumaczyć książkę. Po drugie Grzesiek rzeczywiście się przyłożył. Nie ma tu, za dużych, zrzutów z dokumentacji, a sam pomysł na odsyłanie czytelnika do specyfikacji jest bardzo dobry. Dzięki temu książka jest przejrzysta i łatwo ją ogarnąć. Po trzecie pokrywa ona jak podejrzewam jakieś 95% języka. Przy czym te niepokryte 5% to jakieś szczegóły, o których istnieniu nie musi wiedzieć nawet twórca

Pokadziłem czas na minusy. Szczegółowość opisu spada wraz z czasem. Na początku mamy dokładnie rozpisane typy języka w sposób wręcz “javadocowy” by w miarę czytania coraz mniej było informacji “naukowej”. Jej miejsce zastępują nie do końca jasne przykłady. Szczególnie boli to osoby, które nie miały okazji bliżej poznać np. zasad tworzenia gramatyki języka programowania. Powoduje to pewną niespójność przekazu. Początkowa szczegółowość trochę odrzuca… trochę bardzo. Choć nie ma tego dużo to jednak boli czytanie o kolejnej klasie tak jak bym czytał dokumentację. Boli mnie też ostatni rozdział, bo o ile gra w szachy jako przykład jest fajna, to strasznie nieżyciowa. Lepsza była by prosta aplikacja webowa czy jakiś inny “weterynarz”. Boli też olanie tematu głębszej współpracy z javą (JPA, web, spring). Jest też trochę drobnych błędów, które powodują konieczność wracania i dodatkowego wczytywania się w przykłady.

Podsumowując, jeżeli chcesz zacząć naukę Scali i nie za bardzo wiesz jak do tego podejść to polecam tą właśnie książkę. Jest już co prawda trochę nieaktualna (np. w Scali 2.10 mamy aktorów Akka), ale nie są to różnice, które spowodowały by jakieś większe problemy. Jeżeli znasz język to warto książkę kupić jako podręczny almanach.

Dodaj do

Jako, że zapłaciłem już ZUS to mogę ponarzekać…

Rys historyczny

Po reformie walutowej (denominacji) w 1994 roku rządzący Przenajświętszą Rzeczpospolitą stanęli przed problemem niestabilnego systemu emerytalnego oraz szerzej przed problemem rosnącego zadłużenia państwa. Drugi problem można przynajmniej teoretycznie wyeliminować za pomocą emisji długoletnich obligacji skarbowych. Mają one taką fajną właściwość, że przynoszą szybki zastrzyk gotówki, a spłata zobowiązania jest mocno odroczona w czasie (dla polityka – nie nasz problem). Choć wydaje się, że taka emisja spowoduje wzrost deficytu to jednak nie do końca tak to działa. Głównym źródłem deficytu w tamtym czasie były wydatki bieżące, a nie obsługa długu. Pierwszy problem był jednak znacznie poważniejszy. Spadek przyrostu naturalnego jest wrogiem systemu emerytalnego w stylu kaiserowskich Niemiec, który opiera się na tzw. kontrakcie społecznym. Dodatkowym czynnikiem dobijającym system była prywatyzacja przemysłu ciężkiego powodująca przejście na emeryturę m.n. górników i hutników. Mieli oni prawa do wcześniejszej emerytury i jednocześnie nie należeli do FUS i nie uczestniczyli we wspólnej ściepce.

OFE – pomysł dobry

Rozwiązaniem obu problemów jest właśnie reforma, która wprowadziła OFE. Z jednej strony pozwala ona na odcięcie państwa od systemu emerytalnego, może nie w pełnym, ale znacznym zakresie, a z drugiej dała możliwość pozamiatania problemu deficytu. Z perspektywy 1997 roku taka reforma była dobrym pomysłem. Polsce dopiero co wstąpiła do NATO, a podpisanie porozumień z EWG (UE) było kwestią czasu. Zatem sposób rozwiązania problemów jest naturalnym efektem dobrej perspektywy. Jednocześnie reforma była tak skonstruowana, że nie prowadziła do gwałtownego wycofania pieniędzy z już istniejącego systemu. Oznacza to, że emeryci nie musieli się martwić o wypłatę “kontraktowych” świadczeń.

Czym jest OFE?

Tu dochodzimy do zasadniczej części mojego wywodu. Należy sobie teraz odpowiedzieć sobie na to bardzo ważne pytanie. Jest to w pewnym sensie pytanie retoryczne… OFE to specyficzna forma TFI. Specyficzna z kilku powodów.

• OFE mają nałożone ograniczenia inwestycyjne podobne do tych znanych z tzw. “parasoli finansowych”. Mogą inwestować tylko ograniczone środki w agresywny sposób tzn. akcje itp. Większość środków muszą inwestować w, uważane za bezpieczne, obligacje skarbowe.
• OFE muszą wypracować konkretny i wcale nie mały zysk, co w przypadku ograniczeń inwestycyjnych jest trochę trudniejsze.

Te dwa elementy są może nie trudne do pogodzenia, ale dość mocno utrudniające życie OFE. Stąd wynika kolejny zapis reformy, czyli 10% prowizji dla OFE. By zachęcić instytucje finansowe do wejścia na rynek OFE należało dać im przynętę. Jej rolę pełniła właśnie bardzo wysoka prowizja(obecnie ścięta do bardziej rynkowej stawki). Z prowizjami TFI jest tak, że im bardziej ryzykowne inwestycje tym prowizje większe. Na własnym przykładzie płacę około ~6,5% w najbardziej agresywnym (akcje) z posiadanych funduszy. W przypadku gwarantowanych i parasolowych prowizje można ściąć do mniej niż 1%. Zatem OFE były opłacalnym biznesem. Jedyną rzeczą nie uregulowaną w tamtym czasie była kwestia wypłat. Zresztą słusznie ponieważ tworzenie prawa, które było by martwe przez kolejne 15 lat nie ma większego sensu. Trzeb aby je było aktualizować i dostosowywać do zmieniających się regulacji.

OFE, a deficyt

Kolejne pytanie jakie nasuwa się w tym miejscu, to co ma OFE do deficytu? OFE mając ograniczenia w inwestowaniu musi inwestować m.n. w obligacje skarbu państwa. Zatem OFE finansują państwo, a to zobowiązuje się pokryć przyszłe wypłaty. Fenomenalnie widać to na tym wykresie. Rząd Jerzego Buzka przeprowadza reformę. Następnie mamy “pik” deficytu na początku kariery Millera spowodowany rozbudowanymi programami socjalnymi. Po czym w kolejnych latach rządy ograniczają deficyt by w 2010 roku pojawił się kolejny “pik”… w 2010 roku mijał termin zapadalności pierwszej transzy obligacji kupionych przez OFE. Tych 10 lat to zmarnowany czas, który powinien być poświęcony na reformę finansów publicznych. Zamiast tego kochani współobywatele wybrali socjał w stylu SLD i w efekcie obecną dziurę budżetową.

Przemilczana wada OFE

Tak jak w przypadku każdego TFI tak i w przypadku OFE należy liczyć się ze stratami. Nie powinny być one dotkliwe, ale mogą się pojawić. TFI to nie lokata. Kursy podlegają wahaniom czasami rosną, a czasami spadają. Co prawda w perspektywie czterdziestu kilku lat pracy straty raczej nam nie grożą, ale zawsze mogą się pojawić.

Kilka dygresji

News o wysokości zarobków szefów OFE. W sumie dobrze, że dużo zarabiają. Szczególnie, że wypracowują zyski. Co prawda pojawiają się niepokojące sygnały, ale…

Likwidacja OFE albo czasowe zawieszenie wpłat. Pomysł co najmniej zły. Szczególnie zawieszenie wpłat jest złym pomysłem. Prowizja leci, a zyski topnieją. Likwidacja OFE choć spowodowała by konieczność wykupienia przez państwo wszystkich obligacji oraz zapewne niezłe pierdolnięcie na giełdzie jest opcją trochę lepszą. Po ustabilizowaniu budżetu można by zacząć reformę jeszcze raz.

System węgierski, czyli wybór OFE+ZUS albo ZUS. Scenariusz jeszcze gorszy niż likwidacja czy zawieszenie wpłat. Głównym powodem, dla którego nie wolno dopuścić do tego rozwiązania jest jego populizm. Emerytury z ZUS będą i tak niskie, ale OFE jeżeli wypracują zyski spowodują bardzo silne rozwarstwienie emerytur. Szczególnie, że dobrowolność już jest w obecnym systemie pod postacią III Filaru.

Wypłata świadczenia przez X lat. Jest to jak najbardziej rozsądny argument. Skoro Twoja emerytura będzie taka jak sobie wypracujesz… to normalne, że nie będzie można jej wypłacać w nieskończoność. W pewnym momencie zgromadzne środki się wyczerpią.

Po co nam ZUS i OFE?

Na koniec trzeba jeszcze odpowiedzieć na to pytanie. Ano ZUS i OFE są nam po to by wywiązać się z wspomnianego na początku kontraktu społecznego. Powolne systematyczne wycofanie się z niego jest konieczne by państwo funkcjonowało prawidłowo. Nagłe odrzucenie starego systemu spowoduje, że zostanie naruszony najważniejszy element, czyli zaufanie obywatela do państwa. Co będzie myślał emeryt i jego rodzina kiedy z dnia na dzień okaże się, że trzeba wziąć staruszkę teściową na własne utrzymanie. Nawet jeżeli dostaniemy tych kilka złotych więcej, bo nie będziemy odprowadzać składki na ZUS. Co ważne ci emeryci wywiązali się ze swojej części umowy i mają prawo do emerytury. Skoro państwo nie wywiązało się ze swoich zobowiązań to co to za państwo?

Dodaj do