jQuery live input value reading (keydown, keypress & keyup story)

When I tried to get advantages of getting input field changes after each key I met some problems. To make this description short I do not present examples of my problems, but leads you to final solution.

Solution:

    $(function () {
      $("#m1").keydown(function(){
        that=this;
        setTimeout(function(){
          $("#m1s").text(
            that.value ? that.value : ""
          )
        },0)
      });
    }
    );

HTML content:

  <label for="m1">Test input: </label><input id="m1" placeholder="type here" />
  <hr>
  <span id="m1s">&lt;empty&gt;</span>

Explanation:

1. When key event is triggered it is not applied to control, because you can prevent default browser reaction in handler. The only key event triggered after value changed is keyup. It is not nice to update information only when key is released.
2. Using setTimeout with 0ms delay gives browser opportunity to apply default key handlers and update control content (value).
3. God candidate to be used is keypress event, but... in some browsers keypress is not triggered for character removing keys. Keydown event is triggered for removing character as well, so it is final choice.

Doubts:

It is not sure, that keydown event is triggered when key is repeated by log press keyboard. It works for me so fat.

Here you can see working example: http://jsbin.com/

Beans... JavaBeans.... EnterpriseJavaBeans...

Jest to już 4 odcinek kierowany dla odbiorcy określonego przeze mnie jako ProgramistaGranit. Wszystko zaczyna odcinek Z ręką w nocniku....

Chciałbym zaznaczyć, że nie powinniście traktować tych opisów jako wiedzy technicznej. Nie polegajcie na tym co tu piszę w 100%, zawsze sprawdzajcie szczegóły. Ogólnie jest tak jak piszę, ale nie gwarantuję, że wszystkie kody są w 100% kompilowane i poprawne. Mają tylko demonstrować ideę jaką chcę przekazać.

Pora na EJB
Zastanawiałem się, czy wyróżnić tę część J2EE, ale ostatecznie jest tu chyba największa analogia do środowiska COM/DCOM i warto chwilę o tym napisać.
No więc dla zrozumienia idei możecie przyjąć, że EJB i COM to jest kropka w kropkę to samo. Tylko, że oczywiście EJB są bardziej przejrzyste i jakoś wszystko jest do zapisania prawie w samej javie (no i trochę XML). Nie wypowiem się o tym jak się stawia do tego środowisko i takie tam... bo to jak już pisałem zazwyczaj będziecie mieli gotowe. A nawet jeśli miałby was ktoś o to zapytać, to zawsze możecie powiedzieć, że stawiał to admin, a wy tylko developowaliście.
To co zauważyłem, to że zazwyczaj bean składa się z co najmniej dwóch plików w javie. Pierwszy zawiera definicję interfejsu (czyli puste metody). Ten plik zazwyczaj nazywa się tak samo jak klasa komponentu/serwisu. Drugi plik, gdzie już implementowany jest interfejs ma taką samą nazwę (klasę) z sufiksem Impl. Czyli mamy tak:

// plik MyComponent.java
// przykładowa deklaracja
public interface MyComponent {
    public String myMethod(...);
    ...
}

// plik MyComponentImpl.java
// przykładowa implementacja
public class MyComponentImpl implements MyComponent {
    public String myMethod(...) {
        ...
    }
    ...
}

W  środowisku J2EE przyjęło się jakoś nazywać te komponenty serwisami. Być może jest to jakiś lokalny zwyczaj jaki poznałem i dotyczy tylko komponentów bezstanowych. W tym przypadku nazywanie komponentu serwisem ma dość duże uzasadnienie - podobnie jak klasę statyczną można nazywać biblioteką funkcji.
Kolejnym krokiem jest osadzenie naszego serwisu na jakimś hoście... czyli serwerze aplikacji, czy jak to tam nazwać. Jak wiecie w COM komponenty też same nie działały. Musiały posiadać aplikację hosta, która komponenty tworzyła, puszczała w procesie (najczęściej osobnym na każdy pakiet) i zapewniała komunikację ze światem (i z komponentami między sobą). W przypadku COM tym hostem był MTS.
W EJB mamy jakiś wybór bo sama technologia jest ogólnodostępna i jest kilka implementacji... Ja miałem okazję zapoznać się z jedną w prostszych - Spring. Na 100% nie powiem czy to tylko framework czy host dla aplikacji, w każdym razie jest to kolejna warstwa, którą musimy pokonać w czasie implementowania serwisu/komponentu. Spring przyjmuje informacje o naszym komponencie w postaci pliku XML. Wygląda on jakoś następująco:

<bean class="com.mycom.myController" id="myController">
  <property name="myComponent" ref="myComponent">
</property>
</bean>

W praktyce, jeśli trafi się wam zadanie aktualizacji jakiegoś serwisu czy dopisania do niego jednej metody, to powinniście operować w obrębie tych trzech plików.
Jeśli traficie do projektu, który już istnieje i wszystko ma skonfigurowane, to myślę, że będą wam wdzięczni, że nic więcej nie będziecie zmieniać. Z reguły (podobnie jak to miał Granit) istnieją już jakieś klasy bazowe, które załatwiają detale techniczne i w zasadzie pozostaje już programowanie czysto biznesowe.
Dużym sprzymierzeńcem jest tu środowisko. W Eclipse wciskam CTRL+SHIFT+R i otwiera się okienko wyszukiwania wszystkich składowych projektu. W ten sposób łatwo zlokalizujemy klasę wg nazwy - zarówno jej interfejs jak i implementację.
Kolejnym sprzymierzeńcem jest sam język, który w kolejnych wersjach wchłania co bardziej powszechne rozwiązania i ułatwia ich stosowanie. Tak na przykład jest w korzystaniu z serwisów. Wcześniej każda klasa wymagała też rozbudowywania pliku XML po stronie klienta, obecnie java potrafi to wspomagać. A co za tym idzie robota programisty korzystającego z beana jest prostsza:

@Autowired
myComponent mc;

Jest jeszcze jedna ważna rzecz o jakiej chciałbym przypomnieć.
Każda technologia ma polecane metody komunikacji i przeznaczone do tego typy danych itp. Podobnie jest też w przypadku bean'ów. Najczęściej korzysta się tu z tzw. serializacji - czyli zamiany obiektu klasy na strumień bitów. Przesyłane powinny być tylko obiekty klas implementujących interfejs serializable. Gdzieś wspominałem, że warto z tym się zapoznać i chyba na wszystkich rozmowach kwalifikacyjnych o to pytają.
Podobnie miał zresztą COM, ale nie wiadomo czemu na którymś z etapów rozwoju postanowiono całą komunikację ograniczyć od tablic OleVariant - myślę, że to największa zmora z jaką przyszło spotykać się ProgramiścieGranit. Tu na szczęście jest łatwiej, a na wszystkie problemy potrafi odpowiedzieć google ;)

Myślę, że na początek tak powierzchowna wiedza wam wystarczy. Zainteresowani więcej znajdą w internecie.

W kolejnym kroku będę chciał coś wspomnieć o JPA i Hibernate...

Zamieszczone przykłady pochodzą ze strony: http://static.springsource.org/spring/docs/1.2.7/reference/ejb.html

Jawna ściema...

Jest to 3 odcinek kierowany dla odbiorcy określonego przeze mnie jako ProgramistaGranit. Wszystko zaczyna odcinek Z ręką w nocniku....

Programiści języka Java (podobnie jak administratorzy Oracle) mają tendencje do podkreślania swojej elitarności. Trzeba przyznać, że wychodzi im to całkiem nieźle i najczęściej trudno oprzeć się wrażeniu, że od Delphi do Java jest daleka droga.

Moim zdaniem jest wręcz przeciwnie... i o ile różnice są i to zauważalne, to Java w samych założeniach jest językiem prostszym i bardziej przyjaznym programiście. Poza tym nie zapomnijcie, że nie mówimy o domorosłych programistach Delphi, którzy naklikali w IDE aplikacyjkę do przeglądania fotek. ProgramistaGranit to zazwyczaj informatyk po studiach kierunkowych, gdzie programowanie obiektowe było potrzebne jak powietrze do życia. W gruncie rzeczy, to nawet znajomość C++ wystarczy aby programować w Jawie, ale należy je okroić o większość trudnych konstrukcji...
Teza na dziś: jeśli potrafisz przeczytać ze zrozumieniem kod języka JAVA to bez większych problemów możesz w tym języku zacząć pisać.
Najtrudniejszy problem to chyba programowanie obiektowe - a to już nie java a sposób myślenia. Jedni myślą obiektowo inni nieobiektowo... W Delphi też można programować obiektowo, tylko że jest to trudniejsze. Postaram się to jakoś powoli odczarować.

Hasło na dziś to J2EE
Jawowcy robią wszystko aby wydawało się wam, że J2EE jest trudniejszą odmianą języka Java... w pierwszym akapicie wyjaśniłem dlaczego. Prawda jest jednak taka, że J2EE to nic innego, że serwerowa wersja javy dedykowana do programowania komponentów. Podobnie jak Delphi w Granicie jest używane w wersji dedykowanej do obsługi COM+ (komponentów). Już z samej analogii powinniście przyjąć, że to musi być prostsze. I takie faktycznie jest!
Czy ProgramistaGranit może powiedzieć o sobie, że jest programistą Delphi? Zapewne może, ale w wielu przypadkach polegnie jeśli przyjdzie mu omawiać biblioteki TLC czy sposób obsługi połączeń z bazą danych oferowanych przez Delphi. Większość tych "bzdur" jest nieużyteczna w programowaniu "biznesowym". Magiczna wiedza ogranicza się do umiejętności produkcji "klocków" przetwarzających dane wejściowe na oczekiwany efekt.
W języku Java jest jeszcze prościej, nikt nie oczekuje, aby programista J2EE dłubał jakieś formatki i obsługiwał je w jawie. Trzymając się tej tezy, muszę potwierdzić, że nawet obsługa bazy danych jest o wiele prostsza niż to co znacie z Granitu. Ba! Jeśli to prawdziwe J2EE oraz JPA to bazy danych nawet w waszym programie nie widać! Po prostu klepiecie sobie metodę klasy, która używa jeśli potrzebuje obiektów innych klas i każe im się zapisać, odczytać itp... Czyli, żeby już was dłużej nie ściemniać. Nie musicie znać żadnych javnych klas i bibliotek związanych w budowaniem GUI, nie musicie wiedzieć niewiadomo czego o łączeniu się środowiska jawa z serwerami bazy danych czy WWW i innych. Jedyne co musicie umieć, to utworzyć obiekt klasy, wywołać jego metodę, pracować na jego atrybutach i wynikach metod (obiektach lub tablicach/kolekcjach). Jeśli ograniczycie swoją znajomość do tych zagadnień to możecie o sobie mówić, że jesteście programistami J2EE.

Weźcie pod uwagę jeszcze jedną bardzo ważną rzecz. Zmieniając pracę i otrzymując nowe zadanie, nie dostaniecie na dzień dobry zadania postawienia całego środowiska od zera. Trafiacie do działającego projektu, działającej aplikacji, gdzie tylko musicie wcisnąć własny "klocek" w otoczeniu, które już swoją obecnością powoduje, że w umyśle wam się rozjaśnia. Na każdym kroku jest działający przykład, gotowa ściąga czy grupa ludzi, która wie co i jak.
Postaram się wam zaimprowizować zadanie jakie może się trafić w nowej pracy. Zbudować metodę zmieniającą opis urządzenia - uzupełnienie o adres IP (zadanie jest bardzo abstrakcyjne, ale tak też będziecie się czuć w nowej pracy).

 
public int yourFirstTask(int deviceId){
    Device d1 = deviceService.getDeviceById(deviceId);
    String IP = d1.getIP().toString();
    d1.setDescription(d1.getDescription() + " (" + IP + ")");
    return deviceService.addModivyDevice(d1);
}

Nie chcę nikogo obrażać, ale wydaje mi się, że sam kod jest banalny. Nawet nie wiem, czy on jest poprawny, ale oddaje wam kontekst nowych zadań jakie możecie mieć w nowej pracy.

Aby jednak wszystkiego nie bagatelizować, to napiszę co należy sobie przypomnieć i mieć do dyspozycji jeśli zajdzie potrzeba:

• dziedziczenia - w zasadzie w jawie jest wielka moda na budowanie klas i ich specjalizowanie, po prostu dziedziczenie powinno być natywną metodą pojmowania przez was świata
• polimorfizm - mimo iż z teoretycznego punktu widzenia zagadnienie wydaje sią zaawansowane, to tak na prawdę trudne jest ono tylko dla kompilatora języka. Moim zdaniem jest to najbardziej naturalna cecha programowania obiektowego
• typy podstawowe języka Java - nie ma ich tak wiele, ale dają wielką pewność jeśli przyjdzie bo budowania nowych rozwiązań
• kolekcja, zbiory itp. - w zasadzie w aktualnym programowaniu w języku java uwielbiane są kolekcje i wszystkie typy pokrewne. Pętle wyliczeniowe oparte na indeksowaniu ustępują miejsca tym iterującym po kolekcjach np.
  

  List list = new ArrayList();
  list.add("Bernadine");
  list.add("Elizabeth");
  list.add("Gene");
  list.add("Elizabeth");
  list.add("Clara");
  for (String listElem : list) {
    System.out.print(listElem + " ");
  }
  

• klonowanie i serializacja - jedyne rozszerzenie jakie należy poznać. Napiszę o tym jeszcze później.

Na zakończenie postaram się w trzech słowach odczarować wam listę, jaką najczęściej można spotkać w opisach technologii J2EE:
J2EE - sam język java okrojony z wszystkich elementów nie do wykorzystania po stronie serwera. Weźcie też pod uwagę, że najczęściej w firmie nie będziecie jedynym specjalistą od tej technologii. Będzie tam dostępna wiedza techniczna i specjaliści potrafiący skonfigurować środowisko produkcyjne, środowisko pracy programisty i oddalić od was wiele innych trudnych problemów...
Weźcie też pod uwagę, że sam język java powstał aby uprościć to co w innych językach było trudne. Nie musicie przejmować się wskaźnikami, rezerwowaniem i zwalnianiem pamięci i wieloma innymi.
JPA i Hibernate -  Tu pojawia się wcześniej wspomniana serializacja... już tłumaczę. Programiści javy uważają, że obiektowość wszystko upraszcza, więc musi też uprościć zapisywanie obiektów do bazy danych. Rozwijając JPA dostaniemy Java Persistance Api - czyli api dla utrwalania obiektów javy. Oznacza to, że każdy obiekt w języku java chcielibyśmy w łatwy sposób zapisać i odtworzyć w "trwałej przestrzeni". W ogólności tę trwałą przestrzeń reprezentuje strumień, który bezpośrednio daje się zmapować np. na plik. Czyli programista java chcąc utrwalić obiekt po prostu wykonuje ZapiszDoStrumienia(obiekt);
Drugim poziomem wtajemniczenia jest zapisanie obiektu do bazy danych. Tu wyjaśnia drugie magiczne słowo Hibernate. Jest to zbiór klas i tzw. adnotacji języka, które potrafią połączyć pola waszych klasy z polami bazy danych. W efekcie zamiast zapisywać do strumienia możemy polecić aby obiekt został zapisany w bazie danych. Dla was najważniejsze jest to, że tę część z reguły robią wyjadacze i na początku nikt nie pozwoli Wam tego dotykać.
Servlets - to chyba najbardziej prehistoryczny element programowania biznesowego. Wywodzi się jeszcze z interfejsu CGI implementowanego w serwerach WWW. Nawet jeśli nie jesteście w grupie programistów WWW to idea ta jest w waszym zasięgu. Servlet robi bardzo prostą rzecz - buduje stronę WWW. Budowanie takie składa się z takich kroków jak:
- interpretacja danych wejściowych - np. pól w formularzu czy wciśniętego linka - są możliwe dwie metody przekazania takich danych i jest prosta klasa pozwalająca je zdekodować
- przetwarzanie danych - czyli zwykłe programowanie, być może wywołanie metody komponentu...
- zbudowanie odpowiedzi - czyli sklejenie i przesłanie treści strony WWW. Najczęściej sama strona ma już swoją budowę i musimy do niej dostarczyć wyprodukowane informacje. Nasza klasa powinna zapisać do strumienia wyjściowego przedefiniowane elementy strony okraszone wynikami przetwarzania lub zbudować plik XML jaki przetworzą i zaprezentują pozostałe elementy witryny.
Spring - w największym uproszczeniu jest to odpowiednik COM w Programowaniu Granitowym. Klasy języka java mogą być zamykane w komponenty - tzw. beany. Podobnie jak w przypadku COM tak i w javie potrzebny jest host dla tych komponentów - to właśnie zapewnia nam Spring. Tu znowu programista nie jest odpowiedzialny za działanie środowiska. Jedyne co ma do wykonania, to zdefiniowanie w prostych zapisach XML jak jego klasa powinna zostać udostępniona. Będzie jeszcze czas o tym napisać. W ogólności wystarczy bardzo powierzchowna znajomość...
Apache Maven - jest to dość pokręcone środowisko zapewniające poprawne buildowanie skomplikowanych aplikacji. Całość sprowadza się do mnogości plików konfiguracyjnych (pom.xml), które opisują zależności między poszczególnymi elementami aplikacji. Na podstawie zależności Apache Maven dokonuje inteligentnego buildowania aplikacji. Z punktu widzenia developera ważna jest umiejętność używania środowiska, czyli wpisywania: MVN INSTALL lub MVN CLEAN COMPILE czy inne...
CSV lub SVN - świat nie używa VSS, ale innych popularniejszych odpowiedników. Ostatecznie okazuje się, że są one prostsze niż sam VSS, a to dlatego, że:
- posiadają bardzo użyteczne dodatki pozwalające na integrację z powłoką MS Windows
- posiadają integrację do środowisk rozwojowych (np. Eclipse)
Apache Tomcat - nie znam go dobrze. W zasadzie po zainstalowaniu ustawia się potrzebne informacje w Eclipsie i dalej już jakoś aplikacja automatycznie zostaje przenoszona na serwer Tomcat. W praktyce należy tylko wiedzieć, że serwer często wywala się w czasie debugowania i należy zaznajomić się z kilkoma sztuczkami - napiszę jeszcze o nich
Eclipse - to jest nasz największy sprzymierzeniec. Gdy pierwszy raz użyłem tego narzędzia do programowania w javie zacząłem się zastanawiać po co było mi to kilkudniowe przypominanie sobie języka. Okazuje się, że środowisko już w czasie pisania wyłapie większość błędów i ,co najciekawsze, zaproponuje kilka propozycji usunięcia błędu. Dodatkowo na bieżąco serwuje podpowiedzi, że nie sposób się pomylić.

Przepraszam za to trochę eklektyczne przedstawienie tematu. W kolejnych postach postaram się odczarowywać szerzej poszczególne elementy.

Dla przypomnienia języka polecam źródełko, jakie mi się wydało godne polecenia:
http://www.cezarywalenciuk.pl/?tag=/Java
Moim zdaniem koleś bardzo przystępnie pisze.

Kolejny odcinek: Beans... JavaBeans.... EnterpriseJavaBeans...

Ciemność, widzę ciemność...

Jest to 2 odcinek kierowany dla odbiorcy określonego przeze mnie jako ProgramistaGranit. Wszystko zaczyna odcinek Z ręką w nocniku....

Podsumujmy czym standardowy Programista Granit może zawojować informatyczny rynek pracy:

• Borland Delphi - znajomość bardzo dobra - prawdopodobnie najlepsza w okolicy, głównie z braku konkurencji. 
• COM/DCOM i MTS - znajomość dobra - o ile udało mu się zagłębić w coś więcej niż tylko zamykanie pakietów i dodawanie komponentów do tychże. Podobnie jak powyżej, raczej brak konkurencji na rynku
• język SQL (ostatnio coraz bardziej SQL by MS) - znajomość bardzo dobra, wymagane do życia
• MS SQL Server - jeśli się komuś poszczęściło to doszedł do zagadnień związanych z konfiguracją samego serwera i optymalizacją wydajności
• Znajomość platformy programistycznej opracowanej przez pracodawce - mimo iż to chyba najbogatszy zasób wiedzy i najtrudniejszy do pozyskania to na rynku zupełnie bezużyteczny... niestety
• Umiejętność realizacji zadań programistycznych w powyższym środowisku, w szczególnych przypadkach także umiejętność dekompozycji i projektowania komponentów, struktury bazy danych oraz interfejsu użytkownika
• VSS - nie ma o czym pisać...

A to czego standardowy Programista Granit na pewno w pracy nie wykorzystał:

• system przeglądarkowy - mimo iż od dawien dawna pracodawca zapewnia go, że bierze udział w tworzeniu aplikacji intranetowej, a ostatnio pojawia się nawet aspiracja pracy w Internecie, to niestety nie ma on o tym zielonego pojęcia...
• programowanie obiektowe - tu niestety jeśli sam ktoś się nie postarał, to obiektowego programowania w czasie pracy nie wykorzystał. Mimo iż niby to dziedziczy z klasy bazowej i tworzy komponenty, to niestety tylko namiastka.

Wyposażony w taki zbiór umiejętności i doświadczeń Programista Granit zaczyna szukać możliwości zamiany pracy i przegląda ogłoszenia poszukując intersekcji posiadanych umiejętności i oczekiwań pracodawców. Przeciera oczy ze zdumienia i... ciemność, widzi ciemność.

Nie bez znaczenia jest tu też fakt, że pracodawca niczym religię wyznawał zasadę niewysyłania pracowników na szkolenia, tak więc jak już coś mogłoby się Programiście Granit trafić... to bezczelnie wymagają od niego certyfikatów (np. z MS SQL Server).

Jak wygląda taki standardowy worek dostępnych ofert pracy? Ano tak:

• programista PHP
• programista .NET - najczęściej różnoznaczne z C#
• programista JAVA
• programista HTML/CSS - tu ostatnio używanie słowa programista przestaje być nadużyciem
• certyfikowany administrator MS SQL Server
• certyfikowany administrator Oracle

Pominąłem tu oczywiście oferty, nad którymi raczej się nie pochyli, jak np. tester czy serwisant lub informatyk od wszystkiego :)

W Poznaniu znany jest mi jeden pracodawca, który używa Delphi, o dziwo Delphi 5 - firma Comarch. Nie znam szczegółów, ale prawdopodobnie chodzi o utrzymywanie i rozwijanie jakiejś równie starej aplikacji.

Kolejność ofert wg częstości występowania, przy czym pierwsze dwie to ponad połowa liczby ofert.

Wydaje się, że nasz Programista Granit po odrzuceniu rzeczy, na których zupełnie się nie zna pozostaje z następującą listą możliwości:

• programista .NET - w końcu to podobno następca COM/DCOM
• programista JAVA - w końcu jeśli jest programistą, to programowanie w Javie uczą na każdych studiach od 15 lat
• (certyfikowany) administrator MS SQL Server - jeśli ciągnęło go w tym kierunku, to zapewne ma wiedzę wymaganą do zdania egzaminu, ew. może spróbować oczarować na rozmowie kwalifikacyjnej swoją wiedzą niepopartą certyfikatem.

Ja osobiście nie zamierzam promować drogi w kierunku .NET, ale nie odradzam - po prostu nie o tym będę pisał.

MS SQL Server - moim zdaniem fajna sprawa dająca wiele możliwości, niestety wymaga dużej specjalizacji, czyli albo się specjalistą jest albo się nie jest...

Programista JAVA - to jest zakres, który chciałbym odczarować w ramach kolejnych postów. Na zakończenie dzisiejszego wpisu tylko wskażę, co wchodzi w możliwy zakres oczekiwanych umiejętności programisty JAVA:

• J2EE
• JPA i Hibernate
• Servlets
• Spring
• Apache Maven i CVS lub SVN
• Apache Tomcat
• Eclipse

W kolejnych wpisach zobaczycie, że większość tych zaklęć macie na wyciągnięcie ręki i wystarczy mniej niż tydzień, aby rozpocząć w nich pracować - wszystkich naraz...

Kolejny odcinek:Javna ściema

Z ręką w nocniku...

Chciałbym w tym miejscu pozdrowić, zapewne niemałą, grupę programistów, którzy zapomnieli się przez parę lat w technologii, która okazała się nieprzyszłościową. Innymi słowy poszli w ślepy zaułek i teraz kombinują jak tu nie obudzić się z... ręką w nocniku właśnie. 

Sam wywodzę się z takiej grupy, która utknęła w technologii opartej o niszowy obecnie język programowania Delphi oraz platformę COM/DCOM dla pocieszenia nazwaną później COM+. Co jeszcze gorsze firma zdecydowała się na budowanie swojej platformy programistycznej, którą obecnie nowocześnie moglibyśmy nazwać frameworkiem..., ale która z nowoczesnością niewiele ma wspólnego. Na całe szczęście udało mi się z bazą danych, bo był to MS SQL Server, który w miarę się przez te lata rozwinął i obecnie jest wartościowym produktem a co za tym idzie kwalifikacje są doceniane (ale bez przesady...). Pozostaje oczywiście wiedza merytoryczna z zakresu jaki się oprogramowywało... ale tu też można mieć więcej szczęście niż znajomość gospodarki mieszkaniowej... i umiejętność naliczania czynszu...

W tym blogu, a przynajmniej w tej jego części dostępnej pod etykietą "ProgramistaGranit" postaram się przedstawić jakie opcje ma do zaoferowania współczesny rynek pracy takiemu dinozaurowi i jakie kierunki przekwalifikowania (niestety) są łatwiej, a jakie trudniej dostępne.

No to zaczynamy...

Kolejny odcinek: Ciemność, widzę ciemność...